[elektro] PIC16F883 EEPROM adatvesztés

[hg12345]

"Móczik Gábor" <pm_levlista at progzmaster.hu> írta:
>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.>


Nagyon kevés olyan alkalmazás van, ahol elegendő 1byte adat tárolás :-().
Az IT se megoldás, mert teljesen mindegy hol vársz IT-ben vagy polling szinten.
((((Az IT kevésbé szerencsés, leginkább sleep-ben célszerű várakozni ))))

Erre van egy nagyon jó megoldás ami EEPROM és FLASH kezelés teljesen megoldja!
>
> 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.>

a delay() vagy softwares időzítést probálom mindenütt elkerülni, azonkivül hogy soha nem lehet pontos egy IT-s rendszerben.....

>
> 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.>

Hát ez azért nem ennyire egyszerű. Hálózati táp esetén a puffer a hálózati oldalon van. Ennek a meglétének figyelése több helyet igényel mint a szekunder oldal figyelése, ráadásúl a szekunder oldali táp figyelés nem végleges adatot ad! Ezért miután leállítás megtöténik, a fogyasztás csökkenés miatt a táp helyre áll és a rendszer elindul, ezt ki kell szürni, de erre a HW RESET nem jó!

>
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...>

A beépített full HW watchdog-nál erre a feladatra nincs jobb.
>
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...>

Ez természetes.

>
> 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...>

Szerencséré már sokat változott a uC világ, manapság nem igen kell számolni a lábakat :-), ráadásul a debug felületek is egyre kevesebb lábat igényelnek, nem úgy mint a tápellátás. Most konnyen megoldható, hogy a debug felület fejlesztés után is szabadon maradjon....

Hozzáférek olyan berendezésekhez, amivel a zajos környezeti stabilítást lehet vizsgálni.
Egy megfelelően kiépített reset láb, befordítása után  zavar türő képesség min több mint egy nagyságrendet javul... Nem mindegy 500V 8/20us zavar érzékenyéség helyett 4000V 8/20us jelre se érzékeny készülék....  

Nem csak a plusz láb miatt eröltetik a reset láb belső feldolgozását......


>
----------------------------------------->
          elektro[-flame|-etc]>