Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 05 Mar 2005 18:05:26 +0100


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.


Poprzedni Następny
Wiadomość
Spis treści
From: "Marek Dzwonnik" <mdz_at_nospam_WIADOMO_PO_CO_TO.message.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 5 Mar 2005 18:23:12 +0100


Użytkownik "Ireneusz Niemczyk" <Adres.znajdziesz_at_nospam_w.starym.archiwum>
napisał w wiadomości news:4229E6D6.B3E97F9A_at_nospam_w.starym.archiwum

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.

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.


Za 50pln kupić gotowy licznik LCD z zasilaniem z wbudowanej baterii? ;-)))

A jeżeli ten licznik ma być własny:
już takie drogie, a praktycznie nie ograniczajš liczby zapisów. Poza tym sam
proces zapis trwa znacznie krócej, więc maleje ryzyko błędnej transakcji.

obłożonych dodatkowo sumami kontrolnymi. Poza tym jedna lokacja może
pamiętać wartość dokładnš a inne wartości przybliżone (np. mod.10, mod 33
itp.), a więc aktualizowane rzadziej i nie wszystkie naraz.

--
Marek Dzwonnik, GG: #2061027 - zwykle jako 'niewidoczny'
(Uwaga Gadu-Gadulcowicze: Nie odpowiadam na anonimy.)


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 05 Mar 2005 21:14:00 +0100


Za 50pln kupić gotowy licznik LCD z zasilaniem z wbudowanej baterii? ;-)))

Rewelacja, mechaniczny - najpewniejszy! ;-))

A jeżeli ten licznik ma być własny:
- zamiast EEPROM-u użyć pamięci FRAM. Szeregowe Ramtrony w TME nawet nie sš
już takie drogie, a praktycznie nie ograniczajš liczby zapisów. Poza tym sam
proces zapis trwa znacznie krócej, więc maleje ryzyko błędnej transakcji.

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

- na wszelki wypadek można powielić zapis danych w kilku lokacjach
obłożonych dodatkowo sumami kontrolnymi. Poza tym jedna lokacja może
pamiętać wartość dokładnš a inne wartości przybliżone (np. mod.10, mod 33
itp.), a więc aktualizowane rzadziej i nie wszystkie naraz.

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.


Poprzedni Następny
Wiadomość
Spis treści
From: "Marek Dzwonnik" <mdz_at_nospam_WIADOMO_PO_CO_TO.message.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 6 Mar 2005 00:48:21 +0100


Użytkownik "Ireneusz Niemczyk" <Adres.znajdziesz_at_nospam_w.starym.archiwum>
napisał w wiadomości news:422A1308.58685163_at_nospam_w.starym.archiwum

- zamiast EEPROM-u użyć pamięci FRAM.

Zwykle jest na pokladzie eeprom (konfiguracja, parametry pracy), wiec
bylo by niejako przy okazji gdzie trzymac,

Zwykły szeregowy EEPROM? No to wymienić na szeregowego FRAM-a i używac w
ten sam sposób.
http://www.tme.pl/arts2/pl/html_nowe2/fm24c256-se.html

--
Marek Dzwonnik, GG: #2061027 - zwykle jako 'niewidoczny'
(Uwaga Gadu-Gadulcowicze: Nie odpowiadam na anonimy.)


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Fri, 11 Mar 2005 16:17:57 +0100


Zwykły szeregowy EEPROM? No to wymienić na szeregowego FRAM-a i używac w
ten sam sposób.
http://www.tme.pl/arts2/pl/html_nowe2/fm24c256-se.html

FM24C04A pasuje jak znalazl :-) THX.

__
Pzd, Irek.N.


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 5 Mar 2005 18:41:20 +0100


Ireneusz Niemczyk wrote:

ze zasilanie padnie tuz przed przepisaniem bufora do eepromu,
wiec licznie w ramie tez niebezpieczne.

