Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata

Użytkownik Fish napisał:

[...]

Stary jak świat i POPULARNY trick, konieczny w badziewiastych Atmelach, które mają badziewiasty EEPROM. Liczenie sum kontrolnych itp tylko pochłania program oraz czas procesora.

Są jednak procesory z lepszym EEPROMEM (>=1M cykli gwarantowanych) i ten sam efekt można uzyskać na 13*LICZBA_BAJTÓW_LICZNIKA +1 komórkach bez wydłużana programu. Dla licznika czasu (w minutach) na 24 lata byłoby to

40 bajtów. Dla podniesienia poziomu ufności robi się weryfikację zawartości pamięci a nie multiplikuje liczniki w tej samej pamięci, bo wieksze jest prawdopodobieństwo że padnie cały scalak albo wręcz układ elektroniczny.

Tyle, że Irek sam się przyznał, że nie korzysta z procków z wbudowanymi EEPROM-ami (czyli nie AVR-y), a mimo to lęka się o dane swoje. Pudło ;-)

Pozdrawiam

FM24C04A pasuje jak znalazl :-) THX.

__ Pzd, Irek.N.

Auc... dusza juz cierpi z powodu zniszcenia tak ladnej plytki ;-))

W takim razie jak dobrze _zamieszac_ CRC zeby bylo pewniej? Moze CRC zrobic szersze niz 8 bitow?

Hmm... o tym dalej.

Mnie nie przeszkadza ze podczas zapisu cos sie stracilo, tylko to ze ta strata czasami jest nie do odratowania. Dlatego szukam pomyslu na takie zakodowanie/obsluzenie informacji zeby zawsze mozna bylo ja odzyskac. Nie bedzie mnie bolalo jak ostatni zapis wcale nie przejdzie i bede mial powiedzmy jedna partie niezliczona. Zupelnie nie ma znaczenia czy licznik wskaze 1 000

000cykli, czy tez 1 002 000 cykli (potrzebuje przykladowo oszacowac ile jeszcze pociagnie pneumatyka zanim moga sie zaczac problemy). Dlatego wszelkie wykrywanie zaniku zasilania czy tez trzymanie wartosci pod bateryjka nie ma chyba sensu.

Ale Piotrze, albo ja nie zrozumielam, albo Ty z zakladasz zliczanie i zapisywanie kazdego cyklu. Jesli zakladasz ze liczniki beda zapisywane co jeden to masz racje, dane bezpieczne, ale one tego nie przezyja na dluzsza mete - po prostu. Jesli zas nie zakladasz ze co cykl zapisujemy eeprom (tylko powiedzmy w ramie zliczamy i dopiero grubiej przepisujemy) to nie masz sytuacji w ktorej liczniki maja wartosci rozniace sie nie o jeden - co wiecej - wogole nie wiesz o ile sie roznia i nie znajdziesz jednoznacznie dobrego. Mozesz jedynie zalozyc, ze niewielka (mniejsza od porcji) roznica pomiedzy licznikami wskaze dobry/swierzszy.

Jak juz znajde wartosc, to faktycznie warto odbudowac pozostale liczniki.

:-)

Sprobuje. Mamy 3 poprawne liczniki, ostatnio zapisywany byl pierwszy. Zapis nastepuje za kazdym nacisnieciem jakiegokolwiek klawisza na pulpicie (a wiec i wylaczenie pracy maszyny). Nie jest znana ilosc jaka zostala doliczona od ostatniego cyklu zapisu do eepromu, poniewaz nie ma dla tego zadnego licznika, a czlowiek jest _nieobliczalny_. Nie wiemy wiec jaka wartosc powinna byc wlasnie zapisana w liczniku nr2...ktory wlasnie piszemy i _zawalamy_ (nie wiemy z punktu widzenia programu starajacego sie odzyskac dane). Mamy wiec sytuacje w ktorej licznik pierwszy wskazuje A, Licznik drugi wskazuje A+-X, a licznik trzeci wskazuje A-Y. X oznacza dla nas zmienna _sufitowa_ ;-) Y natomiast ilosc cykli o jaka powiekszyl nam sie licznik pierwszy od czasu zapisu licznika trzeciego. Mozemy jedynie gdybac, ze skoro Y jest niewielkie, to prawdopodobnie jest mlodszy...ale nie mamy gwarancji ze drugi podczas uszkadzania nie zanotowal troche wiekszej wartosci niz pierwszy (Y+1?) - wiec droga nalogii wzieli bysmy go za najswierzszy, gdybysmy dopuscili takie _wnioskowanie na podstawie malych roznic_.

