Pamięć FRAM (SPI) firmy Cypress i Arduino

[Gość es2]

19 minut temu, FlyingDutch napisał:

koncepcja, aby liczyć jakiś rodzaj sumy CRC i trzymać dwie kopie danych podoba mi się.

Skoro PML zaakceptował, to znaczy, że jest ok. Używam CRCR32. Jeśli mam kilka liczników, to albo CRC32 (jeśli licznik dłuższy niż 32 bity) albo dana XOR -1 jeśli <= 32-bity.

Przy odczycie sprawa prosta, jeśli CRC złe, odczytaj z kopii 2, jeśli kopia 2 ok, nadpisz do kopi 1, ustaw znacznik "odzyskano z backup", jeśli dane złe, to init danych i znacznik "init danych".  W rozwiązaniu wymaganym przez PML ma 4 kopie, 2 w RAM 2 w EEPROM, ale to wynika z tego, ze urządzenia ma podtrzymanie pracy super kondensatorami. Przeważnie używam 2 kopii w EEPROM/.FRAM.

Jeśli masz kilka rekordów, zabezpieczaj CRC każdy rekord a nie całą bazę danych. W razie się coś sypnie, to nie cała baza, tylko pojedyncze rekordy. Jeśli dane mają być super bezpieczne, to poza FRAM, zapisuj co jakiś czas (np raz na godzinę czy raz na dzień) w FTASH (uC czy zewnętrznym) albo na karcie SD, czy wysyłaj na serwer. Ja akurat tego nie robię, bo aplikacja przez USB czyta dane i zabezpiecza na serwerach, zarówno lokalnym jak i globalnym a synchronizowanie serwerów miedzy sobą mnie nie interesuje.

[marek1707]

Zdolność kodu do detekcji a może nawet i do poprawiania błędów zależy przede wszystkim od jego tzw. odległości a ta rzeczywiście jest słaba dla kilku bitów, ale szybko rośnie ze wzrostem długości paczki danych. Poza tym trudno mówić o kodach korekcyjnych "tak w ogóle" pomijając ich typ, sposób działania i/lub złożoność obliczeniową. I tak np. zwykłe kodowanie Hamminga wymaga n dodatkowych bitów dla paczki 2^n bitów. To faktycznie marnie wygląda dla jednego bajtu (3 bity), ale ale już dla rekordu 512 bajtów jest to tylko 12 bitów więc całkiem znośnie. Można poprawić tylko 1 błąd (odległość = 3), ale tu dochodzimy do modelu błędów. Nie można tak z czapy wziąć sobie jakiegoś schematu i go zaimplementować, bo może to być strzał kulą w płot. Np. kody Reed-Solomona dzielą rekord danych na symbole i poprawiają cały symbol więc np. do 512 bajtowego rekordu dodajesz 32 bajty ECC i nawet kompletne zniszczenie całego bajtu pozwala go odtworzyć, bo jest to jeden symbol. Taki schemat świetnie nadaje się do kanałów telekomunikacyjnych gdzie chwilowy impuls zakłócający przykrywa wiele blisko siebie położonych bitów danych, natomiast dla pamięci to już tak dobrze nie działa, bo tam błędy są raczej rozproszone. Wtedy sięgasz raczej po kody typu BCH, gdzie dodając 40 bitów poprawiasz aż 5 rozproszonych błędów w rekordzie 256 bitów, a kod 55-bitowy robi to samo w ciągu 2kbitowm.

Nie dam CI jednoznacznej odpowiedzi, bo nie znam modelu błędów dla pamięci FRAM. Musiałbyś zrobić trochę doświadczeń w tym konkretnym systemie. Jeśli nie wierzysz swojemu programowi i może się zdarzyć, że coś zapisze cały bajt np. trwający zapis pod zniszczony w transmisji adres podczas wyłączania zasilania albo samoczynne wywołanie funkcji zapisu podczas włączanego i jeszcze niestabilnego zasilania to masz wtedy błędy obok siebie. Jak długie będą rekordy danych? Ile z nich chcesz chronić jednym kodem ECC? Z jakim narzutem możesz się pogodzić? Jak wiele mocy i czasu może kosztować paskudny algorytm generacji a potem sprawdzania ECC? Poza tym mogą być błędy samych komórek pamięci - nawet nie wiesz z czym walczysz. Jeśli nie musisz tego robić teraz, zostaw to i zbierz wyniki. Koniecznie zrób w programie wykrywanie błędów (silne CRC) i licz te sytuacje, w miarę możliwości logując kiedy to się wydarzyło albo chociaż kiedy to wykryłeś. Mając taki nadmiar pamięci rzeczywiście możesz użyć dwóch (albo więcej) kopii danych do precyzyjnej detekcji miejsca wystąpienia błędu i to także loguj. Po roku pracy wielu urządzeń będziesz miał podstawy do jakichś przemyśleń. Teraz to wróżenie z fusów i niepotrzebny wysiłek. W międzyczasie zajrzyj tu:

http://www.eccpage.com/

A tu masz rozpisane jak działa (i w jak różny sposób można podejść do kodowania/dekodowania) kod Hamminga (7,4) czyli ten o którym wspomniał es2 oraz jego rozwinięcie, kod (8,4)::

http://circuit.ucsd.edu/~yhk/ece154c-spr17/pdfs/ErrorCorrectionI.pdf

Takie podstawy warto mieć w głowie żeby w ogóle wiedzieć o czym się mówi. Implementacja kodowania (7,3) lub (8,4) jest prosta (i na pewno dostępna w sieci jako gotowiec, poszukaj), a w rezultacie każde 4 bity zapisujesz na jednym bajcie - dość wygodne przy bajtowej organizacji pamięci i sporym jej nadmiarze. Nie jest to rozwiązanie do przyjęcia w przypadku więszej ilości danych lub w telekomunikacji, ale tu można się pobawić - choćby dla liźnięcia tematu i edukacji własnej

BTW: Trochę nie rozumiem podejścia: kod korekcyjny wymagający dodania 3 bitów do 4 bitów danych jest zły (choć umożliwia poprawienie 1 błędu w każdej tetradzie), ale rozwiązanie z drugą (a może i trzecią i czwartą) kopią całych danych czyli narzut 200-400% jest OK. Bo to zrobiłeś a wszystko czego nie tknąłeś lub nie pojąłeś jest złe i głupie? Tak tylko pytam, bo przyszedł mi do głowy stary dowcip: wszyscy kierowcy dzielą się na idiotów jeżdżących szybciej ode mnie i na debili jeżdżących wolniej..

[Gość es2]

7 godzin temu, marek1707 napisał:

BTW: Trochę nie rozumiem podejścia: kod korekcyjny wymagający dodania 3 bitów do 4 bitów danych jest zły (choć umożliwia poprawienie 1 błędu w każdej tetradzie), ale rozwiązanie z drugą (a może i trzecią i czwartą) kopią całych danych czyli narzut 200-400% jest OK.

Wszystko zależy od aplikacji. Ja przedstawiłem, swoje, konkretne wymagania (czasem nie moje ale jakiejś ustawy).

Staram się, aby dane były bezpieczne nawet w banalnych projektach (budzik). Ewentualne zniszczenie danych, następuje przeważnie w czasie ich zapisu. Nie zmuszam nikogo, aby robił 2, 5 czy 10 kopii. Jeśli klient upiera się przy 1 kopii, to tak robię ale sie pod tym nie podpisuję (jak Gesler).

Ponadto,10 złych kopii,jest gorsza niż 1 dobra.