Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata

Jak robicie licznik zliczajacy wszystkie cykle maszyny? Z jednej strony ciagle zapisywanie nie ma sensu (trwalosc eepromu), z drugiej moze sie zdarzyc, ze zasilanie padnie tuz przed przepisaniem _bufora_ do eepromu, wiec licznie w ramie tez niebezpieczne. Trzeba by co jakis czas przepisac...albo zrobic detekcje zasilania. To jeden problem, ale jest jeszcze inny. Moze sie zdarzyc, ze procek padnie (z jakiegokolwiek powodu) akurat w trakcie pisania do eepromu i uszkodzi zawartosc licznika. Trzeba by wiec dodac do niego jakies CRC i powielic lokacje w eepromie. Hmm... zastanawiam sie jak zrobic taki _totalny_ licznik najprosciej, ale bezpiecznie. Moze ktos wymyslil cos ciekawego w tym temacie?

__ Pzd, Irek.N.

Reply to
Ireneusz Niemczyk
Loading thread data ...

A kondensator 0,25F podtrzymujacy procka na czas zapisu

  • wykrywanie brown-outu na komparatorze i wyzwalanie przerwania nie wystarczy?

A co to dokladnie znaczy "padnie"? Przerwie wykonywana operacje i zawiesi/zresetuje sie, czy zacznie sobie radosnie hasac po EEPROMie? BTW, wypelnij sobie wolne slowa pamieci programu skokami do wektora resetu, zawsze to jakiesz zabezpieczenie przed kompletnym pojsciem w maliny.

Moze ja czegos nie rozumiem, ale sprawa jest calkiem prosta: Trzymasz w EEPROMie 2 kopie licznika (na osobnych stronach, dzieki czemu nigdy nie skasujesz obu jednoczesnie). Na trzeciej stronie masz zmienna pamietajaca stan:

00 = stan spoczynkowy, liczniki sa poprawne 01 = rozpoczeto modyfikowanie pierwszej kopii licznika 10 = zakonczono modyfikowanie pierwszej kopii licznika i rozpoczeto drugiej

Sekwencja przejsc: 00 => 01 => 10 => 00.

Jezeli procesor po zawieszeniu sie odczytuje stan 00, to znaczy, ze wszystko w pamiecji jest OK. Jesli odczytuje

01, to znaczy, ze pierwsza kopia licznika jest nieokreslona, a druga zawiera poprawna wartosc poprzednia. Wowczas bierzesz wartosc druga, zwiekszasz o 1 i zapisujesz w pierwszej. Jezeli jest stan 10, to pierwszy licznik zawiera poprawna nowa wartosc, a wartosc drugiego jest nieokreslona. No to wtedy przepisujesz pierwsza wartosc do drugiej.

Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski

Najprościej założyć elektromechaniczny licznik. Od razu załatwia wszystkie problemy. Tomek

Reply to
Tomek

Detekcje zawsze warto zrobic. A ile maszynka ma miec cykli trwalosci? Moze wystarczy ze zapiszesz kazda setke, a po milionie gwarancja i tak sie skonczyla :-)

Wymyslili - dawno temu o tym czytalem do licznikow samochodowych. Jakis specjalny kod binarny, gdzie miedzy kolejnymi stanami zmieniano minimum bitow [cos ala Gray] i w dodatku byly te zmiany "rozrzucone" rowno po bitach [czyli nie tak jak u Greya]. Ale szczegolow nie znam. A samochody chyba w koncu z tego nie korzystaja..

J.

Reply to
J.F.

Rewelacja, mechaniczny - najpewniejszy! ;-))

Zwykle jest na pokladzie eeprom (konfiguracja, parametry pracy), wiec bylo by niejako przy okazji gdzie trzymac, poza tym pozostaje problem nr2.

