Fórum témák
» Több friss téma |
Milyen listában? Nekem viszi gond nélkül.
Ott van az.
Megvan, csak kicsit elbujt.
Uraim, amikor a PIC beállításainál megadom a SPBRG regiszternek a kiszámolt számot az azt jelenti, hogy az USART vagy is a sebessége 9600 Baud Rate lesz?
18F442 + 10MHz kristály + PLL == elvileg 40MHz
A kérdés azért született meg bennem mert olyan mint ha valami nem stimmelne a beállításaimmal. A mostani projektemnél, USART-on keresztül küldenék adatokat a PIC-nek, de egy 16Kb-os adattal elkínlódik 21mp-ig. És akkor ezt már egy nagyon sok kísérletezés eredménye ként sikerült kicsikarnom, úgy, ogy extra műveleteket a PIC nem is végez közben. A hozzászólás módosítva: Jan 30, 2016
Ideális esetben is 17 s lenne, ha jól számolom. A 9600 bit/s az legfeljebb 960 byte/s a keretezés miatt.
Akkor egy 8Mbit-es chipet elég kellemetlen lesz feltölteni, legalább is az idő szempontjából..
USB-s kapcsolattal ez gyorsabb lenne? Gondolok itt arra, hogy mondjuk egy 18F4550-el kísérleteznék, és byte-onként küldeném az adatot?
Mi az akadálya a nagyobb sebességnek?
Egyelőre nem tudom mi az akadálya, de csak ennyire képes most.
PIC18F442 a PIC amire fejlesztek és a nyák elvileg most már legyártás alatt van, így az fix. Az adatküldés folyamata a következő képen működik. PC-és progit írtam ami USART-on küldi byte-onként az adatot PIC-nek: 1. PC adat küldés PIC-nek 2. PIC adat fogadásának vissza igazolása (adat küldés PC-nek) 3. PIC feldolgozza az adatot 4. PC várakozik PIC visszaigazoló adatra 5. Ismétlés az elejétől. Ezzel egy 16356 byte-os adatot 21mp-alatt dolgoz fel a PIC ami baromi sok ahhoz képest, hogy mondjuk egy 8Mbit-es adatot kellene feltölteni. Vagy valamit rosszul csinálok.
115200 Baud -dal 12 -szer gyorsabban menne...
40MHz, BRGH = 1, SPBRG = 20
Nem jól kérdeztem, bocsánat. Az szerettem volna megkérdezni, hogy mi az akadálya a 9600Bd feletti sebességnek.
Sziasztok! Szeretném beállítani egy pic24hj128gp502-es UART BRG-jét. Nem is ez a probléma, hanem hogy nem tudom milyen frekin megy a pic akkor ha bekapcsolom a PLL-jét. Alap esetben PLL nélkül 7,37Mhz es belső órajellel számolva, kijön a BRG érték és hibátlanul küldi UART-on az adatot. Ha bekapcsolom a PLL-t és alap állapotban hagyok minden oszcillátor beállítást akkor 1,84Mhz jön ki számításaimból. ("M" szorzó:2 "N1xN2" osztó:8). Viszont valami nem stimmel, mert ha a kapott frekvenciából kiszámolom a BRG-t akkor a UART fals adatokat küld. A kérdésem az lenne, hogy hogyan tudom megállapítani a pontos frekvenciát ha PLL-t is használok? Adatlapot már rongyosra böngésztem, de nem vagyok benne biztos, hogy nem kerülte el valami a figyelmem. Köszönet előre is!
Szimulátorban ezt már nem lehet emulálni, mert sajnos zagyvaságokat ír csak.
Jó a beállításom?
nedudgi: mert nem tudtam, hogy lehet emelni a sebességen.. A hozzászólás módosítva: Jan 30, 2016
Szia! Bocs, hogy beleszólok, de ahogy átfutottam a kódot beleakadt a szemem abba, hogy TX et is bemenetnek konfigurálod. Ne tedd.
A hozzászólás módosítva: Jan 30, 2016
Köszi, egyelőre gondot nem okozott, de köszi.
Több szem többet lát.
Miért nem méred meg az analizátorral
 ?!