A kondensator 0,25F podtrzymujacy procka na czas zapisu
+ wykrywanie brown-outu na komparatorze i wyzwalanie
przerwania nie wystarczy?

Moze sie zdarzyc, ze procek padnie (z jakiegokolwiek powodu)
akurat w trakcie pisania do eepromu i uszkodzi zawartosc licznika.

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.

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?

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


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 05 Mar 2005 21:27:45 +0100


A kondensator 0,25F podtrzymujacy procka na czas zapisu
+ wykrywanie brown-outu na komparatorze i wyzwalanie
przerwania nie wystarczy?

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.

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.

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 :-(

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.

Ok. rozumiem.

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.

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.


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 5 Mar 2005 22:12:41 +0100


Ireneusz Niemczyk wrote:

Hmm...pewnie tak, ale nie lubie oddzielac procka od reszty logiki, a ta
czesto
bierze duzo.

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.

To nawet nie musi byc wina procka, mialem juz przypadki
gdzie kasowal mi sie eeprom z ustawona flaga protekcji :-(

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

A jesli procesor odczyta ff?

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.

3. Zapis zawiodl podczas uaktualniania trzeciego licznika
-- pierwszy i drugi trzymaja te sama, nowa wartosc.

4. 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


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 05 Mar 2005 22:26:43 +0100


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.

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).

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

Jasne, kieszonkowe ;-))

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.

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?

1. Odczytano trzy takie same wartosci -- wszystko OK.


OK.

2. Zapis zawiodl podczas uaktualniania pierwszego licznika
-- drugi i trzeci trzymaja te sama, stara wartosc, wiec
algorytm odtworzy poprawny stan.

OK.

3. Zapis zawiodl podczas uaktualniania trzeciego licznika
-- pierwszy i drugi trzymaja te sama, nowa wartosc.

OK.

4. 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.

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).

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

a no wlansie.... nie.

__
Pzd, Irek.N.


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 5 Mar 2005 22:57:09 +0100


Ireneusz Niemczyk wrote:

Hmm... to moze w nowej wersji pcb przewidze.

Skalpel w dlon i na pajaka. :-)

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?

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.

Ale zapis jak pisalem nie moze byc co cykl, potrzebowal bym nowy EEProma
co...3 dni? (zakladajac 1e5) :-)

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.

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).

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.

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

a no wlansie.... nie.

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


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Fri, 11 Mar 2005 16:50:33 +0100


Skalpel w dlon i na pajaka. :-)

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

Nie, istotnych wad nie ma. Nieistotna jest taka, ze uszkodzona
zawartosc licznika moze przypadkiem wygenerowac poprawne CRC,
co jest bardzo malo prawdopodobne.

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

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.

Hmm... o tym dalej.

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.

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.

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. :-)

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.

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.

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

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.

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.


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Fri, 11 Mar 2005 23:06:18 +0100


Ireneusz Niemczyk wrote:

W takim razie jak dobrze zamieszac CRC zeby bylo pewniej?

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

Moze CRC zrobic szersze niz 8 bitow?

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. :->

Ale Piotrze, albo ja nie zrozumielam, albo Ty z zakladasz
zliczanie i zapisywanie kazdego cyklu.

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:

(tylko powiedzmy w ramie zliczamy i dopiero grubiej przepisujemy)

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.

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.

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

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

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.

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.

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.

Milego dnia

Dziekuje, wzajemnie. :-)

i THX za pomysly, czekam na jeszcze :-)

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


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 12 Mar 2005 09:18:07 +0100




Piotr Wyderski wrote:

Ireneusz Niemczyk wrote:
No tak, sam przeciez napisales, ze chcesz znac wynik dokladny,

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

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.

4 liczniki powiadasz, sprawy sie komplikuja :-(

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.

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

Oczywiscie mozna zaczac machac rekami,
ze to "niemozliwe", ale z zasady szufladkowej wiadomo, ze zawsze da
sie wygenerowac falszywy ciag przechodzacy test poprawnosci.

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 ;-)

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.

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

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.

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.


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 12 Mar 2005 12:20:07 +0100


