[elektro] PIC16F883 EEPROM adatvesztés
hg12345
hg12345 at freemail.hu
Sat Nov 12 07:42:32 CET 2011
"Móczik Gábor" <pm_levlista at progzmaster.hu> írta:
>2011.11.10. 11:40 keltezéssel, hg12345 írta:>
> és elvesztettél 5ms futási idöt minden beírásnál....>
>
Hát egy belső eeprom olvasás azért 1 ciklus alatt lezajlik.>
Na jó, ki kell adni hozzá mondjuk 3-5 utasítást, de nem 5ms...>
Elnézést!!!! "beírás" nem kiolvasás, és a beírást senki nem tudta megcsinálni egy óra ciklus alatt! :-)
>
Mindenesetre én sem ezt csinálnám, úgyse ez lesz hibás, hanem hogy a >
háttérben megváltozik a tartalom.>
Szintén, nem ezt csinálnám :-) Amúgy az EEPROM és FLASH eszközök tárolási problémájának (endurance és hiba javítás és ellenörzés) optimális megoldása a PAGE méretű cache.... Ezzel nem csak az írás gyorsul, hanem a külső soros E2/FLASH olvasási sebessége is nagyságrendeket. A program szinten nem kell foglalkozni az biztonsággal, mert a kezelési szinten megoldod.....
>
Volt nálam egyszer egy mérőeszköz, ami 16 bites eepromban tárolt 11 >
bites adatokat, a maradék 5 bit volt a hamming kód. Házilagosan (nem a >
gyárban) közel előállíthatatlan kalibrációs adatok, tehát fontos volt >
hogy hiba esetén helyre lehessen állítani.>
>
Kerestem annak idején, de nem találtam egy jó leírást, hogy hogyan kell >
egy ilyen hibajaító kódot és a hozzá való algoritmust megtervezni.>
Ha valaki tudna linket, az nagyon hasznos lenne.>
>
Érdekes terület ez a hibajavítás. Ha van ugyanabból az adatból egy >
másolat, akkor checksum alapján el lehet dönteni melyik a jó, és azt >
használni. Ha mindkét blokkban van 1 bit hiba, akkor viszont már >
fogalmad sincs melyik a helyes. Ezzel szemben ha ugyanekkora >
pocsékolással egy 8 bites adathoz 8 bites hibajavító kód kerülne, akkor >
több bit hibáját is javítani lehetne, méghozzá byte-onként!!!>
>
Ez viszont sem jó semmire, ha elromlik mondjuk 1 byte (vagy több), >
teljes egészében. Vannak olyan kódok (pl. Reed-Solomon), amik ilyen >
burst hibákkal is elbírnak. Persze valamit-valamiért, ezek már elég >
komplex algoritmusok...>
>
> A misztikus EEPROM hibák a berendezés kikapcsolásakor keletkeznek (99%)>
>
Vagy bekapcsoláskor. De abban egyetértünk hogy táp anomália igen gyakran >
okozza.>
>
Pl. USB-s készülékek összedugásakor ha nem hálózatfüggetlen cuccok, és >
földpotenciál különbség van, gyakran elő szokott forddulni.>
A bekapcsolást kicsit egyszerűbb kézben tartani mint a kikacsolást, amikor már a uC nincs energiája, ill nem tudod meddig van.
Amúgy a be/ki kapcsolás nagyon hasonló problémákkal küzd, pl.: kikapcsolás közben is leállítás után (hálózati kapcstáp) többször újra indul a készülék, mert a táp kipréseli magából az utolsó elektronokat, ilyen újra induláskor nem megfelelő inditási szekvenciákál szokot probléma lenne. De ugyan ez igaz vissza felé is.
>
----------------------------------------->
elektro[-flame|-etc]>
More information about the Elektro
mailing list