Fórum témák
» Több friss téma |
Sziasztok!
PIC18F4550 belső EEPROM-ját szertném írni, de nem sikerül ;( Akódom, melyet a PIC datasheet-je alapján írtam:
Sajnos az eepromban nem jelenik meg a kívánt érték! Debuggolva a függvényt a while után WRERR értékeWREN értéke 1, atöbbi bit 0 EECON1-ben. A dokumentáció számomra kétértelmű: Idézet: -> ezek szerint sikerült az írás, bár esetemben nem...„Note: During normal operation, the WRERR is read as 1” Idézet: -> sajnos szerintem ez a helyzet.„Reegister EECON1: WRERR 0:the write operation completed, 1: write operation is prematurely terminated” Még egy kis bonylítás: Idézet: -> pedig nálam 0 mindegyik„Note1: When WRERR occurs, the EEPGD and CFGS bits are not cleared” Nagyon nem értem, hogy mi a fene lehet! Van esetleg ötletetek? Mi lehet a baj a kóddal, esetleg kimaradt vmi? Ugye az EEPROM első bájta a 0-nál van?
Nehezen olvasható a kód és már nem tudom kivenni, szóval ide csatolom (bocsi):
EECON2=0x0AA, itt van egy felesleges nulla. Nembiztos, hogy ez a hiba, de ha emiatt esetleg plusz kódot tesz be a fordító, akkor emiatt nem megy az EEPROM írás.
Szerintem nem figyeled a PIR2.EEIF flegget!
Ez árulja el neked, hogy mikor is van vége az írásnak. Ez nálam így néz ki asm-ban! CHKWRT: btfss PIR2,EEIF ;wait until bit 4 of PIR2 is set goto CHKWRT bcf PIR2,EEIF ;clear bit 4 of PIR2 return
A GIE tiltását én így csinálnám:
if (INTCONbits.GIE) gie=1; INTCONbits.GIE=0; ... if (gie) INTCONbits.GIE=1;
Az teljesen független, hogy használod-e a GIE regisztert!!
Ha meg van a dokumentációd akkor olvasd el a PIR2 regiszter használatát!
0x0AA-t javítottam, GIE-t átírtam sajnos nincs változás.
Az EEIF figyelése egy előző verziómban már szerepelt, most beleírtam így:
Ekkor a program a EEIF-es whilenál várakozik... A PIR2 doksiolvasást még nem tettem, de mindjárt fogom! thx!
Az adataim alapján Te nem eepromot írtál, hanem frissítettél.
A dokuban felette található az írási rutin. Annak a legvége foglalkozik a PIR2.EEIF -el. Ott a EEcon1.WR-t csak állítani kell. A rutin legvégén a PIR2.EEIF -et törölni kell!!
Már megint lehet, hogy a C okozza a gondot. Az adatlapban világosan le van írva:
Idézet: „The write will not begin if this sequence is not exactly followed (write 55h to EECON2, write 0AAh to EECON2, then set WR bit) for each byte. It is strongly recommended that interrupts be disabled during this code segment.” Azaz pontosan azt a szekvenciát kell használni, amit ők írnak a példában:
Itt a pontosság nyílván arra vonatkozik, hogy a 0x55 és a 0xAA között ha túl sok idő telik el, akkor nem történik meg az írás engedélyezése. a 4550 doksijában ugyan nem találok rá utalást, de erős a gyanúm, hogy ez egy nagyon szoros, utasításciklusszámlálóval vezérelt dolog, és ha adott számú cikluson belül nem történik meg az írás, akkor nem lesz jó (ez bizonyára az EEPROM véletlen, programhibákból történő felülírásának megakadályozására lett kitalálva). Egészen biztos vagyok benne, hogy az interruptok letiltását is pont emiatt javasolják. A fő kérdés az, hogy a C fordító azokat az értékadásokat mire fordítja le, hány "felesleges" utasítás van köztük. Egyébként a legtöbb PIC-es C nyelvben szokott lenni könyvtári függvény az EEPROM kezelésére, valószínűleg pont a fent részletezett problémák elkerülésére. Idézet: „Az teljesen független, hogy használod-e a GIE regisztert!! Ha meg van a dokumentációd akkor olvasd el a PIR2 regiszter használatát!” Ugyanezt javaslom neked, csak ezúttal kicsit figyelmesebben csináld! A GIE-t azért kell tiltani, mert ha nem futnak le a
utasítások pontosan ebben a sorrendben, megszakítás nélkül, akkor nincs EEPROM-ba írás. A másik, hogy az, hogy a WR vagy az EEIF bitet figyeljük, az teljesen egyenértékű. A GIE egyébként nem regiszter, csak egyetlen bit az INTCON regiszterben.
A sejtésem nekem is ez. Öszintén szólva próbáltam ASM kódot beilleszteni, de a drága hi-tech doksival ellentétben nem akarta elfogadni se a movlw _addr ,se a movwf _EEADR jellegű dolgokat.
Ezek szerint ezen a szálon kellene továbbballagnom...
Jogos amit írsz, köszönöm a javítást!
 Ettől fuggetlenül a PIR2.EEIF--et kell figyelni. Ja és a végén törölni mert nem lessz írás!
Próbáld így:
Ha így sem megy, akkor csatold a fordítás után kapott .lst fájlt.
Szvsz az EEIF-nek az írás műveletéhez nem túl sok köze van, azzal csak akkor kell foglalkozni, ha nem megvárni akarod az írás befejeztét, hanem majd interrupttal fogsz reagálni rá. A WR bitnek viszont kutya kötelessége törlődni, ha az írásnak vége. Az EEIF-ről csak annyit így, hogy azt a felhasználónak kell majd szoftverből törölnie, ha egyáltalán használja valamire.
Juteszembe, ez most Hi-Tech fordító, vagy C18 fordító? Mert az alapján, hogy INTCONbits és EECON1bits, az alapján C18, viszont akkor ne a Hi-Tech doksiját nézegesd hozzá, hanem a C18 saját doksijait.
Az általad írt kódra ezt kaptam:
Error [192] D:\Dokumentumok\PIC\Projects\eeeee\jolesze.c; 84.0 undefined identifier "_asm" Error [195] D:\Dokumentumok\PIC\Projects\eeeee\jolesze.c; 84.1 expression syntax Error [312] D:\Dokumentumok\PIC\Projects\eeeee\jolesze.c; 90.1 ";" expected Ha a TAG-eket kijavítom #asm és #endasm -re, akkor: Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s60s.; 789. undefined symbol "EECON2" Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s60s.; 798. undefined symbol "EECON1" Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s60s.; 798. undefined symbol "WR" .lst fájl csatolva (kicsit hosszú, mert az I2C-s hőmérő dolgai is benne vannak. Ha akarod küldök egy letisztázott, csak az eeprom dolgával kapcsoltos fájlt. ?).
Hi-tech a fordító az fix.
De pl INTCONbits látszólag működik. Legalábbis nem kiabál a fordító és debuggolva is úgytűnik. Vagy csak tévedek?
Frissítés:
Ez működik:
Viszont a BSF _EECON1, _WR -nél az _EECON1-el és a _WR-el is baja van.
Itt valami nagyon nem stimmel, mert a listing fájlban az EEADR és EEDATA regiszterekkel nemis csinál semmit. Csinálj egy teljesen lecsupaszított programot, amiben csak ez az eeprom írás van, és utána egy végtelen ciklusba fut.
Illetve javasolnám, hogy 18F esetén inkább a C18 fordítót használd.
OK csinálok egy "tiszta" kódot.
A fordításhoz hi-tech PICC18 9.63-at használok. Erre gondoltál vagy a microchipes toolra? Számomra a hitech szimaptikusabbnak tűnt! Melyik miért jobb?
Ennek a kódnak már elvileg mennie kellene. Próbáltad?
A Microchip C18 fordítójára gondoltam. Annakidején elsőre a HI-TECH PICC18 nekem is szimpatikusabb volt, de a C18-at sokkal többen használják, emiatt sokkal több mintakódot találni rá. Illetve az sem elvetendő, hogy a C18 gyári, valamint a student edition ingyenesen használható.
Nagyon furcsa, mert az előbb _EECON2-t elfogadta. Most már nem!
 Executing: "C:\Program Files\HI-TECH Software\PICC-18\PRO\9.63\bin\picc18.exe" --pass1 D:\Dokumentumok\PIC\Projects\eeprom\main.c -q --chip=18F4550 -P --runtime=default --opt=default -g --asmlist "--errformat=Error [%n] %f; %l.%c %s" "--msgformat=Advisory[%n] %s" "--warnformat=Warning [%n] %f; %l.%c %s" Executing: "C:\Program Files\HI-TECH Software\PICC-18\PRO\9.63\bin\picc18.exe" -oeep_project.cof -meep_project.map --summary=default --output=default main.p1 --chip=18F4550 -P --runtime=default --opt=default -g --asmlist "--errformat=Error [%n] %f; %l.%c %s" "--msgformat=Advisory[%n] %s" "--warnformat=Warning [%n] %f; %l.%c %s" HI-TECH C PRO for the PIC18 MCU Family (Lite) V9.63PL1 Copyright (C) 1984-2008 HI-TECH SOFTWARE (1273) Omniscient Code Generation not available in Lite mode (warning) Advisory[1233] Employing 18F4550 errata work-arounds: Advisory[1234] * Corrupted fast interrupt shadow registers Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s18o.; 282. undefined symbol "_EECON2" Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s18o.; 291. undefined symbol "_EECON1" Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s18o.; 291. undefined symbol "_WR"
Kisebb-nagyobb keresgélés után kiderült, hogyha az ember include-olja a htc.h -t, akkor alapból definiálva lesz egy
Betettem a programomba; tényleg le is fordul, viszont mivel a HW most nincs nálam kipróbálni csak holnap tudom. Remélem menni fog!  ps: egy apró kérdés: nincs vmi jó szoftver, amivel ilyen esetben szimulálni lehetne a pic-et? Pl: kiválasztanám, hogy milyen PIC-em van, betölteném a lefordított hexát, aztán lehetne vele játszadozni pl virtuális szkóppal, logikai analizátorral ránézni a lábaira,miegymás...Nem hiszem el, hogy nem létezik ilyen, a kérdésem csupán az, hogy halandó ember számára is elérhető-e és mi az? 
Valami Proteus nevű cuccot szoktak itt a fórumon emlegetni, amivel áramkörben lehet a PIC-et szimulálni. Én még sosem láttam a programot, mert hamár áramkör, akkor inkább összelógatok egyet a teszt céljából próbanyákon, vagy már a kész áramkörön fejlesztek. Az ilyen szimulátorok kezdetben érdekesek, de nem tűnik valami elterjedtnek komolyabb fejlesztőknél.
Az MPLAB SIM nagyon jól használható, ha az ember megtanulja használni. A View->Simulator Trace és Simulator Logic Analyzer menűpontokat ajánlom figyelmedbe. Erre az EEPROM írásra kíváncsi leszek, mert amit utoljára feltettél kódot, annak mennie kellene a listing alapján.
Röviden:
 Hosszabban: az előző hozzászólásomban említett, gyárilag mellékelt macro szintén nem működik. A csatolt kép (Pic_eepromwr_prgmem_macro.jpg) szerinti kódot keletkeik, amely természetesen nem felel meg a specifikációnak. A "nyers memóriacímeken" felbuzdulva gondoltam, majd jól kitolok a világgal és beleírtam ezt a saját függvényembe:
És láss csodát: megint nem megy!!!  A keletkezett kódot lásd a másik csatolt képen (Pic_eepromwr_prgmem_asm.jpg). Hogy a f*szba csinál a fordító a 0xfa7 címből 0xa7-et??? Komolyan mondom megőrülök! (a kódban próbálkoztam már a kis és nagybetűk cseréjével is) Számomra tök új ez a PIC-es világ, még csak most ismerkedek vele, de nehezen fogadom, hogy ezzel ennyi baj van és nem bírnak a gyártók normálisan megcsinálni dolgokat (informatikusként c++,c#,php,stb-hez vagyok szokva)! ááááá!
és a képek:
Hogyan lehet olyan szépen kinéző, rendezett kódrészletet beszúrni a hozzászólásba? Nekem még valahogy soha nem sikerült?
Miért nem próbálod meg a "MOVWF 0xA7,ACCESS" formával címezni az SFR-eket? A 0xA7 helyére jobb lenne az SFR szimbolikus nevét írni, ha azt valamilyen módon támogatja a fordító.
|
Bejelentkezés
Hirdetés |