Ireneusz Niemczyk wrote:

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

W takim razie gdzies mi umknal ten post.

4 liczniki powiadasz, sprawy sie komplikuja :-(

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

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

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.

Och, zebys wiedzial jakie przypadki potrafia zdarzyc sie w maszynach
sortujacych detale!

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.

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

Ano. :-)

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).

Ja bym trzymal bajty razem, w koncu na rozrzuceniu nic nie zyskujesz
-- licznik z nawet jednym niepoprawnym bitem to licznik uszkodzony.

Czy wlozenie opoznienia w zapisie licznikow ma jakis sens?

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

Gdyby okazalo sie ze zapis trafil na zanikajace zasilanie, to
pierwszy mogl by sie nie dokonczyc, a kolejny pomimo tego
rozpoczac (w efekcie uszkodzic).

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

Milej soboty Piotrze.

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

Pozdrawiam
Piotr Wyderski


Poprzedni Następny
Wiadomość
Spis treści
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 12 Mar 2005 15:38:34 +0100


On Fri, 11 Mar 2005 23:06:18 +0100, Piotr Wyderski wrote:
Ireneusz Niemczyk wrote:
W takim razie jak dobrze zamieszac CRC zeby bylo pewniej?

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

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.

Moze CRC zrobic szersze niz 8 bitow?
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. :->

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.


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 12 Mar 2005 19:58:36 +0100


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

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

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.

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.

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 :-)

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.


Poprzedni Następny
Wiadomość
Spis treści
From: "Gissbourne" <gissbourneSP_at_nospam_AMpoczta.onet.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 5 Mar 2005 23:52:21 +0100



Użytkownik "Ireneusz Niemczyk" <Adres.znajdziesz_at_nospam_w.starym.archiwum> napisał
w wiadomości news:
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.

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).

W przypadku 4 licznikow powyzszego problemu nie bedzie.
Mozesz tez zrobic licznik w kodzie Graya zapisujac kazdy bit w oddzielnym
bajcie.
W celu zwiekszenia zywotnosci za kazdym razem licznik moze zmieniac strone
pamieci - zapisujesz nowa wartosc na nowej stronie, a stara zerujesz. W
sumie nawet nie trzeba zerowac jesli przyjac, ze aktualny jest najwiekszy.
Najlepiej polaczyc kilka rozwiazan np. 4 liczniki + suma. Wszystko zalezy od
wielkosci pamieci.

Pozd
Gissbourne


Poprzedni Następny
Wiadomość
Spis treści
From: "Fish" <n.o.s.p.a.m.abuse_at_nospam_onet.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 6 Mar 2005 12:27:23 +0100


W artykule news:422A2413.73E3C3F2_at_nospam_w.starym.archiwum,
niejaki(a): Ireneusz Niemczyk z adresu <Adres.znajdziesz_at_nospam_w.starym.archiwum>
napisał(a):

Ale zapis jak pisalem nie moze byc co cykl, potrzebowal bym nowy
EEProma co...3 dni? (zakladajac 1e5) :-)

To ja zaproponuje to co wymyśliłem do swojego urzšdzenia które musiało
pamiętać ile czasu przepracowało a ile pozostało do przepracowania.

Wydzielasz pewnien obszar w eepromie (przyjmijmy ze 128 bajtow). Co jeden
swój cykl zapisujesz kolejny bajt np wartosciš 0xAA. Po dojsciu do konca
obszaru wracasz na poczštek i tym razem przechodzisz przez całość zapisujšc
wartościš np. 0x55

