Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Szia!
Néhány gondolat az (E)USART kezeléséről (A továbbiakban, az egyszerűség érdekében, az egy illesztővel rendelkező kontrollerek regiszter és bit neveit használom, értelem szerűen az USART1 ill. USART2 -re a regiszter és bit nevek átírandók): - PIC18F67J90 errata-jában van egy megjegyzés az USART-ról... - Az RCIF bitet az RCREG olvasása törli. - A vett adat és az adathoz rendelt állapot bitek egy fifo-ba kerülnek, a fifo-t az RCREG olvasása lépteti. Az RCSTA regisztert előbb kell olvasni, mint az RCREG-et. - Egy vételi megszakítás kérés kiszolgálása alatt csak egyszer szabad az RCREG-et olvasni. Állapot lekérdezéses kezelésnél is csak egyszer szabad olvasni az RCREG-et, az állapotot az PIR1 geriszter RCIF bitjével kell figyelni. Ha vett adat többször kellene, akkor az értéket el kell menteni valahová. - Ha keretezési vagy ráfutási hiba keletkezett, a hiba törléséhez a vevőt tiltani majd újra engedélyezni kell. ld. Errata. - Ha a feldolgozás egyes részleteinek ideje nagyobb, mint a venni kívánt karakterek közti minimális idő, akkor a megszakításos, bufferelt kezelést ajánlom... Idézet: Ez tuti így van ? Mert ugye van egy 2 mély fifo a vételi oldalon, és ha gyorsan jönnek az adatok akkor belekerülhet két karakter. Tehát ha beesik a megszakítás, akkor kiolvasom RCREG et, pufferelem, és utána megnézem hogy visszabillent-e újra az RCIF, mert akkor megint kiolvasom. Vagy ez így nem jó ? „Egy vételi megszakítás kérés kiszolgálása alatt csak egyszer szabad az RCREG-et olvasni.”
Szerintem jónak kell lennie, feltéve, hogy csak az RCIF-et vizsgálod meg acélból, hogy van-e következő karakter. Az interrupt-rendszer ilyenformán független az USART-tól, a Hp41C által leírt megkötések kifejezetten az USART modul működéséből adódnak. Gyakorlatilag az ISR-ben lehet egy "while (RCIF) {}"-et is írni, ha nagy sebességű kommunikációt kezelünk viszonylag lassú PIC-en, ezzel csak azt kockáztatjuk, hogy tömeges és gyors adatvételkor túl sok időt töltünk el az ISR-ben és emiatt a programunk többi időzítése szétcsúszhat.
Egyébként emlékeim szerint anno PC-n a 16450/550 kezelésénél is az ilyen while-jellegű interruptos kezelés volt a célravezető, sőt, mivel ott az USART-ból több dolog is tudott interruptot kiváltani, minden várakozó eseményt le kellett kezelni az interruptban.
Szia!
Úgy értettem, hogy ha egy adatot kiolvasunk, és ennek az adatnak a feldolgozásához többször van szükség az értékére, akkor az RCREG-et csak egyszer szabad kiolvasni, az értéket menteni kell, a feldolgozás során a mentett érték olvasható akárhányszor. Pontosan azárt kell így csinálni, mert, ha rendelkezésre áll a következő vett karakter, az RCREG második olvasásra már azt az értéket kapnánk, a harmadikra a következőt (ha már vette), ráadásul a státusz fifó-t is léptetné. Persze ha egy adat státuszát kiértékeltük, az adatát feldolgoztunk / elmentettük, meg lehet nézni, hogy készen van-e már a következő vétele - még ugyanabban a megszakítási rutinban is.
Sziasztok!
Olvastam Topi cikkeit a "Nulláról a robotokig - PIC Mikrovezérlők" Nagyon sokat tanultam belőle. Jó lenne, ha lennének hasonló cikkek a következő témákban is.Magyarul. - Capture - Compare - PWM modul - Analog-Digital converter - SSP és I2C - USART/SCI - PSP Kár, hogy nincs. Használtam a keresőt, de sajna, ami ilyen jó szájbarágósan tárgyalná, és ráadásul anyanyelven, sajnos nem találtam. Esetleg, ha valakinek van valamelyik témában, szívesen venném, ha megosztaná velem. Köszi, hogy elolvastad! Szép estét.
Nézd csak! Ebben a témában már 101-szer be volt linkelve, itt van 102-edszer is. Piccolo projekt... :yes: Mindenképpen ajánlott olvasmány.
Ez tényleg nagyon jó olvasmány, de a fentebb írtakról (CCP, A/D, USART, I2C...) sajnos nem esik benne szó.
Auf! A CCP modulról (capture, compare, PWM) itt van egy kis magyar nyelvű infó: Bővebben: Link
Tökéletesen igazad van, de amilyen szép szisztematikusan bővül a tananyag, előbb-utóbb ezek a perifériák is sorra fognak kerülni.
 Persze azt is tudom, hogy nem illendő más bőrére ígérgetni, ezért elnézést is kérek icserny-től. :hide:
