Pozwolilem sobie zrobic pewien test. Celem bylo sprawdzenie czy latwo uwalic zawartosc licznika trzymanego w eepromie (AT24C02) i zabezpieczonego banalnym algorytmem - namiastka tego o czym ostatnio rozmawialismy. Algorytm pilnujacy licznik wyglada tak: {zapis}
- zapisywana jest zawartosc licznika + jednobajtowe CRC zaraz po nim
- zapisywana jest kopia wczesniejszego wpisu (powinna na osobnej stronie, ale uznalem ze w tym tescie nie ma to znaczenia - teraz zaluje)
{odczyt}
- jesli odczytany pierwszy wpis nie pokrywa sie z CRC, to nastepuje proba odczytania kopi, jesli i ta proba sie nie powiedzie - test jest konczony.
- jesli udalo sie odczytac poprawnie zawartosc licznika, ale byl wykryty blad niezgodnosci crc z licznikiem to wykonywany jest zapis stanu licznika wraz z zapisem bedacym kopia pierwszego zapisu - czyli odbudowywane sa wszystkie zapisy w eepromie.
Licznik jest typu long, a wiec 4 bajty + jeden bajt crc zaraz po bajtach licznika.
Od strony sprzetowej zadbalem o to, aby zasilanie siadalo z czestotliwoscia ~0.3Hz (generator funkcyjny + IRF jako klucz na zasilaniu), program zas stara sie inkrementowac licznik i za kazdym razem zapisywac w eepromie nowa wartosc zgodnie z algorytmem. W praktyce w czasie gdy uklad jest zasilany, licznik zmienia wartosc o kilka jednostek, po czym nastepuje _awaria_ zasilania.
Test trwa juz chyba z 30h, licznik wskazuje >200k, nie bylo zadnego przypadku nieudanego odzyskania wartosci liczika (a wiec test trwa dalej). Szacuje iz _awarii_ bylo juz >30k - niestety nie zrobilem licznika awarii ;-)
Ciekaw jestem kiedy padnie eeprom. Atmel pisze o 1e6... zobaczymy :-)
Ech, nic mi sie nie chce... :-( __ Pzd, Irek.N.