Do tej pory bylem sklonny przepisywac przy kazdorazowej obsludze przez czlowieka, ale _otrzezwialem_ jak zobaczylem co jaki czas operator cos zmienia. W razie awarii strata byla by duza :-( Wiec...przy kazdej interwencji operatora

  • czas/ilosc....?

__ Pzd, Irek.N.

Reply to
Ireneusz Niemczyk

Ma bardzo powazna wade, operator moze w niego ingerowac, a mnie przydalo by sie miec dostep do licznika na wyrazne zadanie (wszystko ma swoja trwalosc, wiec jak maszyneria zaczyna _klekotac_ - warto wiedziec z jakiego powodu). Mechaniczny odpada.

__ Pzd, Irek.N.

Reply to
Ireneusz Niemczyk

Wlasnie nie chce, nie ma dla mnie znaczenia - a robic tylko dla licznika to troche przesada :-(

Wlasnie doszedlem do tego, ze przykladowo jeden gruby cykl to ponad 2300 detali, wiec... najwyzej bedzie o tyle mniej, a kilka tysiecy zapisow kazdy eeprom powinien wytrzymac.

Hmm... chyba pojde sladem podpowiedzianym przez Piotra. Swego czasu robilem zabezpieczenie tak, ze jeden pin procka musial _falowac_ zeby zapis wogole byl mozliwy, wydawalo mi sie ze to nie do zabicia jest, az pewnego razu menu w maszynie sie stracilo ;-) EEpromy jednak slabe sa :-( __ Pzd, Irek.N.

Reply to
Ireneusz Niemczyk

Hmm...pewnie tak, ale nie lubie oddzielac procka od reszty logiki, a ta czesto bierze duzo. Chcial bym jak najprosciej temat zalatwic, wiec pomyslalem ze moze ktos doswiadczyl prostego rozwiazania i mu sie sprawdzilo. Prostego w sensie - programowego.

To nawet nie musi byc wina procka, mialem juz przypadki gdzie kasowal mi sie eeprom z ustawona flaga protekcji :-( Moze taka seria paskudna byla (Atmel...24C), a moze cos sie indukowalo...nie dochodzilem. W kazdym razie kilka razy pozwolilem sobie trzymac menu w eepromie i zawsze byly z tym jakies problemy, moze nie od razu, ale po kilku latach w warunkach przykladowo kopalnianego zasilania - zawsze :-(

:-)

Ok. rozumiem.

A jesli procesor odczyta ff? to tak naprawde przeniesienie problemu z wpisu zawartosci licznika do wpisu statusu licznika, problem ten sam tylko w innym miejscu :-(

__ Pzd, Irek.N.

Reply to
Ireneusz Niemczyk

Przeciez wystarczy zwykla dioda na linii zasilania procka. Dzieki temu logika sama sie odetnie przy brown-oucie, a procek bedzie mial zapas energii w kondensatorze na co najmniej kilka sekund pracy.

Hm, to co Ty robisz, reaktory jadrowe? ;-)

Mozna zapewnic, by nie odczytal, ale mam inny, prostszy pomysl: Trzymaj w pamieci trzy kopie licznika, kazdy koniecznie na osobnej stronie. Podczas procesu odswiezania wpisuj im po kolei nowa zawartosc. Po resecie odczytaj je wszystkie i wybierz te wartosc, ktora wystepuje w pamieci dwukrotnie. Jesli takiej nie ma, to uzyj wartosci pierwszego licznika. Sa mozliwe takie przypadki:

  1. Odczytano trzy takie same wartosci -- wszystko OK.
  2. Zapis zawiodl podczas uaktualniania pierwszego licznika

-- drugi i trzeci trzymaja te sama, stara wartosc, wiec algorytm odtworzy poprawny stan.

  1. Zapis zawiodl podczas uaktualniania trzeciego licznika

-- pierwszy i drugi trzymaja te sama, nowa wartosc.

  1. Zapis zawiodl podczas uaktualniania drugiego licznika. Wowczas nie ma w pamieci dwoch takich samych wartosci, a wiec sa dwa przypadki:

a) licznik nr 1 rozni sie od licznika nr 3 o 1. W takim razie licznik pierwszy zawiera nowa wartosc -- algorytm poradzi sobie z bledem.

b) Liczniki 1 i 3 roznia sie o wiecej => zdechl Ci EEPROM.

Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski

Powitanko,

To moze na kartach mifare: sa liczniki, hasla, szyfrowanie, duza trwalosc/ilosc zapisow itp. no i raczej ciezkie do ingerencji w. Tyle, ze ukladzik nie bylby tani (ok 200zl)... Pozdroofka, Pawel Chorzempa

Reply to
Pawel "O'Pajak

Hmm... to moze w nowej wersji pcb przewidze. Poza tym i procek i eeprom musi byc na bateryjce (nie korzystam z prockow z wbudowanym eepromem).

Jasne, kieszonkowe ;-))

