Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Az nem nano- hanem mikrosec, vagyis kb fel millisec.
Idézet: „Ahogy néztem a port kiíratások között 500nsec eltolódás van, de az "új" PICben még nem is néztem (18F67K22).” Szerintem erre írta  !
Oh, igazad van! Nem neztem, hogy az eredeti hozzaszolas iroja irta. Igy o nem csak a szkopkep alapjan nyilatkozhat.
De akkor viszont ne aggodjon, mert egy 400Hz-es jelnel az az ido elhanyagolhato.
Helló!
Más másik témában is írtam, de ott nem sikerült megoldani a problémát; gondoltam próbálkozok itt is. PICkit 2-n (PIC16F887) próbálgatom az indirekt memóriacímzést de nem sikerül. Debuggoláskor látom, hogy az FSR megkapja a megfelelő értéket, de a MOVWF INDF már nem működik rendesen. A beállított cím helyett a 0x021 kapja meg a WREG értékét. A melléket képen látszik minden. Mi okozhatja a problémát?
Szimulátorban, vagy igazi PIC-en? A szimulátor nekem ritkán csinálta jól a dolgokat.
Az is lehet probléma, ha engedélyezed az interruptokat, és az interrupt rutin "elrontja" a regisztereket. Ha a főprogram is használja ugyanazokat a registereket, mint az interrupt rutin (pl. itt az FSR), akkor az interrupt rutin elején menteni, végén visszaállítani kell. Ugyanez igaz a STATUS byte-ra is, bár azt nyilván mindenki tudja, hogy menteni kell.
Igazi PIC, és a kód is a MAIN elején van szóval még szó sincs megszakításról.
Na várjál. A CPU pont azt csinálja, amit mondtál neki.
Beraktál decimális 33-at (= hexa 0x21) a címregiszterbe, ő meg berakta erre címre az értéket. Hol itt a gond?  Köszi szépen azt hittem ez decimálisan működik. 
Köszi szépen !
Meglesem mik ezek ,meg hogy hol lehet kapni.
Üdv mindenki!
Egy meglehetősen zavaró probléma ügyében szeretnék segítséget kérni.Az általam használt pic18f4550-es meglehetősen furcsán kezeli a megszakításokat. Ha egy perifériamegszakítást alacsony prioritásúnak állítok be akkor egyszerűen nem veszi ezt figyelembe, mintha nem is lenne ilyen megszakításom. Ennél is furcsább a magas szintű megszakítások viselkedése. Ugyanis amint engedélyezem akkor a kontroller egyből beugrik a rutinba és többet nem hajlandó "kimászni" belőle. A while(1){...} -be írt programrészek nem futnak le. Ha a különböző funkciókat valahogyan beletuszkolom a magas szintű megszakítás rutinba akkor normálisan működnek. Ezidáig nem találtam megoldást a problémára pedig nem egy fórumot adatlapot errata-t bogarásztam át. Már gyakorlatilag lemásoltam a tankönyvi példákat, de ugyanez a helyzet. Szintén nem változik semmi akár a direkt regiszter kezelést választom akár a C18-as fordító könyvtárait. Nekem már nincs több ötletem, de ha valaki már látott hasonló problémát akkor örömmel venném ha felvilágosítana, hogy mit nem vettem észre. Itt a tesztprogram épp aktuális 4. verziója (a main.h-ban csak a függvénydeklarációk vannak):
A segítséget előre is köszönöm.
Szerintem rosszul szervezed az USART folymatot. A Timer minden megszakításban belép az USART függvénybe, majd jó elidőzik ott(mit keres ott várakozás?) , miközben az USART megszakítás is bejöhet, az megszakítja az alacsonyat, rálicitál egy küldéssel a félbeszakadt adásnak, stb. Ez így minden csak nem jó. Gondold át mégegyszer. Tisztítsd le a programot és egyszerre csak egy lépést próbálj ki!
Hali,
közben én is rájöttem, hogy így nem lesz jó mert nem fog működni a timer megszakítás. Viszont nem ez az igazi probléma. Korábban már kipróbáltam csak a timer-t használva és akkor is ugyanazt műveli. Magas szintűként az aktiválást követően azonnal beugrik a megszakításrutinba akár történt tényleges timer interrupt akár nem,( ha csak a USART-ot használtam akkor is ugyanez volt) . Az hogy van mellette egy USART is ami néha megszólal az gyakorlatilag nem oszt nem szoroz. A baj az, hogy a while(1){...}-ig el sem jut és így csak a HP interruptban tudom kiszolgálni a többi folyamatot.
Ez csak egyetlen módon lehet: ha valami interrupt forrás folyamatosan interruptot generál. Végig kéne nézni, hogy mit mutatnak a státuszflagek.
Nem ártana tisztázni, hogy milyen programnyelvet használsz, mert C18 esetén például #pragma interrupt és #pragma interruptlow kell ahhoz, hogy a fordító tudja, hogy mit kell csinálnia.
Itt találsz mintapéldát működő kétszintű megszakítás használatra.
sziasztok!
Azért írtam ide, mert sürgős segítség kéne nekem és hátha ti tudtok segíteni. http://www.talkingelectronics.com/projects/Elektor/PIC10F222/IgnSta...r.html ezen az oldalon található egy kapcsolás a hozzá tartozó PIC programmal. Nekem annak a programnak az inverze kéne. És még annyi, hogy a nyomógombal csak egy bemenetet használjon. Ennek az átalakításában tud valaki segíteni? :/ Tehát hogy ne keljen még a kapcsolásba egy invertert bekötni, hanem szoftveresen legyen helyretéve. Nagyon megköszönném ha valaki tudna ebbe segíteni :/. Péter
A program MPLAB X v1.60 -val készült, a használt fordító: C18 v3.40, az XC8-at a USART könyvtár hiánya miatt egyenlőre hanyagoltam. Az interrupt függvényeket a C18 User's Guide és a Kónya féle PIC-es könyv alapján írtam.
Erre már én is gondoltam, bár debug alatt egyenlőre csak a PIR1 és az INTCON1 regisztereket figyeltem, majd holnap megnézem a PIR2-t is, de nem láttam hogy más megszakítás aktiválódott volna. (Elvileg minden alapértelmezetten ki van kapcsolva) . De még ha van is másik akkor sem magyarázza semmi azt, hogy az alacsony szintű megszakítások egyáltalán nem hajlandók futni, még akkor sem ha csak azok van engedélyezve. (Korábban például már használtam az A/D konvertert is, igaz, hogy az egy 18f4450-es volt, viszont ott a main loop-ban blokkoló módon kezeltem az interrupt flaget és úgy emlékszem ott nem jött elő ez a probléma, vagy legalábbis nem tűnt föl.)
Melyikre gondolsz? Az RCIF-et elvileg nem is kell kézzel törölni mert automatikusan törlődik ha kiolvassuk az RCREG-et, de már megpróbáltam kézzel is törölni, több helyen is, de ugyanúgy nem lép ki a megszakításrutinból hanem egyből visszaugrik ide:
és ez az amit egyáltalán nem érem.
Ez a "beugrálás" szerintem akkor következik be, ha nem törlöd a jelzőbitet ( pl. az RCREG olvasásával
, de ez nem látszik a mellékelt kódból, vagy csak én nem láttam : a ReadUSART(); csak utal rá, de mi történik belül ?!) ! Mindenképpen hasznos lehet egy szimuláció, én azt szoktam, mikor "nem látom a fától az erdőt" !
Szia!
Át kellene nézni a könyvtári függvények működését. Az USART adó megszakítást kér rögtön az inicializálás után. A megszakítási rutinban akkor kezeled le az adási megszakításkérést, ha a vevő elkészült. Amennyiben nincs mit adni, az adási megszakításkérést le kell tiltani. A RCIF és TXIF biteket a hardware törli, nem kell programból törölni őket. Mennyivel átláthatóbb a program, ha nem használjuk azokat a könyvtári függvényeket, amik csak egy két utasításból állnak és az általuk generált belépési és kilépési kód sokkal hosszabb, mint az az egy-két utasítás, ami az igazi funkció... A hozzászólás módosítva: Márc 12, 2013
Én utolsóként kapcsolnám be a GIEH bitet, és utolsó előttiként a GIEL bitet a megszakítások inicalizálása során. Nem hiszem, hogy ez a gond, csak úgy megelőzésképpen szólok.
Én úgy tudom, hogy a TXIF csak egy jelzőflag ami az adóregiszter foglaltságát jelzi, de most bogarat ültettél a fülembe. Holnap első dolgom lesz ezt kipróbálni. Egyébként nem rossz ötlet a könyvtári függvények átnézése sem, bár amikbe belenézegettem pl.: a DataRdyUSART() csak ennyi:
Tulajdonképpen ugyanaz mint amit egyébként is használnák csak ezt egyszerűbb begépelni(nesze neked lustaság...).
Azt a linkelt kódot ne vedd szentírásnak, csak gyorsan összecsaptam, meg is látszott a futtatás eredményén.... A javított verziójában már benne vannak a kézi flag törlések meg még pár javítás.
Egyébként én itt találtam meg a konkrét függvényeket:C:\Program Files (x86)\Microchip\mplabc18\v3.41\src\pmc_common Idézet: „Én úgy tudom, hogy a TXIF csak egy jelzőflag ami az adóregiszter foglaltságát jelzi, de most bogarat ültettél a fülembe.” Fordítva! Azt jelzi, hogy üres. És ha nem akarsz semmit se küldeni, akkor ugye folyamatosan üres, tehát folyamatosan küldi az interruptot. Ergó le kell tiltani, és csak akkor engedélyezni, amikor van mire várni (foglalt a regiszter ÉS még van küldenivaló), amint a küldésre váró byte-ok száma nullára csökken, megint le kell tiltani.
Annyit még hozzátennék _vl_ mondandójához, hogy ha az adást is megszakításból szeretnéd (ehhez egy circbuffert célszerű alkalmazni), akkor az ISR-ben nem csak TXIF-et, hanem TXIE-t is figyelni kell:
Lehet én vagyok rettenetesen maradi...
Ez a megoldás:
rövidebb, mint ez:
Az utóbbiban két ugrás van... Illetve nagyon erőltetik ezt a XXXbits.YYY formát, de sok helyen egyszerűbb, rövidebb lenne más megoldás:
az
helyett, avagy a
a
helyett... A hozzászólás módosítva: Márc 12, 2013
Jogos. Igazából pont a TX interrupt az amiről a legkevesebbet találtam, de ha tényleg ugyanolyan a hatása mint a többi interrupt flag-nek akkor azt hiszem megvan az elásott kutya.
Viszont még ez esetben is marad a kérdés, hogy amikor ugyanezt a USART kezelést átraktam az alcsony prioritású megszakításfv.-be akkor miért nem volt hajlandó működni. Lenne valamilyen megkötés a perifériák prioritásszintjére vonatkozóan? De akkor meg nem lenne értelme annak, hogy mi állíthatjuk be a szinteket. Nem értem... Na mindegy... a TXIE-s javaslatodat viszont holnap kipróbálom.
Üdv.! Egy gyors kérdés: Ha egy PIC-re rá van kötve egy RTC (I2C-n)és egy SD kártya (SPI-n) jó a következő felállás:
-SD kártya: 3.3V -RTC+PIC: 5V Működik így is vagy célszerű mindennek 3.3V-os tápot adni?
Az SD-kártya nem fogja elviselni, ha 5V-tal megküldi felé a PIC a kimeneteit, az 5V-ról üzemelő PIC bemenete pedig nem biztos, hogy 1-nek veszi, ha csak ~3-3.3V-ot kap.
Szóval én a helyedben biztosan 3.3V-ról üzemeltetném az egészet. Lehet persze mindenféle szintillesztésekkel szórakozni, a kérdés inkább az, hogy van-e értelme, ha mindenki mehetne egy tápról. |
Bejelentkezés
Hirdetés |