Do tego dochodzi licznik pamietajacy stan odpowiadajacy poczatkowi
rozpoczetego cyklu zapisów.
Dzięki temu licznik jest uaktualniany co 256 cykli pracy urzšdzenia a
pozostałe komórki co 128 cykli.
Licznik można powielić i ewentualnie zabezpieczyć jakšś sumš kontrolnš dla
zabezpieczenia przed przekłamaniem w trakcie zapisu (to juz koledzy
dogłębnie przeanalizowali) a poprzez analizę tych 128 komórek jesteś w
stanie ustalić dokładnie stan licznika nawet w przypaku przekłamania (no bo
skoro pomiędzy bajtami 0x55 a bajtami 0xAA jest komórka z jakšś innš
wartosciš to trzeba jš też zaliczyć bo pewnie właśnie było przekłamanie
podczas zapisu)

Ilość komórek przeznaczonych dla tego "licznika pierścieniowego" można
dobrać odpowienio do potrzebnych ilości zapisów podczas czasu życia
urzšdzenia.
Ja potrzebowałem zapisy co minutę więc zakładajšc 100 tyś poprawnych zapisów
w każdej komórce otrzymałem ponad 24 lata pracy przy użyciu 128 komórek.

--
Janusz



Poprzedni Następny
Wiadomość
Spis treści
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 06 Mar 2005 13:40:22 +0100


Użytkownik Fish napisał:

Ale zapis jak pisalem nie moze byc co cykl, potrzebowal bym nowy
EEProma co...3 dni? (zakladajac 1e5) :-)


To ja zaproponuje to co wymyśliłem do swojego urzšdzenia które musiało
pamiętać ile czasu przepracowało a ile pozostało do przepracowania.

Wydzielasz pewnien obszar w eepromie (przyjmijmy ze 128 bajtow). Co jeden
swój cykl zapisujesz kolejny bajt np wartosciš 0xAA. Po dojsciu do konca
obszaru wracasz na poczštek i tym razem przechodzisz przez całość zapisujšc
wartościš np. 0x55

Do tego dochodzi licznik pamietajacy ...
[...]
Ja potrzebowałem zapisy co minutę więc zakładajšc 100 tyś poprawnych zapisów
w każdej komórce otrzymałem ponad 24 lata pracy przy użyciu 128 komórek.

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.

--

Pozdrawiam,

A. Grodecki

Poprzedni Następny
Wiadomość
Spis treści
From: Marcin Stanisz <mstanisz_at_nospam_bzdury.poczta.onet.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Mon, 07 Mar 2005 18:39:30 +0100


On Sun, 06 Mar 2005 13:40:22 +0100, A.Grodecki wrote:
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.

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
--
Marcin Stanisz

"A lie will go round the world before the truth has got its boots on"
Terry Pratchett, "Truth"


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Fri, 11 Mar 2005 16:53:34 +0100


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 ;-)

-)
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.


Poprzedni Następny
Wiadomość
Spis treści
From: "Andrzej Kamieniecki" <_andrzej.kamieniecki_at_nospam_tespol.com.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 5 Mar 2005 22:28:04 +0100


Użytkownik "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl> napisał w
wiadomości news:d0d7c1$lp2$1_at_nospam_news.dialog.net.pl...
[ciap]

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

Spotkałem się z już i z takimi przypadkami że eprom po gwałtownych zmianach
temperatury zmieniał zawartość na jakieś przypadkowe śmieci. Jak to jest
urzšdzenie przemysłowe to i pewnie takie wahania wchodzš w grę.

Andrzej Kamieniecki


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 5 Mar 2005 22:59:02 +0100


Andrzej Kamieniecki wrote:

Spotkałem się z już i z takimi przypadkami że eprom po gwałtownych
zmianach
temperatury zmieniał zawartość na jakieś przypadkowe śmieci. Jak to jest
urzšdzenie przemysłowe to i pewnie takie wahania wchodzš w grę.

Tylko na to zadne rozwiazanie programowe nie pomoze.

Pozdrawiam
Piotr Wyderski


Poprzedni Następny
Wiadomość
Spis treści
From: "Andrzej Kamieniecki" <_andrzej.kamieniecki_at_nospam_tespol.com.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 6 Mar 2005 00:16:07 +0100


Użytkownik "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl> napisał w
wiadomości news:d0da2s$nqq$1_at_nospam_news.dialog.net.pl...
[ciap]

Tylko na to zadne rozwiazanie programowe nie pomoze.

Może dwa osobne uklady, jeśli nawet coś zgubiš to raczej w różny sposób i
jest prawdopodobne że choć jden zachowa poprawnš wartość. Ale to juz sie
robi chyba niepotrzebnie duże.

Andrzej Kamieniecki


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 6 Mar 2005 00:43:56 +0100


Andrzej Kamieniecki wrote:

Może dwa osobne uklady, jeśli nawet coś zgubiš to raczej w różny sposób i
jest prawdopodobne że choć jden zachowa poprawnš wartość.

Pomogloby to istotnie, gdyby uszkodzenia zawartosci
pamieci byly zdarzeniami niezaleznymi. Skoro tutaj jednak
utrata danych jest spowodowana szokiem termicznym,
dzialajacym w jednakowy sposob na oba uklady, to
dlaczego zwielokrotnienie liczby pamieci mialoby pomoc?

Pozdrawiam
Piotr Wyderski


Poprzedni Następny
Wiadomość
Spis treści
From: "Andrzej Kamieniecki" <_andrzej.kamieniecki_at_nospam_tespol.com.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 6 Mar 2005 09:19:38 +0100


Użytkownik "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl> napisał w
wiadomości news:d0dg7k$smg$1_at_nospam_news.dialog.net.pl...
[ciap]
Skoro tutaj jednak
utrata danych jest spowodowana szokiem termicznym,
dzialajacym w jednakowy sposob na oba uklady, to
dlaczego zwielokrotnienie liczby pamieci mialoby pomoc?

Warunki zewnętrzne działajš tak samo ale oba układy nie sš idealnie
identyczne i jest sansa że zareagujš w inny sposób, wszczególności to co w
jednym spowoduje sfałszowanie części danych w drugim jeszcze niekoniecznie.
Tak mi się wydaje ale nigdy tego nie sprawdzałem. Może lepsze byłoby
zastosowanie dwóch pamięci tego samego typu ale z różnych serii lub różnych
producentów.

Andrzej Kamieniecki


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 6 Mar 2005 13:55:04 +0100


Andrzej Kamieniecki wrote:


Warunki zewnętrzne działajš tak samo ale oba układy nie sš idealnie
identyczne i jest sansa że zareagujš w inny sposób, wszczególności to co
w
jednym spowoduje sfałszowanie części danych w drugim jeszcze
niekoniecznie.

Oczywiscie, ale prawdopodobienstwo uszkodzenia zawartosci obu
pamieci w takiej sytuacji jest znacznie wieksze niz utrata danych
spowodowana losowa awaria ukladu scalonego. Dlatego uwazam,
ze tak niewielki wzrost pewnosci nie uzasadnia wprowadzenia do
ukladu redundancji. Juz IMHO lepiej termostatowac pojedynczy EPROM.
A najlepiej uzyc zaproponowanego juz FRAMu w roli EPROMu.

Pozdrawiam
Piotr Wyderski


Poprzedni Następny
Wiadomość
Spis treści
From: "Andrzej Kamieniecki" <_andrzej.kamieniecki_at_nospam_tespol.com.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 6 Mar 2005 15:53:39 +0100


Użytkownik "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl> napisał w
wiadomości news:d0eujb$ot9$1_at_nospam_news.dialog.net.pl...
[ciap]
A najlepiej uzyć zaproponowanego juz FRAMu w roli EPROMu.

chyba tak

Andrzej Kamieniecki


Poprzedni Następny
Wiadomość
Spis treści
From: "Tomek" <kogutek4_at_nospam_op.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: 5 Mar 2005 18:47:11 +0100


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.

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

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 05 Mar 2005 21:15:26 +0100


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

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.


Poprzedni Następny
Wiadomość
Spis treści
From: "Pawel \"O'Pajak\"" <"pavel(malpa)klub.chip.pl"_at_nospam_niechciana.poczta.out>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 5 Mar 2005 22:16:51 +0100


Powitanko,

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.

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
--
"-Tato, po czym poznać małš szkodliwość społecznš?
-Po wielkiej szkodzie prywatnej" (kopyrajt: S. Mrożek)
Przy odpowiadaniu na priv zastanow sie nad moim adresem;-)

Poprzedni Następny
Wiadomość
Spis treści
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 05 Mar 2005 19:14:42 +0100


On Sat, 05 Mar 2005 18:05:26 +0100, Ireneusz Niemczyk wrote:
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.

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 :-)

Moze ktos wymyslil cos ciekawego w tym temacie?

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.


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sat, 05 Mar 2005 21:20:43 +0100


Detekcje zawsze warto zrobic.

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

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

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.

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..

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.


Poprzedni Następny
Wiadomość
Spis treści
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 06 Mar 2005 01:14:47 +0100


Użytkownik Ireneusz Niemczyk napisał:

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?

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.

--

Pozdrawiam,

A. Grodecki

Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Fri, 11 Mar 2005 16:57:56 +0100


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.

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.

Poziom bezpieczeństwa elektroniki w urzšdzeniu musi być zrównoważony z
poziomem bezpieczeństwa innych podzespołów i czasem życia maszyny.

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

Milego dnia.
__
Pzd, Irek.N.


Poprzedni Następny
Wiadomość
Spis treści
From: "jmdsh" <jmdsh_at_nospam_polbox.com>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Sun, 6 Mar 2005 13:54:09 +0100


Użytkownik "Ireneusz Niemczyk" <Adres.znajdziesz_at_nospam_w.starym.archiwum> napisał
w wiadomości news:4229E6D6.B3E97F9A_at_nospam_w.starym.archiwum...
Jak robicie licznik zliczajacy wszystkie cykle maszyny?

Ja bym dał pamięć typu FRAM i zapisywał kiedy się tylko da.
Dwa zestawy danych zapisywane z sumami kontrolnymi i sprytnym ;)
algorytmem gwarantujš przetrwanie w "prawie" każdych warunkach
jednego zestawu. Gubi się co najwyżej ostatni zapis (np. pad zasilania,
zakłocenia itp.). Oczywiście plus kontrola zasilania.

pozdrawiam
jmdsh



Poprzedni Następny
Wiadomość
Spis treści
From: jerry1111 <pleaseJERRY1111nomorespam_at_nospam_wp.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Tue, 15 Mar 2005 17:27:22 +0000


Ireneusz Niemczyk wrote:

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

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 :-)

--
Jerry


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <Adres.znajdziesz_at_nospam_w.starym.archiwum>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Tue, 15 Mar 2005 22:28:10 +0100


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!


Poprzedni Następny
Wiadomość
Spis treści
From: jerry1111 <pleaseJERRY1111nomorespam_at_nospam_wp.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Wed, 16 Mar 2005 08:53:12 +0000


Ireneusz Niemczyk wrote:

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).

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

ps. czas by tez bylo zmienic procek...w koncu!

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 :-)


--
Jerry


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: Licznik sztuk, kwestia zabezpieczenia wartosci przed utrata
Date: Fri, 18 Mar 2005 13:08:54 +0100


jerry1111 wrote:

Bede pewnie meczyc Piotra Wyderskiego na
poczatku tworzenia bibliotek odnosnie dwuprocesorowosci :-)

Poddam sie tym mekom z przyjemnoscia. :-)

Pozdrawiam
Piotr Wyderski