Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
RFM12B rádiós adóvevő modullal játszom. Megy szuperül vele az adás, a vétel, ezek felváltva, a legnagyobb (115kbps) sebességen, hardveres SPI-al. Tök jó. Viszont!
A küldés úgy működik hogy az nSEL lábát (gyakorlatilag chip select) alacsony szintre tesszük, majd várunk amíg ő az SDO lábát amolyan válaszként H szintre emeli. Ezzel jelzi hogy ráér, lehet vele beszélgetni. Ez után küldünk a modulnak SPI-on egy 0xB8-at, majd az elküldeni kívánt bájtot. Ezt követően az RFM12 elmolyol vele míg kitolja az éterbe a biteket. Addig ő el van foglalva. Ha ismét ráér és lehet vele bármit csinálni (mondjuk a következő bájtot beletolni), akkor azt ismét az SDO lábának H szintre emelésével jelzi. (Már ha előtte L-re kapcsoltuk az nSEL-t.) Ez jól látszik a gyártó (HopeRF) gyári kódjában: Bővebben: Link Konkrétan erről a függvényről van szó:
Bár ez a függvény elég kreténül van megoldva és van benne egy pár felesleges dolog, ezért én írtam egy sajátot ami átláthatóbb illetve csak az van benne ami kell:
Mint írtam; az SPI hardveres, a PIC SPI1 perifériája hajtja. Tehát a PIC azon lábaira, melyekre az RFM12 van kötve, azokra az SPI1 van odakapcsolva (PPS). Azonban szeretném átírni az egész adási részt úgy hogy ne egy szimpla függvény legyen amiben pollinggal figyelem az SDO lábat (while(!SDO) Nop();) hiszen így értékes utasításciklusok mennek veszendőbe. Ehelyett megszakításban szeretném figyelni az SDO lábat hogy mikor vált H szintre, hogy aztán csak gyorsan beletegye a PIC a következő küldendő bájtot az SPI1-be. A baj az, hogy ehhez valamelyik INTx perifériát oda kellene kapcsolnom arra a lábra amelyre az SPI1 periféria SDI-je már oda van kötve.  Nyilván nem lehet két periféria egy lábon... Szóval marad az hogy INTx-et odakapcsolom a lábra, várom míg megszakítás jön majd gyorsan kicserélem az SDI-re? Lehet ilyet csinálni? Nem tart esetleg sok időbe mire az egyik periféria lekapcsolódik a lábról, majd a másik vissza rá? Vagy van esetleg erre másmilyen megoldás?
Az nem tart sokáig, hogy valami lekapcsolódjon a lábról, és egy másik rá, viszont azt próbáltad, hogy egyszerre engedélyezed mindkét perifériát? Mert még az is lehet, hogy akár egyszerre is aktív lehet mindkettő
Most hogy belegondolok elvileg lehetséges két (vagy több) perifériát kapcsolni egy lábra. Hiszen a perifériákhoz kell lábat kapcsolni, nem lábhoz perifériát. Hmm... kipróbálom mit csinál.
Mostanra sikerült kipróbálnom, működik!
 Szóval lehet egy lábra több perifériát bekapcsolni.