Nyugi, én már tavaly beígértem a továbbiakat a PICCOLO projekt bevezetőben!
 Csak lassan haladok. Most a timereknél tartok.
Köszi a hasznos infót.
SzervízMacskának is köszönöm a piccolo project belinkelését. Amit már persze régóta benn van a kedvencek közt. Ahogy Attila86 is írta: Idézet: „sajnos nem esik benne szó.” Viszont én a szájbarágós cikkről írtam, hogy milyen jó is lenne ha az említett témákban úgymond folytatása lenne a "tananyagnak". Amit lehetne olvasni tovább folytatásként. Ugyanis magával ragadó a cikk. Belefeledkezik az ember minden másba olvasás közben. Mint egy film sorozat, lassan építi fel a történetet, részenként, apránként.  Mivel a címe is erre utal. Idézet: „"Nulláról a robotokig - PIC Mikrovezérlők"” tehát elindultunk a nullától, és tartunk kábé a robotok felé félúton. (például a "robot" megnézi az analóg hőszonda jelét, begyűjti a mars adatait, majd lementi I2C-n)
Távol áll tőlem a sürgetés. Minden tiszteletem a Tiéd, hogy ennyi energiát fektetsz a hozzám hasonló tanulatlan verebek okításába!
Okoskodjunk visszafelé:
10 bites AD - 1024 féle kimenet 0,1 °C szorozva 1024 = 102,4 °C Tehát ha 0,1-es felbontással szeretnél mérni, akkor legfejjebb 102,4 °C lesz az átfogásod. Már csak azt kell eldöntened, hogy mi legyen a minimum vagy a maximum értéked, amit meg szeretnél mérni.
Mit csinálok rosszul?
I2C-s BUS-t tesztelnék. PIC16F886 és kijelzésre 2 soros LCD van. PICKIT2-vel, ha DEBUGgolom "működik" megjelenik minden az LCD-n. PICKIT2-t lekapcsolom-lehúzom (külső táppal) az LCD 1. sora fekete kockákkal van kirakva, a 2. üres. Segítség!
Na én az ehhez hasonló jelenségek miatt öregszek.
Logikusan gondolkozva ellenőrizendő, hogy mi van a következő lábakkal párhuzamosan: PGD, PGC, MCLR Debug módban változik-e valamicskét a programkód Én még soha nem debugoltam a PicKit2-vel, meg mással sem, ezért nem volt még ilyen jellegű hibám. De félek, hogy előbb-utóbb előjön. A megoldásodra kíváncsi vagyok.
MCLR 10k Vcc-re, PDG,PGC -vel nem szolgálhatok, de az ICSPDAT és ICSPCLK -ra csak a PICKIT2 csatlakozik. (megoldásra várok)
Amikor nem debug módban indítod, akkor egyáltalán fut-e a program a PIC-ben (pl. egy LED kigyújtásával vagy villogtaqtásával ellenőrizhető)? Az LCD inicializálása megfelelő időzítésekkel az adatlap szerint van-e megírva?
Az LCD leírt állapota olyan, mintha fel sem inicializálnád, ez vagy attól van, hogy a PIC-ben lévő program el sem indul, vagy attól, hogy nem megfelelő az inicializálás.
Szia!
Ha PicKit2 nélkül indítod, akkor Release módban fordított állomány van beprogramozva?
Ha nincs debug módban, úgy tűnik, hogy áll a proci. LCD -re menő lábain nem történik semmi sem. Belső oszcit állítottam be - remélem jól, de most már kételkedem.
Ahogy Hp41C irta is, az önállóan futó programot release módban kellene fordítani. Ez kikapcsolja az(oka)t a bite(ke)t a configban, ami(k) miatt debugolni lehet a programot.
köszi szépen a segítséget, sokat segítettél
 smrtln
