Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Watchdog gdzie umieszczać reset?

wwmajor 20 Lip 2005 12:38 3704 30
  • #1 20 Lip 2005 12:38
    wwmajor
    Poziom 14  

    Po raz kolejny zwracam się do was i liczę na pomoc.
    Z tego co ja wiem watchdog to sprzętowy licznik działający sobie niezależnie od tego co wykonuje sobie napisany przez nas program. Efektem przepełnienia tego licznika jest całkowity reset mikrokontrolera.
    Aby nam się mikro ciągle nie resetował w programie umieszczamy polecenie wyzerowania licznika Wathdog tak aby zaczął liczyć od początku.

    Moje pytanie brzmi.
    Gdzie powinniśmy umieszczać polecenie zerowania Watchdog?
    Czy w głównej pętli programu, podprogramach, a może w podprogramie wywoływanym przy pomocy któregoś z timerów?

    Bo jeśli umieścimy reset Watchdog w miejscu gdzie program się zapętlił to okaże się że mimo błędu procek się nie zrestartuje.

    Używam mikrokontrolerów AT90S2313 i ATMEGA8

    0 29
  • #2 20 Lip 2005 12:43
    elektryk
    Poziom 42  

    wwmajor napisał:
    a może w podprogramie wywoływanym przy pomocy któregoś z timerów?
    Tak nie wolno robić, bo nawet jak się procesor zapętli to przerwania będą wykonywane i całość straci sens.
    wwmajor napisał:
    Bo jeśli umieścimy reset Watchdog w miejscu gdzie program się zapętlił to okaże się że mimo błędu procek się nie zrestartuje.
    Niestety trzeba podejść do tego zdroworozsądkowo, czasem długie pętle bedą miały czas wykonywania dłuższy niż okres timera watchdog i trzeba wstawić w nie, a czasem bardzo krótkie pętle (np oczekiwanie na zewnętrzny sygnał), bedą mogły się wykonywać dłużej niż okres timera watchdog i też trzeba wstawić rozkaz.

    0
  • #3 20 Lip 2005 13:43
    diag
    Spec od samochodów

    Podstawowa sprawa jest taka:
    Watchdog stosujesz tylko w uzasadnionych przypadkach, a najlepiej nigdy.
    Wynika to z tego ,że procek po resecie może być trudny do opanowania z rejestrami i danymi w pamięci.
    Sprawa jeszce bardziej sie komplikuje gdy masz czasowo zbliżony Watchdog do przerwania, bo nie wiesz dokładnie jak sie on zachowa(rozrzut parametrów).

    0
  • #4 20 Lip 2005 23:09
    wwmajor
    Poziom 14  

    Witam.
    Ja muszę użyć watchdoga, bo robię urządzenie do którego będzie ciężki dostęp więc w przypadku zapętlenia muszę odciąć prąd w całym budynku aby odciąć prąd prockowi. Przypadkowy reset układu nie będzie miał większego znaczenia, ale zapętlenie to poważny kłopot.
    Pewnie nad watchdogiem bym się nie zastanawiał, ale mój sterownik będzie podłączony do sieci nieprzerwanie przez kilka lat. Więc jakieś zapętlenie kiedyś musi się zdarzyć. Wolę, aby raz na miesiąc przypadkowo się resetował niżeli żeby raz na pół roku zapętlił na amen.
    Parę słów na temat tego jak piszę programy.

    Za wszelką cenę unikam pętli innych niż FOR unikam jak ognia poleceń GOTO (to zrozumiałe) Staram się wszystko robić na warunkach IF.

    Z tego wynika, że moje programy mają jedną pętlę główną i kupę podprogramów oraz kilka procedurek.
    Nie zdarzyło mi się żeby program kiedykolwiek sam z siebie się zapętlił, więc nie mam wyobrażenia gdzie coś takiego może się przydarzyć.

    Jeśli np. programy zapętlają się w głównej pętli to znaczy że reset trzeba by umieścić w jakimś często wywoływanym podprogramie.

    Jeśli zaś zapętlają się wewnątrz podprogramu to należy umieścić reset w głównej pętli.
    Problem polega na tym że ja nie mam pojęcia gdzie programy się zapętlają.

    P.S. Zapomniałem napisać że programuję w BASCOM AVR

    0
  • #5 21 Lip 2005 01:31
    Machoni
    Poziom 13  

    wwmajor napisał:
    P.S. Zapomniałem napisać że programuję w BASCOM AVR


    Mozna sie domyslic.. po tym:
    Cytat:
    unikam jak ognia poleceń GOTO
    w polaczeniu z
    Cytat:
    Używam mikrokontrolerów AT90S2313 i ATMEGA8


    Ale do rzeczy. Licznik watchdoga musisz zerowac, jak juz wspomniano, w kazdym podprocesie, ktory wykonywalby sie w najmniej sprzyjajacych warunkach dluzej niz max czas dopuszczalny przez watchdoga - tak patrze do noty 2313 i to moze byc nawet 1,9 sek (czy nawet 6 sek). No coz.. w baszlomie ciezko jest przewidziec co ile bedzie sie wykonywac, bo tak naprawde nigdy niewiadomo jak to zostanie skompilowane ;)
    Ale resetuj tez mozliwie najrzadziej. "Zapetlenie" w glownym programie... tu chyba niewiele poradzisz... chyba ze inny timer w przerwaniu sprawdzajacy stan rzeczy, balbym sie raczej zawieszenia sie programu niz jego zapetlenia.

    Acha... troche wyzej improwizuje... wiesz, ja unikam bascoma tak, jak ty GOTO ;)

    0
  • #6 21 Lip 2005 09:29
    diag
    Spec od samochodów

    Uczciwie mówiąć to problem z WatchDogiem jest niczym w porównwiu z tym co przychodzi po sieci i przewodach. Zadbaj o dobry uklad resetu i tlumienie stanow nieustalonych na wejściach. A z bascomem to jeszcze potrzeba wiele sczęscia by bylo wszystko OK.

    0
  • #7 21 Lip 2005 12:57
    GienekS
    Poziom 32  

    Zawsze cały program to wielka jedna lub kilka pętli. Jak się gdzieś "zapętli" to jest poprostu źle napisany. Poprostu zły algorytm postępowanie na występujące sytuacje. Niestety jak czegoś nie przewidzisz to będzie "klops" to nawet ten "pies" Ci nie pomoże. No chyba że akurat go wstawisz we właściwym miejscu programu.

    0
  • #8 22 Lip 2005 18:25
    starob
    Poziom 25  

    jeśli chcesz sprawdzać program w wielu miejscach to zastosuje flagi ustawiane w punktach kontrolnych a ustawienie tych flag sprawdzaj w procedurze obsługi Watchdoga. Możesz wtedy sprawdzić obecność w wielu punktach i wyzerować (lub nie)
    timer, z wyzerować wszystkie fagi. Wtedy procedura nawet dobrze jak byłaby obsługiwana w przerwaniach zegarowych (nawet do tego dedykowanych)

    Dodano po 2 [minuty]:

    troche literówek (:

    0
  • #9 22 Lip 2005 19:20
    Tdv
    Poziom 33  

    starob napisał:
    jeśli chcesz sprawdzać program w wielu miejscach to zastosuje flagi ustawiane w punktach kontrolnych a ustawienie tych flag sprawdzaj w procedurze obsługi Watchdoga. Możesz wtedy sprawdzić obecność w wielu punktach i wyzerować (lub nie)
    timer, z wyzerować wszystkie fagi. Wtedy procedura nawet dobrze jak byłaby obsługiwana w przerwaniach zegarowych (nawet do tego dedykowanych)

    Dodano po 2 [minuty]:

    troche literówek (:


    Kolego: jak nie masz o czymś pojęcia to może nie zabieraj głosu...
    Prawdziwy programista wiesza się razem ze swoim programem... No niby tak ale to na dzień dzisiajszy nie byłoby już ani jednego. Konia z rzędem temu, kto mi zagwarantuje, że każdy napisany przez neigo program jest w 100% pewny i nie wymaga watchdoga (mowa oczywiście o programie rozbudowanym w jakimś stopniu). W przypadku krytycznych wymagań należy stosować także watchdog zewnętrzny, w przypadku bardzo krytycznych watchdoga zewnętrznego o skomplikowanym kasowaniu np. kombinacją kilku sygnałów wywoływanych w odpowiedniej kolejności - wtedy prawdopodobieństwo zapętlenia pomimo obecności watchdoga zdecydowanie maleje. W przypadku stosowania i wewnętrznego i zewnętrznego ich kasowanie rodzielić w taki sposób aby część procesów kasowała jeden, część drugi i najlepeiej tak, żeby żaden z procesów nie mógł kasowac obydwóch.
    Generalnie bezpieczeństwo urządzeń zbudowanych w oparciu o elementy programowalne jest skomplikowanym problemem i zostało ujęte w odpowiednich normach.

    0
  • #10 22 Lip 2005 19:42
    starob
    Poziom 25  

    Tdv
    Oświeć mnie i powaj moją teorie, bo mowa to jest jałowa

    0
  • #11 22 Lip 2005 19:53
    Tdv
    Poziom 33  

    starob napisał:
    Tdv
    Oświeć mnie i powaj moją teorie, bo mowa to jest jałowa


    Służę uprzejmie:

    starob napisał:
    ....sprawdzaj w procedurze obsługi Watchdoga...


    Co to jest procedura obsługi Watchdoga i co w niej można sprawdzić?
    Watchdog (co już zresztą zostało wyżej napisane) to zwykły licznik i jedyna operacja jaką można na nim wykonać to skasowanie tego licznika. Nie skasowanie go na czas powoduje zerowanie mikrokontrolera.

    0
  • #12 22 Lip 2005 20:17
    starob
    Poziom 25  

    deklarujesz znienną np byte:Watch
    w programie wstawiasz w miejscach "zagrożonych" kontrolki przejścia prze dany fragment
    Watch=Watch or 01h
    .....
    Watch=Watch or 02h
    .....
    Watch=Watch or 04h
    w tym przypadku do ośmiu

    w procedurze obsługi przerwania zegaroweg sprawdzasz czy Watch=np 0FFh
    jeśli tak to oznacza, że program przeszedł przez wszystkie punkty kontrolne wtedy:
    zerujesz watchdoga(ten twój zwykły licznik albo generujesz impuls na pinie podtrzymującym Watchdoga zewnętrznego)
    zerujesz zmienną Watch

    jak tego już nie rozumiesz 22 Lip 2005 19:20 Re: Watchdog gdzie umieszczać reset?

    --------------------------------------------------------------------------------

    starob napisał:
    jeśli chcesz sprawdzać program w wielu miejscach to zastosuje flagi ustawiane w punktach kontrolnych a ustawienie tych flag sprawdzaj w procedurze obsługi Watchdoga. Możesz wtedy sprawdzić obecność w wielu punktach i wyzerować (lub nie)
    timer, z wyzerować wszystkie fagi. Wtedy procedura nawet dobrze jak byłaby obsługiwana w przerwaniach zegarowych (nawet do tego dedykowanych)

    Dodano po 2 [minuty]:

    troche literówek (:


    Kolego: jak nie masz o czymś pojęcia to może nie zabieraj głosu...

    0
  • #13 22 Lip 2005 20:22
    Tdv
    Poziom 33  

    SOrry, że tak dosadnie: co ty bredzisz? Jak to ma niby zapobiegać zawieszeniu procesora? wpisz tu kod w C np. konkretnego przykladu.
    To co napisałeś jest bez sensu, bo wystarczy, że przejdzie przez punkt w ktorym Watch=0xFF - jak w przerwaniu sprawdzićz czy Watch == 0xFF to będzie równe, a procesor minął 99% programu i jeździ po pętli Watch=0xFF.

    Zapytam po raz drugi: co to jest procedura obsługi Watchdoga??

    0
  • #14 22 Lip 2005 21:08
    starob
    Poziom 25  

    data uchar Watch; //flagi kontrolne



    void procedura_1 (void) {
    Watch=Watch || 1; // ustawiasz flage nr1
    ....
    ....
    ....
    }

    void procedura_2 (void) {
    Watch=Watch || 2; // ustawiasz flage nr2
    ....
    ....
    ....
    }
    void procedura_3 (void) {
    Watch=Watch || 4; // ustawiasz flage nr3
    ....
    ....
    ....
    }

    //itd...


    void procedura_obsuluga_Watchdoga (void) interrupt x { //przerwanie od timera x

    if (Watch==0xff) { //czy był we wszystkich punktach kontrolnych
    // jesli <>0xff to znaczy że gdzieś nie był albo wisi
    Licznik_Watchdoga=0;
    //lub przy zewnętrzny
    Pin_podtrzymujący=1;
    Pin_podtrzymujący=0;
    // lub co ci się tylko podoba
    Watch=0;
    //jeśli procek się zawiesi po tej instrukcji nigdy nie będzie spełniony ww warunek
    //jeśli timer przestanie działać nigdy nie odświerzy watchdoga;

    }

    }


    void main (void)
    {
    //inicjacja przerwań
    //inicjacja licznika na czas krótszy od czasu podtrzymania watchdoga
    while (1){
    Watch=Watch || 8; // ustawiasz flage nr4
    ......
    ......
    .....
    Watch=Watch || 16; // ustawiasz flage nr6
    ......
    ......
    .....
    // itd aż do osmiu

    }
    }

    0
  • #15 22 Lip 2005 21:21
    Tdv
    Poziom 33  

    1.Jak sie zawiesi to co sie dzieje? Jak to ma resetowac uC?
    2. Co jaki czas obsluga przerwania tajmera i na jakiej podstawie to wyznaczysz?
    3. Jak okreslisz, ktore flagi powinny byc ustawione w momencie wejścia do przerwania? Program, ktory ciagle wykonuje wszystkie sowje procedury jest jak mikolaj - ponoc jest ale nikt nie widzial.
    4. Co sie stanie jak w "będąc w malinach" procesor wykona instrukcję wyłączenia przerwan?
    5. Jak w pkt. 4 tyle, że instrukcja niekontrolowanego przypisania do Watch wartości zgodnej z oczekiwana w przerwaniu?

    Takie zabezpiecznie programu nie daje wcale większej pewności, niż przmyślany, przesymulowany i dobrze napisany i przetestowany program w uC bez użycia watchdoga.

    0
  • #16 22 Lip 2005 22:15
    starob
    Poziom 25  

    tdv
    Przeczytałem większośc twoich postów na forach,
    jesteś zwykłym pieniaczem tylko krytykujesz i nic mądrego nie wnosisz.Jak widać wyżej od kilku godzi stukasz literki i nic. wwwmajor chce mieć watchdoga tylko nie wie jak go obsłużyć nie - nie widziałem ani jednej konstruktywnej podpowiedz ztwojej strony.
    Może napiszesz taki "przmyślany, przesymulowany i dobrze napisany i przetestowany program w uC bez użycia watchdoga. "
    Dlatego,że jestem cierpliwy i uważm,że idj***e należy tłumaczyć odpowiadam:
    1.od godziny wałkowany nieodświeżany watchdog
    2.na podstawie danych katalogowych zastosowanego watcha (wymagany okres podtrzymawania)
    3.to jest szablon- jak będe pisał taki program to będe wiedzał
    4.przestanie być odświerzany i wykona pkt.1
    5.odświerzy się tylko raz,jeśli jest to notoryczne to wyjdze w testach "przmyślanego, przesymulowanego i dobrze napisanego i przetestowanego" programu .
    Jak już tego nie pojmujesz to walnij sobie w łep i się nie męcz.

    0
  • #17 22 Lip 2005 22:16
    Machoni
    Poziom 13  

    Starob:

    cos mi sie wydaje ze Ty na sile probujesz zaprojektowac seftwareowego watchdoga, ale niezabardzo Ci to wychodzi.

    Moze nie kombinuj wiecej co ??

    Ps. Do pytan Tdv dodam cos, co jesli ciagle zglaszane bedzie przerwanie o priorytecie wyzszym niz Twojego timera (a jakies tam zawsze sa) - bo zrozumialem ze z jakiegos tam timera kozystac zamierzasz ??

    Pps. Myslisz zbyt sekwencyjnie, nawet jak na uC.

    0
  • #18 22 Lip 2005 22:26
    starob
    Poziom 25  

    machoni
    patrz wyżej odp4.

    Dodano po 1 [minuty]:

    zaproponuj coś

    0
  • #19 22 Lip 2005 22:32
    LordBlick
    VIP Zasłużony dla elektroda

    Tdv napisał:
    Zapytam po raz drugi: co to jest procedura obsługi Watchdoga??
    To jest "Watch" ale bez "dog"... ;) Może być ewentualnie obsługa inicjalizacji watchdoga w tych procesorach, w których jest on konfigurowalny.
    A dla potomności : watchdog to licznik resetujący układ po upłynięciu odliczanego czasu. W celu zapobieżeniu resetowi układu program wykonujący się bez zarzutu powinien co jakiś czas resetować ten licznik, aby liczył od nowa - dodajemy sobie jeszcze trochę czasu do resetu. Gdy nastapi zwis, nic nie odwlecze czasu odliczanego i układ się zresetuje. Odpowiednio przemyślany program powinien przewidzieć takie przypadki i je obsługiwać. Amen. ;)

    0
  • #20 22 Lip 2005 22:41
    starob
    Poziom 25  

    literki literki,żadnej propozycji.
    przenieście na wyższy poziom abstrakcji.
    Zaproponujcie nawet najgłupsze rozwiązanie.
    Zatrudne?

    0
  • #21 22 Lip 2005 22:44
    LordBlick
    VIP Zasłużony dla elektroda

    OK, w odpowiedzi na prowokację ;)
    Inicjalizacja (przy wyłączonych przerwaniach - dwie instrukcje muszą się wykonać w odstepie nie większym niż 4 cykle procesora) :

    Code:
    #define WDP_16K      0                           // ~16ms
    
    #define WDP_32K                        (1<<WDP0)   // ~32ms
    #define WDP_64K            (1<<WDP1)               // ~64ms
    #define WDP_128K         (   (1<<WDP1)|   (1<<WDP0))   // ~0,13s
    #define WDP_256K   (1<<WDP2)                     // ~0,26s
    #define WDP_512K   ((1<<WDP2)|            (1<<WDP0))   // ~0,5s
    #define WDP_1M      ((1<<WDP2)|   (1<<WDP1))            // ~1s
    #define WDP_2M       ((1<<WDP2)|   (1<<WDP1)|   (1<<WDP0))   // ~2s
    ;Proc InitWatchDog()
       ldi TempA, 1<<WDCE | 1<<WDE
       out WDTCR, TempA
       ldi TempA, WDP_128K | 1<<WDE
       out WDTCR, TempA
    Obsługa (ja umieszczam na początku pętli głównej, odpowiedno dopasowując czas licznika od watchdoga, nie używam bzdurnych konstrukcji pętlowych typu waitms, jak nie ma nic do roboty, to sio do pętli głównej sprawdzać, czy rzeczywiście nie ma nic do roboty, od sprawdzania czasu to są przerwania timer-a, a nie bzdurne pętle ;)) :
    Code:
    wdr
    --
    Pozdrawiam, Daniel

    0
  • #22 22 Lip 2005 23:16
    Machoni
    Poziom 13  

    starob napisał:
    machoni
    patrz wyżej odp4.

    Dodano po 1 [minuty]:

    zaproponuj coś


    Uszanowalem Twoj pseudonim, wiec bylbym wdzieczny gdybys nauczyl sie tego samego.

    A do rzeczy. Skoro watchdog dziala, to po kiego diabla kombinujesz (i komplikujesz) z tymi Twoimi flagami. Bez sensu.

    0
  • #23 23 Lip 2005 06:24
    Tdv
    Poziom 33  

    starob napisał:
    tdv
    Przeczytałem większośc twoich postów na forach,
    jesteś zwykłym pieniaczem tylko krytykujesz i nic mądrego nie wnosisz.Jak widać wyżej od kilku godzi stukasz literki i nic. wwwmajor chce mieć watchdoga tylko nie wie jak go obsłużyć nie - nie widziałem ani jednej konstruktywnej podpowiedz ztwojej strony.
    Może napiszesz taki "przmyślany, przesymulowany i dobrze napisany i przetestowany program w uC bez użycia watchdoga. "
    Dlatego,że jestem cierpliwy i uważm,że idj***e należy tłumaczyć odpowiadam:
    1.od godziny wałkowany nieodświeżany watchdog
    2.na podstawie danych katalogowych zastosowanego watcha (wymagany okres podtrzymawania)
    3.to jest szablon- jak będe pisał taki program to będe wiedzał
    4.przestanie być odświerzany i wykona pkt.1
    5.odświerzy się tylko raz,jeśli jest to notoryczne to wyjdze w testach "przmyślanego, przesymulowanego i dobrze napisanego i przetestowanego" programu .
    Jak już tego nie pojmujesz to walnij sobie w łep i się nie męcz.



    OK, przyznaje się: jestem zerem. Przy tobie, któryś w czasie kilkunastu minut przeczytał ponad 800 moich postów (zajrzyj na mój licznik - większość to conajmniej połowa +1 i to bez względu na to w jaki sposób obsługujez watchdoga) jestem malutki jak pantofelek. Z takim ekspertem już się nie odważę polemizować.
    BTW to my tu piszemy na trzeźwo bo rozwiązujemy problemy techniczne i "wyższy poziom abstrakcji" zostawiamy dla takich jak Ty, którzy piszą co wiedzą, choć nie wiedzą co piszą.

    0
  • #24 23 Lip 2005 15:21
    starob
    Poziom 25  

    Pytanie „Watchdog gdzie umieszczać reset?” w oderwaniu od całości systemu jest pytaniem abstrakcyjnym a nie „problemem technicznym”. System to nie tylko mikroprocesor ale jakieś urządzenia peryferyjne które wstępnie obrabiają dane pochodzące od procesu który jest przez niego kontrolowany.
    Hipotetycznie mam „problem techniczny” (wymagane jest):
    -system z zewnętrznym UART który obiera losowa znaczki i wiem ,że te znaczki muszą przychodzić ni później niż co 1sek;
    - konfigurowalny scalak który podsyła mi dane nie później niż 0.5sek
    - i obieg pętli głównej na trwać nie dłużej niż 0.3sek

    Zapomnijcie na chwile o konkretnym procesorze i konkretnym watchdogu.
    Proszę o znalezienie metody jak to wszystko kontrolować i co zrobić w przypadku gdy coś jest nie tak

    0
  • #25 24 Lip 2005 12:26
    starob
    Poziom 25  

    Cisza!!!!

    Gdzie umieścić reset w takim programie?
    Light'I: Gdzie tu jest pętla główna?


    #include <rtx51.h>
    /******************************************************************************/
    /* Task 0 'init': Initialize */
    /******************************************************************************/
    void init (void) _task_ INIT { /* program execution starts here */
    serial_init (); /* initialize the serial interface */
    os_create_task (CLOCK); /* start clock task */
    os_create_task (COMMAND); /* start command task */
    os_create_task (LIGHTS); /* start lights task */
    os_create_task (KEYREAD); /* start keyread task */
    os_delete_task (INIT); /* stop init task (no longer needed) */
    }


    /******************************************************************************/
    /* Task 2 'clock' */
    /******************************************************************************/
    void clock (void) _task_ CLOCK {
    while (1) { /* clock is an endless loop */

    }
    }

    /******************************************************************************/
    /* Task 6 'get_escape': check if ESC (escape character) was entered */
    /******************************************************************************/
    void get_escape (void) _task_ GET_ESC {
    while (1) { /* endless loop */

    }
    }


    /******************************************************************************/
    /* Task 1 'command': command processor */
    /******************************************************************************/
    void command (void) _task_ COMMAND {

    while (1) { /* endless loop */

    }
    }


    /******************************************************************************/
    /* Task 3 'blinking': runs if current time is outside start & end time */
    /******************************************************************************/
    void blinking (void) _task_ BLINKING { /* blink yellow light */

    while (1) { /* endless loop */

    }
    }


    /******************************************************************************/
    /* Task 4 'lights': executes if current time is between start & end time */
    /******************************************************************************/
    void lights (void) _task_ LIGHTS { /* traffic light operation */

    while (1) { /* endless loop */

    }
    }


    /******************************************************************************/
    /* Task 5 'keyread': process key stroke from pedestrian push button */
    /******************************************************************************/
    void keyread (void) _task_ KEYREAD {
    while (1) { /* endless loop */

    }
    }

    0
  • #26 24 Lip 2005 13:19
    marek_Łódź
    Poziom 35  

    Tdv napisał:
    Takie zabezpiecznie programu nie daje wcale większej pewności, niż przmyślany, przesymulowany i dobrze napisany i przetestowany program w uC bez użycia watchdoga.


    Urządzenie bez watchdoga w umownych 99 przypadkach na 100 po zakłóceniu procesora już nie wróci do pracy. Urządzenie z watchdogiem w 99 przypadkach na 100 się zresetuje i przynajmniej spróbuje pracować dalej. W tym kontekscie dowolnie skonfigurowany watchdog ma sens. Nie bardzo rozumiem, co masz przeciwko idei punktów kontrolnych. Jest to jeden z możliwych do realizacji sposobów sprawdzenia, czy program się odmelduje tam, gdzie był spodziewany i zresetowanie gdy coś jest nie tak.

    Co do takich czy innych obiekcji to odpowiedź jest chyba jedna. Nie ma możliwości stworzenia w 100% niezawodnego układu. Chodzi tylko o to, żeby zwiększyć tę niezawodność, a w tym pomaga dobrze skonstruowany i oprogramowany watchdog.

    Jeszcze inaczej - watchdog nie jest po to, by stwierdzić, że jest dobrze bo tego się nie da sprawdzić (nawet zdublowanie całego systemu daje "tylko" zmniejszenie stopy błędów np. o kolejne 6 rzędów), lecz po to by stwierdzić, że jest ewidentnie źle.

    I jeszcze jedno - nie ma żadnej gwarancji, że po zakłóceniu wbudowany watchdog procesora się nie wyłączy. I co wtedy? Pozostaje watchdog czysto sprzętowy.

    Nie bardzo też rozumiem ideę ratowania watchdogiem źle napisanego programu (no chyba, ze w fazie uruchomienia). Oddanie do eksploatacji programu, który co jakiś czas się resetuje bo "się zapętlił" to jakaś paranoja.

    0
  • #27 24 Lip 2005 14:07
    LordBlick
    VIP Zasłużony dla elektroda

    Mały apel do co niektórych :
    Swoje wstawki emocjonalne zachowajcie dla ludzi we własnym otoczeniu, bo nikogo na tym forum nie znacie dostatecznie dobrze, aby wyrazić o nim rzetelną opinię, a stwarzać sobie nowych nieprzychylnych dla kilku krótkich i pozornych chwil poczucia dowartościowania nie ma sensu... Raczej starajcie się wyrażac rzeczowo i czytelnie, unikając epitetów.
    @starob :
    1. Nie bawię się na co dzień w C, więc się nie wypowiadałem szerzej, czy jest cos w tym niestosownego ?
    2. Pętlę główna w twoim kodzie jest ukryta, ale istnieje, gdyż 8051 to maszyna jednozadaniowa i podział na zadania jest tu czysto softwarowy. Reset watchdoga może być tu np. jeszcze jednym zadaniem odpowiednio sprawdzającym stany pozostałych zadań - np. w odpowiednim czasie każde zadanie powinno ustawić własną flagę, a zadanie testujące ją zeruje i po pewnym czasie sprawdza - jak któraś z flag nie jest ustawiona, to nie resetuje watchdoga i następuje reset procesora. Jak sama zwiśnie to też nie będzie problemu... ;)
    --
    Pozdrawiam, Daniel

    0
  • #28 24 Lip 2005 15:18
    starob
    Poziom 25  

    Święte słowa!!!
    Na forum poczułem się jak na "komisji śledczej" - bez mocnych "kwitów" siedż cicho.

    0
  • #29 30 Lip 2005 00:25
    wwmajor
    Poziom 14  

    Szkoda że z takiego fajnego tematu zrobił się taki bełkot.

    Wyraziłem się jasno ja nie chcę ratować programu Watchdogiem nie chcę również oszczędzać przy jego pomocy na zabezpieczeniach samego procka itp.
    Pewnie się ze mną zgodzicie Watchdog służy do zabezpieczania procka przed błędami i wypadkami, których nie da wyeliminować na drodze programowej i sprzętowej.

    Zawsze staram się aby na końcu mojego tematu była wyczerpująca odpowiedź. Więc wybrałem ze śmietniska ważne informacje.

    1. Elektryk
    a. Nie wolno reseować watchdoga w przerwaniach „bo nawet jak się procesor zapętli to przerwania będą wykonywane i całość straci sens.”
    b. „Czasem długie pętle bedą miały czas wykonywania dłuższy niż okres timera (…) np. oczekiwanie na zewnętrzny sygnał”

    2. marek_Łódź
    a. „urządzenie bez watchdoga w umownych 99 przypadkach na 100 po zakłóceniu procesora już nie wróci do pracy. urządzenie z watchdogiem w 99 przypadkach na 100 się zresetuje i przynajmniej spróbuje pracować dalej.”
    b. „Nie ma możliwości stworzenia w 100% niezawodnego układu. Chodzi tylko o to, żeby zwiększyć tę niezawodność, a w tym pomaga dobrze skonstruowany i oprogramowany watchdog.”

    Najbardziej trafił z podpowiedzią (moim skromnym zdaniem) kolega starob. Pod wpływem jego postów wymyśliłem coś takiego.

    1. Tworzymy zmienną Flaga o wartości &B00000000
    2. Spośród podprogramów wybieramy te co do których jesteśmy pewni że często są wywoływane.
    3. Wykonywanie podprogramu powoduje ustawienia przyporządkowanego mu bita na „1”. Np. Podprogram 1 zmienia zmienną flaga na &B00000001 następnie wywołanie podprogramu 4 zmienia zmienną flaga na &B00001001 itd.
    4. W przerwaniu TIMERA (pozorna sprzeczność z kolegą elektrykiem) tworzymy warunek który sprawdza czy zmienna flaga == &B00111111 (liczba zależy od ilości sprawdzanych podprogramów)
    jeśli zmienna jest równa to resetujemy watchdoga i wszystko ładnie sobie działa.
    5. Jako że watchdog mógłby się troszkę za często resetować z racji długo wykonujących się instrukcji proponuję dołączenie w miejscu gdzie sprawdzana jest flaga z wzorcem (&B00111111) dodatkowej zmiennej „błąd”.

    IF flaga <> &B00111111 (któryś z podprogramów się nie wykonał) THEN
    resetujemy watchdoga
    flaga = &B00000000 (bo będziemy po raz kolejny sprawdzać czy wszystkie podprogramy się wykonały)
    BLAD = BLAD + 1
    Dopiero jeśli zmienna BLAD osiągnie pewną wartość wtedy przestajemy resetować watchdoga i tym samym restartujemy procesorek.
    Zalety:
    Zastosowanie Flag sprawia, że zapętlenie się nawet w kilku podprogramach restartuje procka.
    Zablokowanie procka w przerwaniu również spowoduje restart
    Manipulowanie przy zmiennej BLAD zmniejszy liczbę przypadkowych resetów (w moim sterowniku oświetlenia nawet 1s zawieszenie się program będzie niezauważalne dla użytkownika).

    0
  • #30 31 Lip 2005 22:23
    marek_Łódź
    Poziom 35  

    Czyli mamy metodę punktów kontrolnych z programowym odliczaniem resetu procesora. Znowu można by się czepiać, że program może się zapętlić na instrukcji zerowania Twojej zmiennej BŁĄD i co wtedy. Tyle, że najpierw by się trzeba zastanowić jakie jest prawdopodobieństwo takiego zdarzenia (myślę, że jest to coś bliskiego zeru absolutnemu).

    0
TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo