Trwałość EEPROM w AVR

Właśnie. Sprawa miejsca jest bardzo ważna. Wcześniej stosowałem do tego PIC10F w SOT23. Niestety on nie ma EEPROM, muszę się przesiąść na coś, co ma. Padło na AVR, bo lepiej znam, mam kompilator, poza tym ten ma akurat pomiar temperatury w sobie.

Tutaj pojawi się podobny problem

Użytkownik "Konop" snipped-for-privacy@gazeta.pl napisał w wiadomości news:gfq8g1$gna$ snipped-for-privacy@inews.gazeta.pl...

Pamiętam, gdy były o tym zapisy. Niedwano szukałem wzmianki o tym i nie mogłem znaleźć, ale nadal komórki 00 nie używam.

Ciekaw jestem jeszcze jak objawia się uszkdzona komórka? Czy trudności polegają na odczytaniu 1 zamiast zera, które było zapisane?

Ogólnie u mnie zapis nie jest jakiś super-krytyczny. To jest zapis ostatniego stanu pracy, który ma być cykliczny po każdym załaczeniu zasilania. Jeśli raz na tysiąc taka dana przepadnie nic się nie stanie, a procedura wyzeruje ten stan. Po prostu przy kazdym załączeniu zapamiętuję następny stan jaki ma nastąpić, ewentualnie w wyniku działania użytkownika, jeszcze ten stan zmienić. Nie mam za bardzo miejsca na żadne sprawdzanie czy zasilanie się nie wyłączyło, podtrzymanie kondensatorem, itp. Wymagana trwałość - np. 2 miliony cykli.

Zrodlem jest Atmel. Jest to chyba w ktorejs nocie, a jesli nie to znajdziesz odpowiedni post na avrfreaks z cytatem z odpowiedzi Atmela. Zreszta wynika to po prostu z zasady dzialania EEPROM. Programowane sa tylacznie komorki, ktore zmieniaja zawartosc na 0, do pozostalych ine jest przykladane HV, wiec nic zlego im sie nie dzieje.

Dzieki, czyli rozumiem, ze dobrym wyjscie powinno byc uzycie sekwencji bitowych kolejnych zapisów typu:

EM pisze:

No właśnie się nie pojawi ;).. ten algorytm nie polega na tym, że używamy komórki "aż do śmierci", tylko to jest taki wear-leveling :)... Zapisujesz tę samą daną (tzn. po każdej jej zmianie ;)) za każdym razem w następnej komórce... Gdy dojedziesz do końca, to zaczynasz kolejną kolejkę i też jedziesz od początku pamięci... Ponieważ z reguły w pamięci będziesz mieć część danych z poprzedniej kolejki, a część z aktualnej - trzeba je jakoś rozróżnić i do tego służy ten bit :)... autor źle użył sformułowania "dobra komórka"... chodziło mu raczej o "aktualną wartość" :)... W tym wypadku uszkodzenie pamięci (którejkolwiek komórki) dyskwalifikuje całą pamięć!! Ale to nie problem, bo jeśli wszystkie komórki mają zbliżoną żywotność, to gdy padnie jedna - padną kolejne... . Ale i tak, dla pamięci np. 256 bajtów odpornych na 100 000 cykli zapisu, dostajesz 25 500 000 cykli zapisu dla danych 7-bitowych :)... Poprawa znaczna :)... Zauważ też, że pierwsza komórka (ta rozróżniająca czy kolejka jest parzysta czy nie) zużywa się tak samo szybko, jak pozostałe :)...

Pozdrawiam Konop

Konop pisze:

No i takie rozwiązanie mi się podoba. Pomyślę jak coś takiego zaimplementować. :)

Konop napisał:

Użyteczne dane nie muszą być 7-bitowe, algorytm nie ma jednobajtowego ograniczenia. Dane zapisywane cyklicznie w różnych miejscach mogą mieć nawet wielomegabajtowy rozmiar. To zależy tylko od potrzeb i od ilości dostępnej pamięci.

Dokladnie tak.

Tez tak slyszalem, ale zastanawiam sie czy to po prostu nie wynikalo z tego, ze na ta komorke wskazuje domyslnie rejstr adresowy EEPROM?

I on to jakos inteligentnie rozroznia co jest, co ma byc, ktore bity wymagaja zmiany, skasowac czy nie ?

Ja tam podejrzewam ze jednak najpierw caly bajt kasuje [ustawia na FF?] a potem programuje co trzeba .. i faktycznie mozna w dokumentacji napisac "programowane sa tylko te komorki ktore maja wartosc zero".

Co sie ma jednak nijak do mojego pomyslu.

J.

Nie musi, proces kasowania komorki (ustawiania na FF) jest rozdzielny z zapisem. Zapis polega tylko na zerowaniu bitow, nie da sie ich ustawic. EEPROM zuzywa sie w trakcie procesu kasowania, gdyz tylko wtedy potrzebne jest wysokie napiecie, kolejne zapisy nie sa szkodliwe.

J.F. pisze:

Tak było od początku. Ale w nowszych AVRach można rozdzielić operację kasowania komórki EEPROMu (zapalającą wszystkie bity) i operację zapisu (mogącą tylko zerować bity). Domyślnie operacja jest przeprowadzana w dawnym trybie (kasowanie+zapis) - poczytaj o programowaniu EEPROMu np. w dokumentacji ATmega88 (rejestr EECR).