[elektro] DataFlash logger

[hg12345]

Hi!

Kiváncsivá tettél.... 

Ez EEPROM vagy FLASH mert mindkettőről írsz!

A FLASH eszközöknél törölni nagyobb blokkokban kell (ERASE BLOCK 4K), írni meg tudsz kisebben is (WRITE PAGE 264byte). A header fejlécében a sztatisztikai adatok alatt mit értesz... TIMESTAMP? A validítás figyelésére nem lenne egyszerűbb egy CRC16 ellenőrző összeggel bővíteni nem csak a statisztikai adatokat, hanem a a tárolt LOG értékeket. Ennek a képzése akár kiírás közben megtörténhet, teljesítményt nem igényel, az olvashatóságot nem rontja.
Felhasználáskor a keresésben nem is kéne használni csak akkor amikor visszaolvasod ennek érvényesítésére.

Az írási laphatár átlépését a LOG-gal hogyan kezeled, több LOG-t nyitva tartasz, hogy takarékoskodjál az endurance-val, vagy egyből kiíród, mert amig FF-van a tároló területen addig írható. (ez persze csökkenti az adott PAGE endurance-t, annak arányában mekkora a LOG és PAGE méret aránya, ellenben kisebb lesz az elveszett adat mérete)

Ha ERASE BLOCK parancs közben fogy el az energia, akkor mi történik, mert elképzelhető, hogy a törlés nem teljesen sikeres. Ha marad valami szemét a BLOCK területen és már erre a blokkra írtál amikor kiderül, van valami eljárás, hogy egy adott LOG méretet inaktivvá tegyen a program. 

Még egy kérdés a LOG méret fix, vagy esetleg a fejléc erre is tartalmaz információt. 

Visszaolvasáskor hogyan biztosítod a LOG tartalom validítását?

Egy utolsó kérdés... a kapcstápok azon tulajdonságát tudja kezelni, hogy a kikapcsoláskor amikor a fogyasztókat lekapcsolják, a bufferben tárolt energiából még üzemi feszültséget tud előállítani, újra indítja akár többször is a rendszert.  

Az utolsó utáni kérdés, egy MicroSD kártya lassan olcsóbb mint egy DF :-), mérete szerintem nem okoz problémát, foglalat is fillérekért kapható. Kezelése is hasonló SPI busz és alternatívái. A program kezelése elképzelhető úgy, hogy egyből valamilyen számítógép ehető file formátumban történjen? A LOG feldolgozás nagyobb valószínűséggel valamilyen nem mikró gépen történik, esetleg Windows vagy LINUX gépeken, így egy beolvasás és átküldsét meglehet spórolni.


Bocs a sok kérdésért ezek a témák nagyon izgatnak...

  
  
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

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