Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[AVR] Żywotność pamięci eeprom w praktyce - ciekawostka taka

manekinen 10 Lut 2010 19:07 9310 42
  • #31 10 Lut 2010 19:07
    PO.
    Poziom 20  

    asembler napisał:
    Moze i są potrzebne ale jeszcze anirazu ich nie dawałem:-)
    A FLASH'a to bym podejrzewal na koncu najpierw to program bym sprawdzil :-)

    Dodano po 4 [minuty]:

    No raz bo snie chcial sie wzbudzic kwarz małoherzowy



    O właśnie.
    A program też już zmieniałem, to znaczy wrzucałem różne działające wsady różnych rzeczy (bo to płytka prototypowa i wszystko na niej robię) i zawsze się zachowuje tak samo. To znaczy dokładną temp. znam z testów końcowych oczywiście ;) .
    No i nie odpowiada na programator - a to nie zależy od kodu...

  • #32 10 Lut 2010 19:16
    asembler
    Poziom 32  

    No to je juz nie wiem procesor powinien podjac prace nawet przy i -65 zewnętrznej temperatury bo przeciez struktura po jakims czasie sie nagrzeje. Do takiej temp testowałem na wewnetrzymn osc. i dopiero ponizej -50 strat procesora nastepował zauwazalnie pózniej niz sie mozna bylo spodziewac

  • #33 10 Lut 2010 19:20
    manekinen
    Poziom 29  

    Sprawdziłem drugi raz te same 15 komórek które katowałem wcześniej. O ile wtedy wyniki były (nawet bardzo) powtarzalne, to teraz są zupełnie różne więc nie liczyłem średniej

    31,213
    3,202
    261,906
    191

    357
    94,567
    5,561
    3,914

    268,649
    44,019
    529,265
    308

    12
    404,232
    231

    Tak więc wychodzi na to że po pierwszym błędzie komórkę można uznać za martwą i nie warto już jej wykorzystywać bo jak widać kolejny błąd może wystąpić już po 12 cyklach zapisu.

    asembler napisał:
    No to trzeba bedzie napisac prosty program na zapisywanie do eeprom w jednej komórce $00 w drugiej $FF i sprawdzanie po kazdym tysiacu operacji czy jest mozliwosc zmaiany bitów w komórce. Ciekawe która komórka wytrzyma dłuzej.

    Nie ma problemu, tylko powiedzcie bo się w końcu pogubiłem troszkę. Chodzi o sam zapis czy zapis z uprzednim kasowaniem? Jeśli to pierwsze to w bascomie tego nie zrobie :( Ale jeśli dostane kod to mogę puścić, dobrze jeśli będzie miał dwa ledki jak ten mój.

    Z testowania w mrozie zrezygnowałem, skoro to wydłuży żywotność... potestowałbym w takim razie wysokie temperatury, może ma ktoś jakiś pomysł na utrzymywanie stałej temperatury dajmy na to 80*C co już będzie temperaturą graniczną. Może jakaś obudowa z izolatora, i grzałka z termostatem... ehh sporo roboty.

  • #34 10 Lut 2010 19:30
    PO.
    Poziom 20  

    manekinen napisał:

    Z testowania w mrozie zrezygnowałem, skoro to wydłuży żywotność... potestowałbym w takim razie wysokie temperatury, może ma ktoś jakiś pomysł na utrzymywanie stałej temperatury dajmy na to 80*C co już będzie temperaturą graniczną. Może jakaś obudowa z izolatora, i grzałka z termostatem... ehh sporo roboty.


    Piec w kuchni masz :) ? Elektryczny? To on suportuje też takie niskie temp. tylko będzie trochę niedokładnie. Ale na ten test wystarczy.

  • #35 10 Lut 2010 19:31
    asembler
    Poziom 32  

    jak mozesz to przetestuj bez uprzedniego kasowania gdzy i tak przy zapisie procesor realizuje funkcje kasowania.
    Zrob to w ten sposob ze zapisz do dwoch komorek dwie wartosci 00 i 256 10000 razy po czym sprawdz czy mozna zmienic bity w kazdej komorce z osobna i tak dalej.

  • #36 10 Lut 2010 19:48
    manekinen
    Poziom 29  

    PO. napisał:
    Piec w kuchni masz ? Elektryczny? To on suportuje też takie niskie temp. tylko będzie trochę niedokładnie. Ale na ten test wystarczy.

    Jak wyobrażasz sobie pozostawienie włączonego piekarnika na tydzień? Nie dość że będe jadł zupki chińskie to za prąd zapłace że...

    Asembler Właśnie chodziło mi o te kasowanie które odbywa się automatycznie, z tego co napisaliście na poprzedniej stronie i z tego co mi w uszy wpadło, wynika że procesor ma możliwość zapisu bez kasowania, i właśnie o to pytałem :) Ale ok. Jakimi bitami sprawdzać? Przeciwnymi? Tzn w komórkę w którą dawałem 1000 razy 00000000 sprawdzać czy zapiszę 11111111? Czy jakąś liczbą losową? Chyba nie ma to znaczenia bo jeśli dane zamarzną to w całej komórce a nie w jednym bicie?

  • #37 10 Lut 2010 20:11
    asembler
    Poziom 32  

    Niekoniecznie w w calej komorce a testuj co 10000 razy zeby nie zaburzyc testowania

  • #38 10 Lut 2010 21:19
    PO.
    Poziom 20  

    manekinen napisał:
    PO. napisał:
    Piec w kuchni masz ? Elektryczny? To on suportuje też takie niskie temp. tylko będzie trochę niedokładnie. Ale na ten test wystarczy.

    Jak wyobrażasz sobie pozostawienie włączonego piekarnika na tydzień? Nie dość że będe jadł zupki chińskie to za prąd zapłace że...




    Nooo, trochę pewnie zapłacisz, ale za to jaka prosta realizacja. Poza tym 80*C to nie 200*C i jak jest przyzwoicie zaizolowany to nie zeżre aż tak dużo.

    Oczywiście, możesz na drugim (albo nawet na tym samym) atmelku machnąć termostacik na ds18... i kawałku drutu kantalowego po czym zawinąć całość w kocyk i pod poduchę. Tylko to więcej roboty.

  • #39 10 Lut 2010 21:59
    manekinen
    Poziom 29  

    Program będzie testował 4 komórki, w pierwsze 2 będzie wpisywał 00 a w kolejne dwie FF. Po 10000 cyklach wpisze przeciwne wartości i sprawdzi czy wszystkie bity pasują. Jeśli nie, przestanie zwiększać licznik dla danej komórki. Jeśli tak, testuje dalej. Pracuje dopóki nie padną wszystkie 4 komórki. Z początku chciałem zrobić tak aby po każdym jednym ubitym bicie zapisywał wartosc komórki tak aby było później wiadomo które bity po kolei padały, ale po prostu nie chce mi się siedzieć przy tym więc włączyłem wersję uproszczoną. Jakikolwiek bit którego nie da się zapisać i zatrzymuje licznik. W załączniku kod, tym razem nie testowałem w symulatorze, mam nadzieje że nie pójdzie w krzaki :|

  • #40 11 Lut 2010 10:45
    asembler
    Poziom 32  

    Tlko moze nie zapisuj licznika do 10 000 wystarczy podac do wiadomosci ile cykli po 10 000 wykonal program.

  • #41 21 Lut 2010 17:07
    manekinen
    Poziom 29  

    Eehhh niestety miałem awarię komputera i dokładne wyniki przepadły, z tego co pamiętam pierwszy i drugi licznik (dwie komórki "00") były zatrzymane z różnymi wynikami = czyli padły. Trzeci i czwarty (czyli komórki "FF") szły po równo, nadal pracowały. Nabite było po około 3tyś, w co sam nie wierzę bo to pomnożone przez 10tyś dało by po jakieś 30mln (!) cykli zapisów. Nie wiem czy to nie jakiś błąd w programie że aż po tyle naliczył, ale tak czy siak wygląda na to że te "00" padły pierwsze.

  • #42 21 Lut 2010 17:43
    asembler
    Poziom 32  

    Mnie sie wydaje ze nalezało si etego spodziewac z zapis $FF powinien byc gdzies koło nieskonczonosci:-)

  • #43 18 Kwi 2017 12:12
    higlos
    Poziom 12  

    Podłączając się do tematu. Jak najbardziej znane są możliwości zwiększania żywotności eeprom przedstawiane powyżej. Jednak biorąc pod uwagę milionową ilość kasowania eeproma ($FF) czy nie można w jednej komórce eeprom np 9 przechować adres aktualnej zapisanej wartości np 10. Po każdym zapisie w komórce 10 byłaby dokonana kontrolna procedura odczytu i jeśli jest prawidłowa adres w komórce 9 pozostaje bez zmian. Jeśli podczas odczytu zauważony zostaje błąd w komórce nr9 zostaje wpisana wartość 11. Komórka numer 11 stanie się teraz miejscem przechowywania informacji. W ten sposób na 1 adresowej i 10 komórkach danych może się okazać że będziemy mieli milionowe wartości poprawnych cykli zapisu. Oczywiście można użyć FRAM jednak tutaj nie mowa o nim.

    Z ciekawości sam sprawdziłem wytrzymałość eeprom (Atmega). Zapisywana wartość $00, a następnie $FF. Po każdym zapisie była kontrola poprawności zapisu. Pierwszy błąd podczas zapisywania $00 pojawił się przy cyklu 9,375mln (odczytana liczba BIN 0000_0001). Następne błędy pojawiały się znacznie częściej. Na kolejny milion $00 było ich ponad 7 tyś.