Niezawieszalnosc a niezawodnosc ukladu
Masz problem? Zapytaj na forum elektroda.pl
From: Jack Houseman <KILLSPAMjado_at_nospam_chello.pl>
Subject: Niezawieszalnosc a niezawodnosc ukladu
Date: Tue, 25 Oct 2005 10:25:27 +0200
Witam,
Ostatnio sporo sie tu pisalo na temat niezawieszalnosci programu
mikrokontrolera, itd... Z moich doswiadczen wynika jednak, ze nie zawsze
utrzymanie poprawnej pracy programu mikrokontrolera (po zakloceniu)
gwarantuje poprawnosc dzialania calego ukladu.
Nie zawsze mamy doczynienia z ukladem w ktorym nastepuje natychmiastowa
weryfikacja logiczna stanow wejsc i co za tym idzie wyjsc ukladu.
W takim przypadku zaklocenie, ktore zmieni stan jednego z wyjsc ukladu (np.
spowoduje to zalaczenie przekaznika), przy niezmienionym stanie wejsc
powoduje, ze taki zaklocony stan utrzymuje sie - bo procesor niczego "nie
zauwazyl" jesli chodzi o wejscia.
Wydawaloby sie ze rozwiazaniem moglaby byc okresowa weryfikacja stanow wejsc
i ponowne sprawdzenie wszystkich warunkow wejsciowych przez procesor (np.
wyzwalana co minute), ale obawiam sie, ze przy bardziej rozbudowanym
ukladzie moze to doprowadzic do malego chaosu (za duzo bodzcow na raz, w
konsekwencji spowoduje to lekkie przytkanie ukladu, przez co uklad wolniej
reaguje w tym momencie na zmiany stanow na wejsciach).
Moze jest jakies inne rozwiazanie tego problemu?
--
Pozdrawiam
Jado
>> Otwarty Projekt Automatyki Domowej [HA] http://zegaruz.republika.pl <<
From: "Pawel \"O'Pajak\"" <opajak_at_nospam_gazeta.pl>
Subject: Re: Niezawieszalnosc a niezawodnosc ukladu
Date: Tue, 25 Oct 2005 11:54:54 +0200
Powitanko,
Moze jest jakies inne rozwiazanie tego problemu?
I nawet dosyc powszechne - watchdog.
Pozdroofka,
Pawel Chorzempa
--
"-Tato, po czym poznać małą szkodliwość społeczną?
-Po wielkiej szkodzie prywatnej" (kopyrajt: S. Mrożek)
******* >>> !!! UWAGA: ODPOWIADAM TYLKO NA MAILE ->:
> pavel(ten_smieszny_znaczek)klub.chip.pl <<<<*******
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: Niezawieszalnosc a niezawodnosc ukladu
Date: Tue, 25 Oct 2005 12:22:47 +0200
Użytkownik Jack Houseman napisał:
Ostatnio sporo sie tu pisalo na temat niezawieszalnosci programu
mikrokontrolera, itd... Z moich doswiadczen wynika jednak, ze nie zawsze
utrzymanie poprawnej pracy programu mikrokontrolera (po zakloceniu)
gwarantuje poprawnosc dzialania calego ukladu.
Nie zawsze mamy doczynienia z ukladem w ktorym nastepuje natychmiastowa
weryfikacja logiczna stanow wejsc i co za tym idzie wyjsc ukladu.
W takim przypadku zaklocenie, ktore zmieni stan jednego z wyjsc ukladu (np.
spowoduje to zalaczenie przekaznika), przy niezmienionym stanie wejsc
powoduje, ze taki zaklocony stan utrzymuje sie - bo procesor niczego "nie
zauwazyl" jesli chodzi o wejscia.
No więc trzeba to tak zrobić, aby się ten niewłaściwy stan nie
utrzymywał niebezpiecznie długo.
Wydawaloby sie ze rozwiazaniem moglaby byc okresowa weryfikacja stanow wejsc
i ponowne sprawdzenie wszystkich warunkow wejsciowych przez procesor (np.
wyzwalana co minute), ale obawiam sie, ze przy bardziej rozbudowanym
ukladzie moze to doprowadzic do malego chaosu (za duzo bodzcow na raz, w
konsekwencji spowoduje to lekkie przytkanie ukladu, przez co uklad wolniej
reaguje w tym momencie na zmiany stanow na wejsciach).
To musi być jakieś specjalne zastosowanie (pobór mocy), że sprawdzanie
stanów wejść częściej niż raz na minutę stanowi problem.
Przede wszystkim układ ma działać tak jak trzeba z punktu widzenia wyjść
i wejść, a inne rzeczy trzeba umiejętnie upchnąć. Ale problemy pojawiają
siÄ™ gdzy czas liczy siÄ™ w mikrosekundach przy kilku procesach a nie
sekundach!
Zwykle program składa się z programu właściwego i zabezpieczeń jego
skutecznego działania, które mogą objętościowo pzekraczać wielkość
programu głównego. Im więcej kombinacji przypadkowych niezbezpiecznych
zjawisk, im wymagana większa niezawodność, tym zabezpień wszelkiego
rodzaju i trybów wychodzenia z sytuacji awaryjnych wiecej
--
Pozdrawiam,
A. Grodecki
From: Jack Houseman <KILLSPAMjado_at_nospam_chello.pl>
Subject: Re: Niezawieszalnosc a niezawodnosc ukladu
Date: Tue, 25 Oct 2005 12:51:40 +0200
A.Grodecki wrote:
To musi byæ jakie¶ specjalne zastosowanie (pobór mocy), ¿e sprawdzanie
stanów wej¶æ czê¶ciej ni¿ raz na minutê stanowi problem.
Sprawdzanie stanow wejsc odbywa sie co ok 0,5-2s - zalezy od wielkosci
mierzonych. Problem w tym, ze wyzwolenie dalszego dzialania ukladu
prowadzace do np. wlaczenia przekaznika nastepuje dopiero w momencie
wykrycia zmiany stanu na tym wejsciu (lub zmiany wielkosci mierzonej
jesli mamy doczynienia z wejsciem A/C). Nastepuje wiec porownywanie z
poprzednimi wielkosciami i jesli jest zmiana - robimy dalsze sprawdzanie i
dzialanie.
Jesli wiec wielkosc sie nie zmienila - a stan ten moze trwac czasami
dowolnie dlugo, to nie nastapi samoczynna zmiana stanu wyjscia.
Dodatkowo dochodzi jeszcze cos takiego jak jednorazowe wyzwolenie zdarzenia.
Jesli np. napiecie mierzone przekroczylo zadany prog 2V, to w momencie
wykrycia tego faktu nastepuje dzialanie systemu np. wlaczenie przekaznika,
a potem nastepuje blokada dalszego cyklicznego wlaczania przekaznika do
momentu zmiany napiecia ponizej zadanego progu 2V. (tak ogolnie, bo tam
jeszcze sa sprawy histeresy itd..ale tu nie ma to znaczenia)
To po to, zeby blokowac bezsensowny ruch w ukladzie, ktory i bez tego ma co
robic.
Przede wszystkim uk³ad ma dzia³aæ tak jak trzeba z punktu widzenia wyj¶æ
i wej¶æ, a inne rzeczy trzeba umiejêtnie upchn±æ. Ale problemy pojawiaj±
siê gdzy czas liczy siê w mikrosekundach przy kilku procesach a nie
sekundach!
To zalezy - jezeli mam np. transmisje poza uklad, gdzie nastepuje wyslanie
pakietu skladajacego sie z wielu bajtow + ew. do tego dochodza powtorzenia
blednych transmisji i zwiazane z tym zwloki czasowe, to czas rosnie.
Zalozylem sobie pewien skonczony bufor okrezny, do ktorego wrzucam
przychodzace asynchronicznie roskazy (do wyslania na zewnatrz) i jesli
przychodza one przypadkowo, to z reguly nie bedzie ich wiecej niz 2-3
jednoczesnie. Ale jak dam jednoczesne "zwolnienie sfory rozkazow" po
ponownym jednoczesnym sprawdzeniu wszystkich warunkow, to bufor moze sie
przepelnic.
Wyglada mi na to, ze jedynym rowiazaniem jest tutaj rozciagniecie tego w
czasie np. weryfikacja jednego warunku co 5s, a potem nastepny, itd...
To wydluzy czas weryfikacji, ale nie obciazy skokowo ukladu.
Chyba, ze ktos ma jeszcze jakies pomysly?
Zwykle program sk³ada siê z programu w³a¶ciwego i zabezpieczeñ jego
skutecznego dzia³ania, które mog± objêto¶ciowo pzekraczaæ wielko¶æ
programu g³ównego. Im wiêcej kombinacji przypadkowych niezbezpiecznych
zjawisk, im wymagana wiêksza niezawodno¶æ, tym zabezpieñ wszelkiego
rodzaju i trybów wychodzenia z sytuacji awaryjnych wiecej
No wlasnie - a wszystko kosztem cennego czasu procesora :-)
Z jednej strony czlowiek walczy, zeby umiejetnie przydzielac czas
poszczegolnym zadaniom i go nadmiernie nie obciazac zbyteczna krzatanina, a
z drugiej okazuje sie, ze to zle sluzy niezawodnosci - takiej jak tutaj.
--
Pozdrawiam
Jado
From: =?iso-8859-2?Q?Piotr_Ga=B3ka?= <piotr.galka_at_nospam_CUTTHISmicromade.pl>
Subject: Re: Niezawieszalnosc a niezawodnosc ukladu
Date: Tue, 25 Oct 2005 13:19:03 +0200
U¿ytkownik "Jack Houseman" <KILLSPAMjado_at_nospam_chello.pl> napisa³ w wiadomo¶ci
news:38cf4$435e0e3d$540adc4c$21565_at_nospam_news.chello.pl...
Nie uwa¿am siê za eksperta od mikroprocesorów, ale napiszê czego tu nie
rozumiem
Sprawdzanie stanow wejsc odbywa sie co ok 0,5-2s - zalezy od wielkosci
mierzonych. Problem w tym, ze wyzwolenie dalszego dzialania ukladu
prowadzace do np. wlaczenia przekaznika nastepuje dopiero w momencie
wykrycia zmiany stanu na tym wejsciu (lub zmiany wielkosci mierzonej
jesli mamy doczynienia z wejsciem A/C). Nastepuje wiec porownywanie z
poprzednimi wielkosciami i jesli jest zmiana - robimy dalsze sprawdzanie i
dzialanie.
Jesli wiec wielkosc sie nie zmienila - a stan ten moze trwac czasami
dowolnie dlugo, to nie nastapi samoczynna zmiana stanu wyjscia.
Co za problem od¶wie¿yæ stan wyj¶cia jak ju¿ i tak siê robi pomiar stanu
wej¶cia ?
Dodatkowo dochodzi jeszcze cos takiego jak jednorazowe wyzwolenie
zdarzenia.
Jesli np. napiecie mierzone przekroczylo zadany prog 2V, to w momencie
wykrycia tego faktu nastepuje dzialanie systemu np. wlaczenie przekaznika,
a potem nastepuje blokada dalszego cyklicznego wlaczania przekaznika do
momentu zmiany napiecia ponizej zadanego progu 2V. (tak ogolnie, bo tam
jeszcze sa sprawy histeresy itd..ale tu nie ma to znaczenia)
To po to, zeby blokowac bezsensowny ruch w ukladzie, ktory i bez tego ma
co
robic.
Jaki ruch ?
Ustawienie stanu pinu wyj¶ciowego to typowo oko³o 0,000001 s, chyba, ¿e twój
mikrokontroler pracuje z zegarem w kHz, a nie MHz to trochê wiêcej.
Tak czy siak znikomo ma³o w porównaniu z czasami o jakich mówisz.
Nie widzê te¿ problemu, aby g³ówny program jak nie ma zdarzeñ zajmowa³ siê w
kó³ko od¶wie¿aniem stanów wyj¶æ (100 razy na sekundê).
Zmiany stanów wej¶æ to ogólnie obs³uguje siê chyba w przerwaniach wiêc
g³ównemu programowi prawie nic do tego najwy¿ej raz od¶wie¿y wyj¶cia nie co
10ms, a co 20ms.
Znów pod warunkiem, ¿e nie jest to jaka¶ aplikacja o znikomym poborze
pr±du - bo wtedy szkoda tego pr±du na pracê g³ównego programu od¶wie¿aj±cego
wyj¶cia.
Ale jak s± tam przeka¼niki to chyba nie jest to taka aplikacja.
Ja ogólnie nie rozumiem problemu.
P.G.
From: Jack Houseman <KILLSPAMjado_at_nospam_chello.pl>
Subject: Re: Niezawieszalnosc a niezawodnosc ukladu
Date: Tue, 25 Oct 2005 18:04:36 +0200
Piotr Ga³ka wrote:
Nie uwa¿am siê za eksperta od mikroprocesorów, ale napiszê czego tu nie
rozumiem
Co za problem od¶wie¿yæ stan wyj¶cia jak ju¿ i tak siê robi pomiar stanu
wej¶cia ?
Bo ja dla uproszczenia nie wnikalem w szczegoly :-) - dlatego ten prosty
przyklad z przekaznikiem, ale w rzeczywistosci po drodze jest jeszcze kilka
analiz i kazde wyzwolenie zdarzenia konczy sie oprocz wysterowania danym
urzadzeniem (czy to bedzie przekaznik czy tez urzadzenie sterowane przez
siec) wyswietleniem stosownego komunikatu na LCD, sygnalem dzwiekowym itd,
itd... Jest tez mozliwosc sumowania zdarzen z kilku zrodel.
No i mamy tez przeszukiwanie pamieci EEPROM, wyciaganie rekordow i
porownywanie ich z danymi biezacymi, itd, itd...
Zdarzen wywolywanych roznymi wielkosciami wejsciowymi moze byc w sumie do
340.
Nie mozna tego wywolywac 100 razy/s.
Ale to sa juz szczegoly - mnie interesowal bardziej ogolnie ten problem.
--
Pozdrawiam
Jado