Nie wiem czy czytelnie przedstawilem o co mi chodzi. Sorki rowniez za zwloke, delegowalem sie bylem i to w stanie chorobowym, wiec nawet sily nie mialem odpalac i-net.

Jak na razie tytulem proby (w jednej z maszyn od jutra testy) zrobilem tak, ze dwa liczniki maja na sobie crc i zapisywane sa ta sama wartoscia. Jak program uzna ze pierwszy z nich ma crc nie odpowiadajace spodziewanemu, to stara sie sprawdzic drugi, jak jest ok to naprawia pierwszy, a jak nie....to klapa z informacja do projektanta wlacznie ;-)) Ciekaw jestem jak podniesie sie niezawodnosc przy tak prostym rozwiazaniu (ciekawe jakie jest prawdopodobienstwo rozwalenia czegos takiego, strony rozne, zapis pomiedzy licznikami opozniony o 20ms, wiec kwestie zasilania mamy z glowy).

Milego dnia i THX za pomysly, czekam na jeszcze :-) __ Pzd, Irek.N.

:-) A bo to tak jest, ze w jednej maszynie statystyki chodza miesiac, w innej wcale a w jeszcze innej nigdy nie bylo problemu z nimi ;-) i jak tu byc madrym? :-(

Milego dnia Marcinie. __ Pzd, Irek.N.

:-)

Ale to nie po to... Co ciekawe jak kiedys poszlo w jednej z maszyn 12V na elektronike z 89C52, LCD-kiem i AT24C16 chyba, to ten ostatni przezyl.

Ma wlasnie nadzorowac starzenie sie maszyny, wiec samemu musi byc...zywotniejszy.

Milego dnia. __ Pzd, Irek.N.

Jesli odwzorowanie CRC nie bedzie funkcja roznowartosciowa, to _zawsze_ da sie je oszukac.

CRC krotsze niz ciag zabezpieczany (czyt. dlugosc licznika) _nigdy_ nie sa obliczane przez funkcje roznowartosciowa, a wiec zawsze da sie je oszukac. Kolderka jest zbyt krotka, taka jest brutalna prawda. :->

No tak, sam przeciez napisales, ze chcesz znac wynik dokladny, a tego bez zapisu co cykl nie uzyskasz. Jesli dopuszczasz blad co najwyzej K cykli, to po zmianie roznicy 1 na K w podanym algorytmie rowniez wszystko bedzie dzialac poprawnie. Ale jesli:

to w takiej sytuacji moj algorytm oczywiscie nie zadziala, ale nie do takich warunkow pracy zostal on zaprojektowany. Mozna go jednak latwo zmodyfikowac do powyzszych zalozen, wystarczy wprowadzic czwarty licznik i liczyc funkcje majority z ich wartosci: jesli jest ona jednoznaczna, to albo 4 liczniki sa jednakowe -- OK, albo 3 jednakowe, a jeden inny albo 2 jednakowe i 2 rozne -- naprawialne. Jesli nie jest jednoznaczna, czyli masz 2 pary po 2 jednakowe wartosci, to za wartosc poprawna uznajesz wieksza. Pozostale mozliwosci oznaczaja fizyczne uszkodzenie zawartosci EPROMu.

W przedstawionym przypadku masz calkowita racje, ale nie zmienia sie regul (okreslajacych sposob zapisu do pamieci) w trakcie gry... :-)

Nie tylko warto, ale trzeba, to jest integralna czesc tego algorytmu: bez tego nie ma on tej wlasnosci, ze proces naprawy kazdego mozliwego stanu pamieci zakonczy sie w stanie nie gorszym od zastanego. Tylko naprawe musisz wykonywac w dokladnie takiej kolejnosci, jak podalem poprzednio -- kazdy z kilku mozliwych bledow wymaga odrebnego potraktowania.

Tylko rzecz w tym, ze suma kontrolna krotsza od zabezpieczanego slowa nie ma prawa byc okreslona jednoznacznie (prosty wniosek z definicji odwzorowan bijektywnych) i moze sie tak zdarzyc, ze uszkodzone dane wygeneruja Ci poprawna sume. Oczywiscie mozna zaczac machac rekami, ze to "niemozliwe", ale z zasady szufladkowej wiadomo, ze _zawsze_ da sie wygenerowac falszywy ciag przechodzacy test poprawnosci. Mozna sobie poradzic z tym problemem wylacznie poprzez uzycie sum o dlugosci co najmniej takiej, jak zabezpieczany ciag. Jesli zdefiniujesz funkcje wyliczajaca CRC jako odwzorowanie identycznosciowe, a dlugosc "CRC" bedzie rowna dlugosci licznika (kazda bijekcja jest roznowartosciowa, a identycznosc szczegolnie prosto sie liczy... ;-)), to dostaniesz _dokladnie_ przedstawiony wyzej algorytm czterolicznikowy.

Dziekuje, wzajemnie. :-)

Wiecej pomyslow nie bedzie [:-)], bo, jak napisalem wyzej, zarowno moj algorytm, jak i Twoje podejscie z CRC (po narzuceniu na nie wspomnianych, bardzo istotnych warunkow) prowadzi do niezawodnego rozwiazania.

Pozdrawiam Piotr Wyderski

? Jarkowi pisalem ze nawet gruby przebieg (2300cykli) moge odpuscic.

4 liczniki powiadasz, sprawy sie komplikuja :-(

Ok, zaraz siadam i _wyrzne_ takie CRC ze wszystkie inne liczniki beda zazdroscic :-)

Och, zebys wiedzial jakie przypadki potrafia zdarzyc sie w maszynach sortujacych detale! Gdybym chcial tak je popukladac tak dziwacznie recznie, to by mi pewnie nerwow za braklo, a tu prosze dzien pracy i znamy chyba wszystkie mozliwe rozklady detali ;-)

Wlasnie dotarlo do mnie, ze w zasadzie to ten sam przypadek, no niezle!

No to moze jeszcze troche dyskusji na temat czy warto rozsiewac liczniki jak groch, czy tez trzymac poszczegolne bajty w kolejnosci (nie chodzi o rozmieszczenie licznikow - tu oczywiste ze na roznych stronach). Czy wlozenie opoznienia w zapisie licznikow ma jakis sens? Pomyslalem, ze jak zapisze pierwszy, to warto poczekac chwilke zanim zapisze kolejny. Gdyby okazalo sie ze zapis trafil na zanikajace zasilanie, to pierwszy mogl by sie nie dokonczyc, a kolejny pomimo tego rozpoczac (w efekcie uszkodzic). Co jeszcze? aa.... oczywiscie pierwszy bajt zostawiamy w spokoju :-)

Milej soboty Piotrze. __ Pzd, Irek.N.

W takim razie gdzies mi umknal ten post.

Dlaczego? Jesli masz juz 3, to trzeba tylko dolozyc jedna zmienna, a jesli z CRC, to 4 zmienne i tak juz juz masz.

Tylko niech bedzie bijektywne. Np. takie, ze pamietasz wartosc i dopelnienie tej wartosci (do zera, samych jedynek itd. -- kazde bedzie dobre). BTW, sumy trzymaj oczywiscie na osobnych stronach.

No ale jesli na podstawie zalozenia modelu awarii (tu: niszczy sie zawartosc co najwyzej jednego licznika) masz przestrzen stanow skonczona i potrafisz przeanalizowac wszystkie mozliwe sciezki, to skad Ci sie moga wziac inne przypadki? -- tylko z powodu wystapienia bledu nie spelniajacego tego modelu. A takie bledy sa mozliwe tylko wowczas, jesli zawartosc pamieci zmieni sie sprzetowo: padnie EPROM, zostanie zamrozony, jeden licznik dostanie czastka elementarna podczas zapisu drugiego itp., ale tego _programowo_ nie zalatwisz.

Ano. :-)

Ja bym trzymal bajty razem, w koncu na rozrzuceniu nic nie zyskujesz

-- licznik z nawet jednym niepoprawnym bitem to licznik uszkodzony.

Moim zdaniem nie, a nawet wrecz przeciwnie -- zwiekszasz prawdopodobienstwo zawieszenia sie podczas uaktualniania, bo wowczas masz na to po prostu wiecej czasu. :-)

Kondensator podtrzymujacy powinien skutecznie zalatwic sprawe brown-outu. Dzieki niemu z duzym wyprzedzeniem dowiesz sie, ze zasilanie pada.

Wzajemnie, ale w moim przypadku ta sobota nie musi byc mila, wole, by byla bezdymna, bo sie biore za przetwornice... :->

Pozdrawiam Piotr Wyderski

Jaka by nie byla - zawsze jest to ryzyko ze i dane i crc sie przeklamie i odczytamy wartosc przypadkowa ale uznana za dobra.

A tutaj ... ja bym chyba dal tych licznikow kilka[N] w pamieci, co M [powiedzmy 100] cykli zapisywal wartosc w kolejnym liczniku, w ten sposob jedna komorka jest zmieniana co ~N*M cykli i starcza na dlugo, przy wlaczeniu wyszukujemy najwiekszej .. a jak sie cos przeklamie, to wiemy ze w komorkach powinny byc liczby podobnej wartosci, rozniace sie o mniej niz M.

Przy CRC 8 bit mamy 0.4% szansy ze przypadkowe przeklamanie da poprawna wartosc. A przy dobrze dobranym wielomianie - 100% pewnosci ze nie wystarczy 1 bitu przeklamac.

Te 0.4% nie jest malo .. ale 16-bit crc juz powinno starczyc. Chyba ze to o duze pieniadze chodzi, wtedy 32-bit moze byc za malo :-)

Tylko ze .. trafi sie blad i co ? Nic nie wiemy, poza tym ze jest blad. To ja juz chyba wole swoj pomysl ..

J.

:-) Probowalem recznie uwalic algorytm z 2-ma licznikami i prostym CRC, ale bezskutecznie. Na probe zostawilem - zobaczymy po....roku?

Ale to troche pamieci zajmuje, a poza tym - nie mam tego luksusu zeby zapisywac dokladnie co M. Czasami procek nie moze sobie zrobic przerwy na bazgranie po eepromie. Czasami musimy tez zapisac inna wartosc, bo operator zakonczyl prace i to nie w modulo M, co wtedy? :-( Poza tym z wyszukiwaniem najwiekszej wartosci jest klopot taki, ze moze to byc wartosc zdrowo przesadzona. Wypadalo by wiec sprawdzac czy jest gdzies taka sama wartosc -M, zeby miec pewnosc ze nie czytamy smieci.

Zrobie chyba 4-ro licznikowy algorytm i zapisze w bibliotece po wsze czasy, temat wydaje sie opanowany, choc zastanawiam sie czy nie da sie optymalniej. Troche duzo te 4 liczniki (longi sa 4 bajtowe, wiec 16 bajtow...najlepiej w 4 stronach - a to juz wymagania).

Milego wieczoru Jarku. __ Pzd, Irek.N.

Ja mam monitorowane zasilanie urzadzenia. Jak mi spada napiecie ponizej pewnego minimum, to zapisuje do eepromu. W ponad 2k urzadzen dziala to bezblednie (od 5 lat). Jako ze miejsca w 24c16 mam malutko, wiec zapisuje tylko jedna kopie licznika, bez CRC, bez niczego innego. Jak do tej pory ani jednej awarii z tego powodu nie bylo. Urzadzenia srednio wlaczane do pradu 1-3x dziennie. Zapisywana jest ilosc sekund pracy. Prosto i... (jak do tej pory) bezbolesnie :-)

Az podejrzane ;-) A ja _trzasnalem w biblioteke_ i juz zapomnialem o problemie, no chyba ze odkryje jakies idiotyzmy po pewnym czasie, ale nie sadze. W nowej wersji sterownika przewidze detekcje zasilania, moze tez zrobie osobno frama i eeproma... zobaczymy (najpierw musze wytluc te co juz mam).

Milego wieczoru Jerry. __ Pzd, Irek.N. ps. czas by tez bylo zmienic procek...w koncu!

Hehe... tez teraz przechodze przez tworzenie nowego sterownika - z wiadomych wzgledow :-)

No wlasnie ja sie nie moge zdecydowac... chyba wybiore dwa procki i w zaleznosci jakie zadania, taki bedzie proc. Softwarowo bedzie wszystko kompatybilne, bo oba proce maja kompilatory gcc :-) Bede pewnie meczyc Piotra Wyderskiego na poczatku tworzenia bibliotek odnosnie dwuprocesorowosci :-)

Poddam sie tym mekom z przyjemnoscia. :-)

Pozdrawiam Piotr Wyderski