Niezawieszalnosc a niezawodnosc ukladu

Oct 25, 2005 5 Replies

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?



Powitanko,

I nawet dosyc powszechne - watchdog. Pozdroofka, Pawel Chorzempa

Użytkownik Jack Houseman napisał:

No więc trzeba to tak zrobić, aby się ten niewłaściwy stan nie utrzymywał niebezpiecznie długo.

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

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.

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?

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.

U¿ytkownik "Jack Houseman" snipped-for-privacy@chello.pl napisa³ w wiadomo¶ci news:38cf4$435e0e3d$540adc4c$ snipped-for-privacy@news.chello.pl...

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 ?

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.

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.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required