A nie lepiej podeprzec sie crc i miec problem wiarygodnosci licznika z glowy? Powiedzmy 2 kopie z crc dla kazdej, wazna zawsze ktoras bedzie, a ktora latwo sie przekonac sprawdzajac crc. Czy takie rozwiazanie ma jakies ostotne wady?

OK.

OK.

OK.

Ale zapis jak pisalem nie moze byc co cykl, potrzebowal bym nowy EEProma co...3 dni? (zakladajac 1e5) :-) To z kolei prowadzi do sytuacji uniemozliwiajacej jednoznaczne okreslenie ktory z licznikow jest prawdziwy. Innymi slowy - moze byc tak, ze wszystkie 3 beda sie roznily niewiele i nie bardzo wiadomo bedzie o ile powinny 2 poprawne (nowy i stary, uszkodzony 2 pomijamy).

a no wlansie.... nie.

__ Pzd, Irek.N.

Reply to
Ireneusz Niemczyk
Reply to
Andrzej Kamieniecki

Skalpel w dlon i na pajaka. :-)

Nie, istotnych wad nie ma. Nieistotna jest taka, ze uszkodzona zawartosc licznika moze przypadkiem wygenerowac poprawne CRC, co jest bardzo malo prawdopodobne. Moj algortm na te przypadlosc nie cierpi; jesli zawartosc EPROMU nie zostala skasowana/uszkodzona przez czynniki zewnetrzne, to on zawsze znajdzie poprawna wartosc licznika. Poza tym jest prostszy, nie trzeba obliczac zadnych sum kontrolnych ani kodow korekcyjnych, a jedynie sprawdzic, ktora z pieciu mozliwosci zachodzi.

Liczysz w RAMie, a zapisujesz do EPROMu po wykryciu zaniku napiecia. Energii na czas zapisu dostarcza wlasnie wspomniany kondensator. Druga mozliwosc polega na tym, ze rezygnujesz z EPROMu i zamiast tego dajesz procesor z podtrzymywaniem bateryjnym (ta sama sztuczka z dioda), ktory nie zmienia zawartosci RAMu podczas resetu.

W przypadku poprawnym zapisujesz zawsze trzy po kolei. Jesli zrobisz tak, jak Ci napisalem, to nigdy (z wylaczeniem utraty informacji przez EEPROM, ale tu zaden algorytm nie pomoze) nie dostaniesz sytuacji w ktorej nie bedziesz mogl okreslic, ktory z licznikow zawiera blad. Przeanalizuj to sobie na kartce. :-)

Bedziesz zawsze mogl wykryc numer blednego licznika i odtworzyc wartosc poprawna. Wowczas naprawe zawartosci EPROMu zaczynasz od blednego licznika -- jesli bedziesz mial gigantycznego pecha i cos nawali w tej fazie, to po prostu wrocisz do punktu wyjscia i procesor bedzie probowal naprawic ten blad do skutku. Gdy mu sie w koncu uda, to albo bedziesz mial juz poprawna zawartosc w pamieci, albo dwa liczniki beda aktualne, a jeden nie, co naprawiasz w dokladnie taki sam sposob.

To pokaz mi przejscie stanow prowadzace do nienaprawialnego bledu. :-) Liczniki sa na osobnych stronach, wiec kasowanie nigdy Ci nie zniszczy wiecej niz jednej kopii, a pozostale dwie zawsze wystarczaja do odtworzenia poprawnej wartosci.

Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski
Reply to
Andrzej Kamieniecki
Reply to
Piotr Wyderski
Reply to
Marek Dzwonnik

Użytkownik Ireneusz Niemczyk napisał:

100% pewności nigdy nie osiągniesz, możesz tylko dodawać kolejne dziewiątki po przecinku. Trzeba uważać, żeby nie przesadzić z rozbudową koncepcji. Bo jak np padnie zasilacz, co też jest prawdopodobne, albo inne przepięcie pójdzie w układ, to i tak padnie każdy scalak. Poziom bezpieczeństwa elektroniki w urządzeniu musi być zrównoważony z poziomem bezpieczeństwa innych podzespołów i czasem życia maszyny.
Reply to
A.Grodecki

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.