Andrzej W. <awa_wp@na_wp_oczywiscie.pl> wrote:

> Tak, chciałbym takiego watchdoga na funkcję. Na cały systemie mam
> sprzętowego, ale zabijanie całego systemu jest zauważalne dla użytkownika.
> Niestety wszystkie funkcje które chcę nadzorować są funkcjami obsługi
> sprzętu, a sprzęt czasem lubi robić sobie jaja.

Idea szczytna, ale mam wrażenie że takie podejście ("ubicie" funkcji)
zaprowadzi Cię na manowce... gdyby to było inne środowisko - takie, w
którym masz możliwość kontrolowanego zwolnienia zasobów, używanych przez
coś, co zawiodło, to można byłoby się pokusić o "ubijanie", dlatego
wspomniałem o C++, wyjątkach i RAII, ale w czystym C nie da się z tego co
wiem tego elegancko zrobić.

Co w tych funkcjach obsługi sprzętu czeka? Czekasz na ustawienie jakiegoś
pinu? To w tej pętli możesz też czekać na ustawienie flagi z przerwania
(jeżeli chcesz mieć jeden timeout na całą funkcję) i jeżeli flaga będzie
ustawiona, to wtedy wywołaj reset sprzętu. Albo jeżeli ma być timeout na
ustawienie pinu, to np. zapamiętać liczbę ticków (inkrementowaną przez
timer) i sprawdzać, czy aktualna liczba ticków jest większa, niż
zapamiętana plus określony timeout (pamiętając oczywiście o
przepełnieniach).

> Plan był taki, że jeśli ląduje w funkcji obsługi przerwania, to
> sprawdzam która funkcja się zawiesiła, robię restart sprzętu
> wykorzystywanego przez tę funkcję, zeruje jej zmienne i skaczę do punktu
> B i program kręci się dalej.

Reset sprzętu to też czekanie... nie rób takich rzeczy w przerwaniu. Niech
funkcja obsługi przerwania trwa jak najkrócej - inkrementacja licznika,
czy ustawienie flagi.

Przerwanie to szczególny stan dla MCU - głównie dlatego, że inne
przerwania (oraz ponowne wystąpienie tego samego przerwania) są wtedy
zablokowane. Można je odblokować, ale trzeba bardzo dokładnie przemyśleć
wszystkie możliwe scenariusze, inaczej będzie problem, łącznie z
możliwością przepełnienia stosu i nadpisania heapa (zakładając, że
nie ma MMU, ale skoro mówisz, że to MCU, to pewnie bez MMU).

> Niestety to wszystko ma się dziać poza kodem funkcji, ma to być
> zabezpieczenie na wypadek nieprzewidzianego, nieudokumentowanego
> zachowania sprzętu prowadzącego do pozostania funkcji np. w
> nieskończonej pętli.

Temat jest poważniejszy niż się na początku wydaje - czy system ma ukrywać
błędy sprzętu i być niezawodny mimo wszystko, czy jeżeli coś jest nie tak,
to należy to zgłosić, żeby nie doprowadzić do większej katastrofy (bo
program nie wie, co się dzieje, stan urządzenia jest niespójny).

Jeżeli masz sprzęt, który czasami zawodzi, trzeba go resetować i chcesz
lub musisz zapewnić wtedy prawidłowe działanie programu, to najlepiej
zaimplementować to resetowanie w funkcjach obsługujących ten sprzęt.
Jeżeli chcesz zabezpieczyć się na wszelki wypadek, bo może stać się
cokolwiek... to tak naprawdę i tak nie przewidzisz wszystkich możliwości.

Pamiętam sytuację, gdy w jednym modelu terminala płatniczego był moduł
Bluetooth, który (na dostępnym wtedy firmware) czasami się zawieszał.
Dodałem po prostu obsługę jego resetowania do klas, które go obsługiwały,
jego zawieszenie było traktowane po prostu jak normalny stan, z którym
program potrafi sobie poradzić.

Tak naprawdę o ile nie robisz sprzętu, który nigdy nie może zawieść (np.
sprzęt lotniczy, medyczny, automotive), to ja w krytycznej sytuacji, gdy
sprzęt zawodzi (a nie jest to jego normalna cecha) po prostu wywaliłbym
błąd i zresetował urządzenie. Przypadki lotnicze, medyczne itd. to ogólnie
inna bajka, tam stosuje się różne standardy (np. MISRA), których normalnie
raczej nie ma potrzeby stosować.

Kojarzę, że kiedyś była taka dyskusja między Linusem (maintainerem kodu
jądra Linuksa) a kimś innym od innego jądra jakiegoś innego Uniksa, nie
pamiętam dokładnie jakiego. W tym innym jądrze było dużo kodu, który miał
radzić sobie z nieprzewidywalnymi sytuacjami. W Linuksie przyjęto inne
podejście - jeżeli coś wymyka się spod kontroli i nie wiadomo, co się
stało, to nie ma sensu próbować ratować sytuacji - jest kernel panic
(który można skonfigurować tak, żeby automatycznie restartował kernel).
W uC odpowiednikiem może być po prostu watchdog. A że user to zauważy...
trudno, ma niesprawny sprzęt.

--
SELECT finger FROM hand WHERE id = 3;
http://www.chmurka.net/