Mit mérjek ki analizátorral?
Hogy helyes adatokat küld e a szimulátor? Egyelőre csak abban tudom tesztelni az USART beállításokat és adatküldést. Éles teszt, talán a jövőhéten vagy azután lehet. 9600-at még jól szimulálja, de felette már nem tudtam beállítani és nem tudom, hogy csak a szimulátor korlátozza, vagy nem jó a beállításom.
Köszönöm, sikerült beállítani.
Működik ezen a sebességen a szimulátor is. Tesztelem..
Én a fordítóra szoktam bízni a regiszterek értékeinek kiszámítását:
Uraim, had kérdezzem meg, hogy ti milyen megoldással oldanátok meg a PC és PIC közötti USART folyamatos adatáramlást a legoptimálisabban és leggyorsabban?
C18-ban programozok. Jelenleg, így működne: 1. PC küld egy adatot PIC-nek és vár 2. PIC egy while ciklusban pörög és egy feltételben figyeli DataRdyUSART() függvényt, hogy érkezik e adat. Ha igen, akkor elvégzi az adat rögzítését 3. PIC kiküld egy adatot PC-nek amivel jelzi, hogy kész és várja a következő adatot 4. PC megkapja az adatot 5. PC az adat tömb végéig ismétli az adatküldést Ami gondot okoz, hogy a PIC nem érzékeli sok esetben az adatot amit PC küld, pedig az kiküldi. Mutatom a figyelő részt.:
A gond, hogy sok esetben nem fut le a feltétel mert olyan mint ha nem kapna adatot, pedig kap. A hozzászólás módosítva: Jan 30, 2016
egyszeruen a PIC oldalon tedd megszakitasba a read-et. Igy ha adat jott , mindenkeppen elugrik az adatkezelohoz, azt gyorsan kiolvassa (pufferbe teszi pl. darabszamlalot noveli) es mar vissza is adja a vezerlest a foproginak, ami meg a darabszamot figyeli, amit mar mi noveltunk.
En ilyen esetben baudrate-beallitasi problemara gyanakodnek elsosorban. Szkoppal nezd meg, mekkora a PIC oldali ADAS sebessege (FF-eket a TX regiszterbe folyamatosan). Na, ilyen sebesseggel VESZI is az adast.
De a ciklusban is érzékelnie kell, hogy van adat, különbem a megszakítás sem működne.
Idézet: „En ilyen esetben baudrate-beallitasi problemara gyanakodnek elsosorban.” Ez hogy csináljam? PC-s programból folyamatosan küldjek 0xFF-eket PIC-nek?
Sziasztok!
16F690, kültérbe szánt kapcsolás. Melyik a jobb választás? Belső órajel vagy külső kvarc? Nem probléma az sem, ha +- 10 %-ot elmászik az órajel frekvenciája. Adatlap szerint -40 °C-ig bírja (árnyékban lesz mindig, max. 40 °C).
A processzor munkaregiszterébe szeretnék tenni közvetlenül egy C nyelvbeli változót. (Most tömb kezdőcímet)
Találtam is szintaktikai ajánlást, de persze triviálisan nem működik. Így néz ki:
Hogyan lehetne ezt megoldani? A hozzászólás módosítva: Jan 30, 2016
Nem, hanem a PIC-bol a PC fele es a TX labra teszed a szkopfejet. Ekkor tudod a PIC baudrate-jet ellenorizni. A masik irany sem haszontalan, de a PC oldalon altalaban kisebb a tevesztes beallitasi lehetosege.
Pl. en mindig a ROOT-ot szivom meg, ha hex-re van allitva, akkor egy jonak tuno decimalis szam (pl. 12) hexaban ertelmezodik, ami 18-nak mar nem jo. Ezert atalltam a 0x56 alakra es DEC-ben hagyom a ROOT-ot. Ja a megszakitas csak otlet volt, mert az hardveres, tehat ha befejezte a bitek betolteset, akkor mindig general megszakitast hardverbol. A pollingot pl. megszakithatja egy masik megszakitas, ami kihagyashoz vezetHET. A hozzászólás módosítva: Jan 30, 2016
Amit most csatoltam az megy PIC-ből a PC-s program felé.
Ekkor tökéletesen működik, de ha PC-ről küldöm az adatot PIC-nek és ezzel a kódrésszel fogadom majd nyugtázom:
Akkor pár jel után megszakad a folyamat. PC csak akkor küld jelet, ha PIC is küld neki és persze ez fordítva is. Azt hiszem a PIC téveszt, de nem tudom miért. PC-és programból így néz ki:
Hardveresen, hogy tudom beállítani, hogy okozzon megszakítást ha érkezik jel? Tudnál ebben segíteni? Kipróbálnám ezt is, hátha megoldja a gondot. A hozzászólás módosítva: Jan 30, 2016
Megtaláltam a megoldást a header file ban. A munkaregisztert WREG0 nak kell hívni, nem W0 nak.
Azonban felmerült egy másik kérdés közben. Az alábbi sor nem tudom értelmezni, túl bonyolultnak tűnik számomra. Így néz ki W re: Idézet: „extern volatile unsigned int WREG0 __attribute__((__sfr__,__deprecated__,__unsafe__));” és így valamely más SRF re: Idézet: „extern volatile unsigned int SPLIM __attribute__((__sfr__));” Valaki el tudná magyarázni hogyan kell olvasni?
Ha nem számít a pontosság akkor inkább belső.
Adatlap. Idezem:
3. If interrupts are desired, set enable bit RCIE. 5. Enable the reception by setting bit CREN. 6. Flag bit RCIF will be set when reception is complete and an interrupt will be generated if enable bit RCIE was set. Te nem ebbol dolgozol? C-ben nem tudok segiteni, de ahogy latom nincs torolve az IF (interrupt flag), amit szerintem meg kellene tenni.
Sokszor leírtam már:
Vétel: Folyamatos vétel, RC megszakítást beállítani, vételi hibát lekezelni, a vett adatot egy vételi bufferbe írni. Adás: A TX megszakíáts az adási bufferből veszi ki a soron következő adatot és beírja a TXREG -be. Ha nincs adat a TX megszakítást tiltja. A fő program a vételi buffert figyeli, ha ven benne adat kiveszi és feldolgozza, a választ az adási bufferbe írja és engedélyezi a TX megszakítást. Melyik szimulátort használod? bbalász: Az RCIF és a TXIF automatikusan törlődik (náhány utasítással később) a RCGER kiolvasása ill. a TXREG írása után. A hozzászólás módosítva: Jan 31, 2016
|
Bejelentkezés
Hirdetés |
