Ha nagy sebesség kell, a szoftveres uart egy rémálom. Kb semmi logikai funkció nem lehet azon a pic-en, mert bármi lefoghatja annyira, hogy elcsúszhat a pic az időzítéssel - talán még interruptostul együtt is, ha másra is kell prioritív interrupt. A szoftveres uart-ot inkább csak olyankor érdemes használni, ha épelméjű sebesség korlátokkal darabszámban kell olyan sok uart, hogy nincsen annyi egy maréknyi pic-en sem. Ritka eset, de nem feltétlen példa nélkül álló. Olyankor feldobni vagy egy marék asic-ot a panelra spi busz láncra kötve (nem tudom, létezik-e spi/uart gateway asic, de biztos gyárt valaki olyat is), vagy feldobni egy újabb pic-et spi buszra kötve, aminek minden kivezetéséből szoftveres uartot csinálhatsz, és ne fusson azon a pic-en egyáltalán semmi más - akkor tudni fogja bírni az időzítést meg az adat kezelést.

Pontosítanék. Az UART egy rémálom. A Can-Busz-al együtt. Lassú, megbízhatatlan, zavar érzékeny. A mai technika mellett megengedhetetlennek tartom, hogy egy PLC egy közepes hosszúságú programot 8-10 percig töltsön UART-on. Akkor már lenne inkább 1-Wire. Azt még egy 64MHz-s PIC-en is fel lehet heccelni közel 2 millió bit/másodpercre szoftveresen is.

Protestálok. Az UART az egyetlen adatátviteli mód, ami az ősidőktől kezdve, minten fajta számítógépen és műszeren létezik. Több mint negyven év alatt mozdonyhangártól a légvédelmi hírhálón keresztül az óceánkutató hajóig meglehetősen sokféle környezetben használtam, és használom ma is. Aláírom, hogy szerencsés vagyok, mert ritkán fordult elő, hogy az elsőre megsaccolt sebességet ritkán kellett csökkenteni, de nem okozott gondot sem a megbízhatóság, sem a zavarérzékenység. Szoftveres vételt keveset használtam, adást csak a legkisebb PIC kontrollerekben. Mindezt csak a belső oszcillátorra hagyatkozva. Előfordult a 921600 Baud sebesség is, ha kellett, működött.

Nem is olyan régen, még LP-n, orsós és kazettás magnón halgattunk zenét. Aztán jött a CD. De mire a CD kiszorította volna teljesen az analóg technikát, addigra itt volt az MP3, és a flash memória.
Ezzel csak arra szeretnék utalni, hogy a régi, igen sokféle, mára elavult kommunikációs technikáknak is el kellene tünnie, átadva a helyet egy gyorsabb, megbízhatóbb, és legfőképpen egységesített rendszernek.
Ahogy a mobiltelefonokon, és egyéb hordozható eszközökön is egységesítették a töltőcsatlakozót.
Kinek jó az, hogy ahány eszközhöz nyúl, más a kommunikációs mód, vagy ha az azonos is, más a protokol.
Míg én a PIC-ekkel, addig a fiam a Nextion kijelzővel bohóckodik. Középen találkozunk. Versenyben szídjuk a kommunikációját, mert agyatlan, értelmetlen.
Míg kifelé kijátszható a Nextion, mert képes egy 32bites szám sallangmentes elküldésrre, azaz csupán 4 byte-ot kiküldeni, befelé komplett szöveges parancsoktat fogad úgy, hogy minden betűt ascii kód formájában kell elküldeni. A hab a tortán, hogy ha egy változót szeretnék küldeni neki, először le kell bontani számjegyekre, és ezek ascii kódját küldeni. Mindezt UART-on.
Szerinted ez normális és elfogadható?

Ez a mindenáron való változás kinek jó? Kérdezz meg pár HiFimániást az eltűnt analóg lemezek és a CD, vagy MP3 közötti különbségről. A digitális műsorszórásra történt átállás lehetővé teszi, hogy még több szemetet nyomjanak le az emberek torkán. A töltőcsatlakozó kifjezetten rossz példa. Egységesítették, de bele van kódolva a tönkremenetel. Az USB pár száz, legfeljebb pár ezer dugásra garantált csatlakozó. De ez már a "Vitatkozzunk..."-ba való téma.
Van benne logika, még ha nem is a fehér emberek szerinti gondolatmenettel. Mondom ezt úgy, hogy nem foglalkoztam vele annál sokkal többet, mint amennyit most ideírtál. A Nextion fejlesztése a felhasználók bevonásával történik. Erre jutottak a logikát a saját szájuk íze szerint értelmező vásárlók.

A kontrollerek és egyéb "egyszerűbb" eszközök univerzális busza egyértelműen az UART. Nincs egységes protokoll? Kit érdekel? Ha már van egy eszköz amihez szeretnénk kapcsolódni, akkor igazodnunk kell a protokolljához. Ez kb. mindig is így volt.

