[elektro] DataFlash logger

[Szima Gábor]

On Wed, 3 Mar 2010, vfx wrote:

> Így nem kell a head és tail pointereket tárolni, elég induláskor
> végigsöpörni az extended területen és megkeresni azels? FF-byte-ot.

Kidolgoztam egy stabilnak tuno eljarast, most tesztelgetem "elesben" (uC 
+ Flash).
A PC-s szimulacio eleg jo eredmenyt adott.
A szamitasok szerint megoldhato egy 16/32/x Mbit-es DF-be mindenfele 
tapfigyeles, backup elem + RAM/FRAM nelkul egy olyan LOG-olas, ahol:

  - tap megszunesekor nem lesz hibas adat
  - maximum az utolso 1..2 masodperc adatait vesziti el (bgsync 1 vagy 2 masodpercenkent irja ki a cache-t)
  - legrosszabb esetben 26 ev alatt farad ki az egesz
  - a fenti parameterek fuggetlenek a log-rekord meretetol (2..516 byte)

A lenyeg:

  - blokkos iras (jelenleg 264/528, de elvileg barmilyen blokkmeret johet)
  - 12 byte header, ebbol 6 byte adat, 6 byte ennek inverze (check)

A fejlecben statisztikai adatok vannak arra vonatkozolag, hol tart az 
iras/olvasas.

Indulaskor az osszes (4096/8192/...) blokk feljecet kell csak beolvasni 
(illetve tobbnyire csak az elso par byte-jat), ami 100 ms-en belul 
megtortenik. Ezzel eloallt az osszes pointer RAM-ban.

Az iras korbe-korbe megy, az olvasas koveti a korforgast, amig utol nem 
eri. Tulcsordulaskor a regebbi adatok tunnek el.

A header check arra epit, hogy az EEPROM irasakor eloszor torles van 
(a bitek megindulnak 1-fele), utana pedig iras (egyes bitek 0-at vesznek 
fel).

Tehat olyan eset (elvileg) nem allhat elo, hogy mondjuk torles/iras kozben 
elmegy a tap, es az egy blokkban egyszerre irt bitek nem azonos iranyba 
serulnek be. Azaz ket egymas melletti bit kozul ez egyik 0 helyett 1, a 
masik 1 helyett 0 erteket vesz fel.



 								-Sygma