[elektro] DataFlash logger

[hg12345]

A LOG méret 12byte ebből 2x4 a sorszám a maradékban van az információ?


  
On Sat, 27 Mar 2010, hg12345 wrote:

> Kiváncsivá tettél....
>
> Ez EEPROM vagy FLASH mert mindkettőről írsz!

Ez Atmel DataFlash (FLASH :)

> A FLASH eszközöknél törölni nagyobb blokkokban kell (ERASE BLOCK 4K), 
> írni meg tudsz kisebben is (WRITE PAGE 264byte).

Ezeknel van blokk torles, illetve blokk iras torlessel.
Blokk: 264/528 byte.

Lehetoseg van meg page/sector torlesre is, de nem hasznalom.

> A header fejlécében a sztatisztikai adatok alatt mit értesz... 
> TIMESTAMP?

Olyasmi. Konkretan egy 32 bites sequencer, ami szigoruan monoton novekszik 
minden iraskor.

Ezzel tudom, hogy melyik a "legfiatalabb" (innen folytatom az irast) es 
"legoregebb" blokk (innen olvasok), illetve nagyjabol kideritheto, hogy 
mennyire elhasznalt az eszkoz.

Tovabba helyet kapott ott 1-1 byte, hogy a lapon belul hol tart az iras, 
illetve az olvasas.

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

Nagyon lelassitja az osszes folyamatot (init, read, write).
Igazabol azert, mert a DataFlash RAM buffereben tartok mindent, abban 
modositom, es onnan is irom ki, CPU-ba csak par byte kerul attoltesre.

> 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

Egybol kiirom, mivel csak az adott blokk "kopik".

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

A fejlec-check ezt lekezeli.
Tegyuk fel, hogy binaris 11110000 kerul a fejlecbe. Check: 00001111.

Elindul a torles. Legrosszabb esetben mi tortenik?

11111111/00001111 vagy 11110000/111111111

Mivel nem egyezik a fejlec inverze a check-el, ezert ez invalid blokk.

Iraskor pont a forditottja tortenik: legrosszabb esetben 1-2 bit 1-ben 
marad. Viszont a check ezt is megfogja, mert azon a helyen eleve 1 van 
benne, aminek az inverze 0.

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

FIX, egyelore #define

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

Elso korben a header adatok validitasara ugyeltem, mivel ha par LOG 
invalid lesz, akkor az meg "elmegy", de ha megserul a struktura, akkor 
teljesen osszeborul az egesz.

Ide be lehet tenni CRC-t, ha az adatok fontosak.
Nem is mondasz hulyeseget: 12 byte-os a LOG strukturam, de ebbol csak 11 
byte-ot hasznalok (43*12 + 12 = 528 byte = blokk). Oda szepen befel egy 
CRC.

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

Ebbol nem lesz baja, mert Init-kor csak olvasas van.

Van egy masik LOG-olo algoritmusom, csak az FRAM-al mukodik. Ott 
tranzakcios logot gyartok, initkor pedig elindul recovery, ha szukseges.
De ez sem sertodik meg ha rangatjak a tapot, mert a folyamat atomikus.

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

Meg nem foglalkoztam ezekkel, de lehet mindenfele uC-n
filerendszer-kezelo kodot hasznalni.



 								-Sygma

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