Úgy látom, nem értitek, mi a problémám vele.
Nem az a bajom, hogy két vezetéken bonyolít le kétirányú kapcsolatot.
Még csak nem is az, hogy időalapú.
A problémát a jelalak milyensége, és a szinkronizálás ritkasága adja.
Ezért kell neki start bit, stop bit, esetenként paritás bit.
A start bit indítja az óra szinkront. Az első jelet meg sem kell nézni. A stop bit gyakorlatilag nem jelent semmit.
Ha küldessz egy 0x00-át, 9 bitig alacsony jel van, aztán a következő start bitig magas. Ha küldessz egy 0xFF-et, 1 bit alacsony, utána folyamatos magas a következő start bitig. Márha jön következő.
Ezek nem információ értékű jelek. Adatként fogadhatsz egy vezeték szakadást, vagy zárlatot.
Az 1-Wiret ugyanígy lehetne két vezetéken, két irányú kommunikációra használni.
Csak ott minden egyes bitnél megtörténik az óra szinkronizálása. Épp ezért még pontatlan órajel esetén is hibátlan kommunikációt tud megvalósítani, jóval nagyobb sebességen.
Épp most játszogatok egy programozható RGB LED-el.
800000 bit/sec-től 1000000 bit/sec-ig hibátlanul veszi az adást. Ilyen órajel szórás mellett az UART működésképtelen.

Már említettem, de megismétlem, hogy ilyen irányú társalgás szerintem a "Vitatkozzunk..." topikba való. Nem tudom, hallottál-e róla?
Megfelelő körülmények között az UART nagyobb sebességre képes. Ha gond van, a 1-Wire is lassú lesz.

Az 1-wiren meg több fals állapotot fogadhatsz tévedésből. Sokkal hibaérzékenyebb protokol, mint az uart. Nem véletlenül nem tudta még leváltani az uartot. A szakmai világ egésze szavazott, és az lett a végeredmény, hogy létezik az 1-wire is, használják azt is, de az uartot nem tudta kiszorítani.

Sziasztok!

Sajnos 1 hete nem jövök rá mi okozza a következő problémát: Adott pic16f684
AN0, AN2, AN4 lábakat szeretném használni analóg bemenetnek illetve az AN1 mint referencia.
A probléma, hogy bármelyikről olvasok be a másik két lábra rakott jel (test) áthallatszódik mindegyik analóg bemenetre.
Az alábbiakban láthatjátok a pic initjét:
void init_pic(void)
{
TRISA = 0b00100111;
ANSEL = 0b00010111;
ADCON0 = 0b11000001;
ADCON1 = 0b00010000;

TRISC = 0b00000001;
PORTC = 0b00000100;
PR2 = 0b11111111;
T2CON = 0b00000101;
CCPR1L = 0;
CCPR1H = 0;
CCP1CON = 0b10011100;
PWM1CON = 20;

T0IF=0;
T0IE=1;
T0CS=0;
PSA=0;
CMCON0=0b00000111;
GIE=1;
}
A segítségeteket kérném.

Nekem anno az okozott hasonló gondot, hogy a port átkapcsolások között nem hagytam elég időt. Ebben kódban ez nem látszik.