Szilva - Hp41C mit csinálnék nélkületek???
Ez volt a baj. Még nem debuggoltam eddig, így van szívás rendesen. Hálás köszönet!
Sziasztok!
Bocsi ha evidens dolgot kérdezek, de már az egész délutánom erre ment rá  Hogy kell a 16F1826-os picnek megadni a konfigurációs sort mplab alatt?__CONFIG _FOSC_INTOSC &_WDTE_OFF &_CP_OFF & _PWRTE_ON & _LVP_OFF Erre hibaüzenetet kapok, de szerintem nem a config bitek megadásával van a gond, hanem valami globális dolgot nem tudok. Ha valaki tudja hogy kell légyszi írjon ide nekem egy configurációs sort! Köszi előre is!
Hello mindenki!
Egy olyan problémám lenne, hogy vettem egy MCP23017-es port extender IC-t ami I2C-vel kapcsolódik a PIC-hez. Egy PIC18F4550-vel szeretném használni. SDCC-t használok és szerencsére van előre elkészített header fájl az adatátvitel beállításához és kezeléséhez de sajnos így sem megy. :S Az a gond, hogy eleve úgy tűnik, hogy a modul nem küld semmilyen adatot mivel a rákötött LED sem villog. 10K-s felhúzó ellenállás van a vonalakon az ADC-nek pedig csak az RA0 és az RA1-es bemenetei analógok a többi mind digitális (ezeket olvastam főbb hibáknak, megmondom őszintén az ellenállásokat én is kihagytam először) de sajnos így sem megy. Azt írta a PIC adatlapja, hogy egyszerre csak egy adatot tud küldeni ezért az adatok között is van egy kis várakozás, amíg foglalt a modul. A PORTB első két portja (RB0 és RB1-es) pedig bemenet. Mi lehet még as probléma? Túl nagy a felhúzó ellenállás? Esetleg valami más? Köszönöm a válaszokat előre is! Bye!
Szia!
A 10k egy kicsit soknak tűnik, de lassabb adatátvitelnek mennie kéne. 100kHz-hez 2K7-et ajánlanak...
Ha 10 k a felhúzás, és a LED úgy van ráakasztva, hogy a föld felé megy, akkor az a vonal garantáltan nem fog tudni magas szintre fölmenni!
Az I2C busznak az a lényege, hogy csak az ellenállás húzza fölfelé, a ráakasztott eszközök pedig vagy lefelé húzzák, vagy nagyimpedanciás (TRI-STATE) állapotba kapcsolnak. Vedd le a LED-et, vagy pedig a tápfesz és a vizsgált vonal közé kösd (min. 1 k áramrkolátozó ellenállással)!
Talán ez még segítség. Ez a hibaüzenet:
Argument out of range (not a valid config register address)
Szia!
Póbáld így:
A __config sor előtt ott vannak a list p=pic16f1826 és az #include
|
Bejelentkezés
Hirdetés |
