[elektro] PIC16F883 EEPROM adatvesztés

[Móczik Gábor]

2011.11.12. 15:39 keltezéssel, hg12345 írta:
> Hát nem tudom, én még sohasem vártam meg mig az adat beíródik, kiadom a parancsot és a program fut tovább, inkább írás elött várok mig szabaddá nem válik az eszköz. Ha vársz ellenörzésre akkor tényleg 3-5ms időt vesztesz minden beírásnál, vagy egyes EEPROM-ok irás közben is olvasható?.

Attól függ, de nálam elég ritka, hogy csak egy byte-ot kell írni, tehát 
úgyis meg kell várni.

Persze lehet interruptban nyomatni ahol erre a kihegyezett tempóra van 
szükség, de ott már endurance probléma is felmerül, lényegesen 
bonyolultabb témakör, valószínüleg máshogy célszerűbb megoldani.

> Egy párhuzamos LCD parancs kiadása után is vársz mig szabaddá válik az eszköz?  Várakozol a busy jelre minek, elöbb utóbb biztos végrehajta :-()

Igen, várakozok, mert általában nem 1 karaktert kell kiírni, és addig 
úgysem folytathatnám. Persze a pre-check valóban célszerűbb, érdekes 
hogy pl. UART-nál eleve úgy csinálom, itt meg eszembe sem jutott. :-)

Én 1 taszkos rendszerben úgy csinálom, hogy szinte csak az user 
interface vagy az elég lassú eseményeket (amibe belefér az LCD vagy 
miegymás késleletése) vezérli a főprogram, ami gyors, határidős és 
determinisztikus, az megy minden ISR-ben, állapotgépekkel.

Általában olyanok a programjaim, hogy a main-ben egy delay() kiadása 
szabadon megtehető, a fontos eseményeket egyáltalán nem érinti.

> Az ellenörzés.... mit csinálsz amikor leállítás közben kiderül, hogy nem tudod kiírni a backup tartalmat, időd se energiád sincs az ismétlésre!.... A validitás visszaolvasáskor megadja hogy mit kell csinálni, ha nagyon fontos az adat akkor hiba javító kód..... Ezt nem lehet kikerülni varázslással....

Ha ilyet kell csinálnia az eszköznek, akkor biztosítani kell, hogy 
_legyen_ energiája. Be kell tervezni egy akkora puffert, ami bőségesen 
elég ahhoz hogy elmentse a leállításkori státuszt. Ha elveszett a táp, 
azt a puffer előtt kell érzékelni.

Emellett megoldható, megoldandó, hogy ha közben visszajön a táp, akkor 
is egy szakszerű reset ciklus menjen végbe. Nyilván nem csak az MCU-t 
érinti, ezt szoftver úton is lehetne resetelni, de a hardver elemeket 
nem biztos, tehát azt kell megoldani, hogy ha már egyszer a leállítási 
státuszba került a rendszer, akkor vegye is el a saját betápját, úgy 
hogy rendesen le is álljon.

Helyzettől függ, hogy kell-e ez vagy sem, kézzel kelljen újraindítani, 
vagy egy időzítő (független hardver rész) újraindítja, stb...

Ahol kell, meg lehet ezt szakszerűen oldani, jó is néznénk ki, ha a 
véletlentől függene, hogy ki bírjuk-e írni a mentést vagy sem...

> A nagy varázslások nem adnak megoldást, csak megnyugtatják a tervezőt addig mig benem üt a crack!

Ebben egyetértünk.

> Amikor a RESET-tel kéne már valamit csinálni (leállítani a uC) az már nagyon nagy baj.... még elötte elkell kapni a hibát.

Igen vagy nem, attól függ. :-)
Pl. egyszerűen lekezelhető vele, hogy a processzor RESET-ben áll, amég a 
táp nem jelez, hogy minden tápfesz jó, ekkor elengedi a RESET-et. Persze 
lehet szoftveresen, de van mikor ez egyszerűbb.

Nem utolsósorban, a fejlesztést nehezítheti, ha nem lehet hardveresen 
RESET-elni a procit. Fejlesztés idejére persze meg lehet hagyni a 
funkciót, de az a véleményem, hogy ha ezen múlik egy projekt stabil 
működőképessége, ott már komoly baj van...