A következő részlet hátha segít:
while(1)
{
visszatero_homerseklet=(read_analog_input(VISSZATERO_HOMERO)>>2);
eloremeno_homerseklet=(read_analog_input(ELOREMENO_HOMERO)>>2);

if(read_analog_input(INFRA)>200)
{
if (SZIVATTYU==0 && (sec-oldsec)>1) {NYOMOGOMB=0;oldsec=0;infra_valtozas=1;T0IF=1;}
else if (NYOMOGOMB==1 && (sec-oldsec)>1) {NYOMOGOMB=0;oldsec=sec;infra_valtozas=1;T0IF=1;}
}
else if (NYOMOGOMB==0) {NYOMOGOMB=1;infra_valtozas=1;}

Beolvasom a visszatérő hőmérsékletet , az előremenőt illetve az infra led jelszintjét.

unsigned int read_analog_input (unsigned char channel)
{
GIE=0;
ADCON0 = 0b11000001;
ADCON0|= (channel<<2);
GO_nDONE=1;
while(GO_nDONE);
GIE=1;
return ((ADRESH<<8)+ADRESL);
}

Én nem nagyon értem a C kódot, de ha jól látom egymás után olvasol az egyik, majd másik analóg bemenetről. Ha ez így van akkor tudni kellene, hogy a fordító tesz-e oda valami várakozást az első beolvasás után.

Miért tenne, saját rutin kezeli az A/D beolvasást. Az adatlap 9.2 fejezetében van a számítása.

Ja igen, már látom én is. Mondom, hogy nem értem a C kódot. Bár most még azt nem értem, hogy ha ugyan azt a rutint használja akkor hogy vált bemenetet?

Szia!

Szerintem is az a hiba, amit Pali79 kolléga jelez: a csatornaváltásnál ( amikor a következő csatornára vált a kiolvasó függvény !) kellene egy kis idő (ACQUISITION TIME néven nézz utána az adatlapban!) !

szerk. : valószínűleg az is elég lenne, ha az előző csatorna kiolvasása után / a fv. végén, a RETURN előtt! / már átállnál a következő csatornára, de ez az órajeltől és a PIC-től függ !

Próbáld ki ezt:



Csak 1 példa nálad: ADCON0 |= channel<<2 <-itt pl a csatorna a 4-es,így a chs-ben az 4-es csatorna lesz kiválasztva.(CHS = 0b100)
De ha a kövi mondjuk a 0-ás bemenet -> 0b100 | 0b000 = 0b100 ,így nem lesz csatornaváltásod
Bár lehet,hogy még kimaradt valami,nem szoktam használni a pic-ek saját AD-átalakítóját,én csak ennyit fűznék hozzá

Egy lehetséges hiba látszik a kódban. Ha 8 MHz-en járatod a pic-et, akkor túl sok a FOSC/8 az ADCON1-ben.
1us alatt nem fut le a konverzió (9.1-es tábla) és így rossz adatokat olvasol. Jobb lenne FOSC/16, vagy ha biztosra akarsz menni, akkor FRC.

HA a következő sorokat ideiglenesen átírom:
visszatero_homerseklet=0;
eloremeno_homerseklet=255;
akkor a pwm (HOMERSEKLET) kimeneten tökéletes a változás, 0-ra átvált a led és teljesen 255-re teljes fényerőre vissza.
Így gondolom a rossz (áthalló) értékeket a beolvasáskor kaphatja. A visszatérő és előremenő bemenetekre raktam egy 10K és szabadon vannak. Ha az egyikre testet teszek akkor a másik bemenet beolvasásakor is erőteljesen érzékelhető.
Azért problémás, mert a harmadik bemeneten olvasom be az infra led jelét és ha bármelyik hőmérő bemenetre tápot adok, akkor annyira megemeli az infra bemenetét is, hogy bekapcsolást érzékel. Nem értem mi okozza.

Bemásoltam, sajnos nem lett jó. A ADCON0 = 0b11000001; sor minden képen kinullázta a csatornát és azzal vagyolok, így jónak kellett lennie az eredeti megoldásnak is. De, hogy így is lehet azt nem tudtam, köszönöm.

Próba képpen próbálj a beolvasások közé egy kis várakozást tenni.

Upsz...nem is figyeltem az egészet,de legalább ötletet adtam....A másik,hogy próbáld duplán kiolvasni az AD-t,hátha a második eredmény jó lesz pl:

Módosítva:
unsigned int read_analog_input (unsigned char channel)
{
GIE=0;
ADCON0 = 0b11000001;
//ADCON0|= (channel<<2);
ADCON0bits.CHS= channel;
__delay_us(20);
GO_nDONE=1;
while(GO_nDONE);
GIE=1;
return ((ADRESH<<8)+ADRESL);
}
Sajnos a jelenség ugyanaz.

Internal oszcillátor megy, de nem változtattam rajta. Mi az alapértelmezett? 4 vagy 8MHz?
#pragma config FOSC = INTOSCIO
#pragma config WDTE = OFF // Watchdog Timer Enable bit (WDT disabled)
#pragma config PWRTE = ON // Power-up Timer Enable bit (PWRT enabled)
#pragma config MCLRE = ON // MCLR Pin Function Select bit (MCLR pin function is MCLR)
#pragma config CP = OFF // Code Protection bit (Program memory code protection is disabled)
#pragma config CPD = OFF // Data Code Protection bit (Data memory code protection is disabled)
#pragma config BOREN = ON // Brown Out Detect (BOR enabled)
#pragma config IESO = ON // Internal External Switchover bit (Internal External Switchover mode is enabled)
#pragma config FCMEN = ON // Fail-Safe Clock Monitor Enabled bit (Fail-Safe Clock Monitor is enabled)

Alapértelmezetten 4MHz, de ezt a C-nek is meg kell adni, hogy jól számolja a késleltetést.

Átírtam így:
void init_pic(void)
{
TRISA = 0b00100111;
ANSEL = 0b00010111;
ADCON0 = 0b11000001;
ADCON1 = 0b00110000;

Az eredmény változatlan.

#define _XTAL_FREQ 4000000
Sajnos benne van ez a sor is.

És a referencia feszültség stabil? Teszteld Vdd-vel.

Átállítottam Vref-et Vdd-re. A tápban 0,,005 ingadozás van, 3,62 és 3,61 között ingadozik.
A jelenség mintha inkább erősödött volna. Az épen nem kijelzett lábra testet téve látszik a változás pedig nem kéne.
GIE=0;
ADCON0 = 0b10000001;
ADCON0bits.CHS=channel;
__delay_us(20);

Milyen ák. feszültségét méred ? Ha túl nagy a belső ellenállása, akkor a mintavevő kondi nem tud "átállni" ?!