Megjelent az MpLab X 3.10 verziója. Ez lesz az utolsó, ami támogatja az XP -t.
Idézet: „NOTICE: Microsoft Windows XP Professional SP3 will no longer be supported after MPLAB X IDE v3.10.”
Sziasztok!
24EP512GU814 kontrollerre az Auxiliary területre bootloadert írtam, amit leteszteltem, minden rendben működik, kiírja a General Segment-be a programot. De mikor bekapcsoltam a kódvédelmet, _FAS(APL_ON) nem indul el a program. Beszúrtam a 2-3. sorba TRISF = 0b0000000000000000; LATFbits.LATF1 = 1; -t, de eddig se jut el a program. Tehát ha a lenti kódban APL_OFF -ot APL_ON -ra cserélem, akkor nem jut el a program LATFbits.LATF1 = 1; -ig sem.
Itt már Hp41C fórumtársnak volt gondja a kódvédelemmel, de ha jól értem nem pont ez. Valamint az is érdekes, hogy az az állapot, amiben nekem rendesen működik, szerintem ellentmond ennek: Idézet: „Auxiliary Segment Key bits These bits must be set to ‘00’ if AWRP = 1 and APL = 1. These bits must be set to ‘11’ for any other value of the AWRP and APL bits. Any mismatch between either the AWRP or APL bits and the APLK bits (as described above), will result in code protection becoming enabled for the Auxiliary Segment. A Flash bulk erase will be required to unlock the device.”
Errata-t nezted? 1-2 eve mar volt ezzel gond, de akkor meg nem volt benne az errata-ban. Talan mostanra irja....
Nekem annyi volt a gondom vele, hogy a törölt példányban a AWRP = 1 és APL = 1 esethez az APLK1.0 nak 00 -nak kellene lennie. Ha ez igaz, akkor hogyan programozható be más kombináció. Megoldódott.... A konfiguráció szavak írása előtt egy törlés is lezajlik ld. időzítések.
Egy másik apró megjegyzés az adatlapból a FAS regiszterre: Idézet: „This register can only be modified when code protection and write protection are disabled for both the General and Auxiliary Segments (APL = 1, AWRP = 1, APLK = 0, GSS = 1, GWRP = 1 and GSSK = 0).” A hozzászólás módosítva: Szept 11, 2015
Csak ennyit találtam:
Idézet: „If code or write protection is enabled on either the General Segment or Auxiliary Segment, neither segment can be read by the programmer. Code or write protection is enabled for the General Segment when the GSS (FGS<1>) or GWRP (FGS<0>) bits are ‘0’. Code or write protection is enabled for the Auxiliary Segment when the APL (FAS<1>) or AWRP (FAS<0>) bits are ‘0’.” De ha jól értem -az egyébként rossz angolommal- ez csak annyi, hogy bármelyik szegmens kódvédelmét bekapcsolom, az a másikra is érvényes. Amúgy honnan az infó hogy 1-2 éve volt vele gond? Ha tudnál linket, megnézném, hátha van ott valami. A hozzászólás módosítva: Szept 11, 2015
Ez logikus nem? Csak akkor módisítható a FAS, ha a kódvédelem mindkét szegmensben ki van kapcsolva. Vagy rosszul értem?
(Amúgy biztos hogy én csinálok valamit rosszul, mert nem valami különleges dolgot várok azzal hogy kódvédett program elinduljon, ha ez nem működne, biztos tele lenne vele a net.) Most jut eszembe, hogy amikor elkezdtem a bootloadert írni, nehezen tudtam kikényszeríteni a fordítóból, hogy mindent az aux területre fordítson. Ha az MPLABX project properties-ben állítottam át, akkor az inicializáló részt mindig a general segment-re fordította, majd utána adta csak át a vezérlést az aux területre. Végül .gld -t kellett szerkesztenem:
Ez normális így? A hozzászólás módosítva: Szept 11, 2015
Azon meditáltam el, hogyan programozza be a programozó a konfigurációs regisztereket....
Az FS alacsonyabb címen van, mint a FAS. Ezek szerint előbb kell beállítani a FAS regisztert aztán az FS -t????
FS mint FGS? Arra gondolsz gondolom. Lehet hogy a programozási szekvencia alatt mindegy a sorrend, csak pl. a Vpp megszűnése után él a védelem.
Idézet: Dolgoztam egy cegnel, ahol PIC-eket hasznalnak(tunk). Miutan eljottem toluk, meseltek, hogy (az akkor uj) dsPIC33EP-s PIC-ekkel szivas volt az AUX segmensbe tett bootloaderrel, ha irasvedve volt. De mar nem emlekszem, hogy pontosan mi volt a gond. Megkerdezem a programozo sracot. „Amúgy honnan az infó hogy 1-2 éve volt vele gond? Ha tudnál linket, megnézném, hátha van ott valami.” Idézet: Hálás köszönet.„Megkerdezem a programozo sracot.” Amit a .gld fájllal műveltem, az szerinted normális? Ez a módja annak hogy az aux segmensbe tegyem a programot? Idézet: Nem tudom, mar 4 eve nem foglalkozom PIC-ekkel, nem vagyok benne napi szinten, es a PIC-nel ez az egesz linkeles egy nagy mágikus , ahhoz kepest, ahogy a gcc magatol linkelne. Legalabbis par eve meg igy volt. „Amit a .gld fájllal műveltem, az szerinted normális? Ez a módja annak hogy az aux segmensbe tegyem a programot?” A hozzászólás módosítva: Jan 24, 2016
Ezt olvastam, de nem találtam a rám vonatkozó részt. Vagyis hogy mit csinálok rosszul.
Mondjuk az is igaz, hogy néztem vagy fél órán keresztül a 23-1 táblázatot, de még mindig nem értem... hogy mit akartak vele mondani. Közben kipróbáltam azt, hogy a general segment kódvédelmét kapcsoltam be, és az errata-nak megfelelően nem olvasható ki egyik segment sem. Ekkor végre elindul a bootloaderem (az aux-ban) rendben, viszont nem tudja írni/visszaellenőrizni a kódot a general segment -ben... 
Valóban van errata-ban erre vonatkozó rész, de ez még nem oldotta meg.
Idézet: Annyit mondott a srác, hogy ha az AUX területet levédik, akkor nem tudja írni a General flash-t az AUX-ban futó program (a bootloader). Nem találtak rá semmilyen megoldást. „Megkerdezem a programozo sracot.”
Köszönöm hogy megkérdezted!
Én eddig két lehetőséget találtam: 1: AUX write protected -et kell csak bekapcsolni, ekkor errata alapján (és a valóságban is) külső programozóval nem olvasható egyik segment sem, viszont így szépen fut a bootloader aux -ban, és tudja írni generalt. 2: General segment code protect bekapcsolva, ekkor kívülről szintén nem olvasható egyik sem, és aux -ban lévő bootloader úgy tudja írni general-t, hogy kitörli az egészet, megírja, és utána vissza kapcsolja general segment code protect-et. Idézet: „Nem találtak rá semmilyen megoldást.” És ilyenkor mi van? Áttérnek más mc -re? Amúgy tényleg bekerült errata-ba, hogy aux code protect esetén egy reset után nem indul el a program aux területen.
Muszáj most sajnos egy kicsit assembly-ben programoznom és belefutottam egy hibába:
Lefoglaltam a memóriában 12db bájtot:
És van egy ilyen rész a programban:
Ha az FSR0 mutató által mutatott bájt 0b11111111, akkor szépen rámegy mindegyik bsf-es sorra a PIC, és 1-be is állítja a megfelelő biteket. Kivéve az utolsó kettőt, azaz a TUCHEL_tabla+10 és a TUCHEL_tabla+11 regiszterek megmaradnak úgy ahogyan voltak. Az első ötletem az volt hogy lehet hogy ez a legfelső két regiszter már egy másik bankban van ezért beraktam elé egy bankváltást és átírtam azt is hogy ne 0x800-tól kezdődjenek hanem 0x750-től. De nem változott a helyzet. Arra tudok csak gondolni hogy esetleg a fordító nem tudja értelmezni a "+10"-et és a "+11"-et, talán mert két számjegyűek. Hiszen "+9"-ig működik. Vagy talán nem decimálisan értelmezi hanem hexadecimálisan? De akkor hibát jelezne a fordító! Mindenesetre kipróbáltam hogy átírtam őket "+1A"-ra és "+1B"-re. Érdekes módon lefordította így is, de nem működött így sem a program. Megoldottam úgy hogy adtam mind a 12 regiszternek külön nevet:
De azért kíváncsi lennék miért nem jó a fordítónak úgy. A hozzászólás módosítva: Szept 15, 2015
a btfsc INDF0,0 elé.
helyett, ha nem akarod, higy a radix -tól függjön:
A hozzászólás módosítva: Szept 15, 2015
Sziasztok, újra elakadtam!
Van 3 egyforma áramkörön PIC24EP256MU806 -al, ebből 1 már hetek óta felprogramozva működik, kettőt most élesztettem volna föl, de Pickit3 mindkettőre azt mondja hogy: Idézet: „Target Device ID (0x2100000) does not match expected Device ID (0x18610000).” Természetesem bekötés, PGC,PGD,MCLR tápok rendben, 100n-k, 10u tank. Kipróbáltam, hogy rátettem Pickit3-at a már működő darabra, és indítottam egy read memory-t. És erre is azt mondja hogy 0x2100000 az ID -je. Pedig ezt hetekkel ezelőtt többször felprogramoztam, debuggoltam, akkor simán ment, nem nyúltam hozzá azóta. Ekkor gondoltam hogy a Pickit3 -al lesz valami, rátettem egy másik áramkörre, amiben PIC24EP512GU814 van, de azt simán felismerte... na innentől nem tudom mit csináljak. Honnan veszi ezt a 0x2100000 ID-t? Ha valami nincs rendben mindig 0x0000 -t szokott kiolvasni. Próbáltam MPLABX, IPE, és IDE v8.92 -alól is. Mind azt mondja hogy neki 21...  Megőrülök!
PIC24EP256MU806 ??? Nem dsPIC33EP256MU806 (DeviceId = 0x0x185A)? PIC24EP256MU806 nincs, csak PIC24EP256MU810 és PIC24EP256MU814.
De igen, dsPIC33EP256MU806, elírtam, bocsánat. Utoljára a PIC24EP512GU814 -et próbáltam, és az sikerült, azzal kevertem.
De DeviceId = 0x0x185A -t én nem látok a családban. dsPIC33EP256MU806 = 0x1861 A hozzászólás módosítva: Szept 19, 2015
f883-akkal volt hasonló jelenségem. ICD3, PCKIT2 ill.3 bizonytalanul ismerte fel, hol égette, hol nem,hol debugolta, hol nem. RB3 10k-val a földre megoldotta. (Be akart low voltage programming mode-ba ugrani.)
Sajnos ez itt nem fordulhat elő, mert ezeken a 16 biteseken nincs ilyen opció.
Azóta kipróbáltam, hogy áttértem másik programozó lábakra, PGD1-PGD3, de mindenhol ugyan az a helyzet, ID 0x2100000.
Azt írtad minden rendben van a lábakkal de nem részletezted. MCLR pullup 10k?
Ez gyakran szokott gondot okozni.
Igen, az ellenállás megvolt.
Most lerövidítettem a Pickit3 - PCB közötti kábelt, és jó felismeri. Persze eddig is ezt használtam, ugyan ezen a PIC-en, tökéletesen működött egy héttel ezelőttig. Illetve a 24EP512GU814-et még most is stabilan felismerte, programozta. A 33EP256MU806- ot meg már nem.. De legalább jól megszívattam magam. Így, ismerve a megoldást, az amatőr kérdések között kellett volna feltennem a kérdést. A hozzászólás módosítva: Szept 21, 2015
Milyen hosszú volt előtte, és most milyen lett, ami jó lett?
|
Bejelentkezés
Hirdetés |
RIPLL Start with internal fsc and low-power osc.
