On Fri, 30 May 2014 01:37:49 +0200, bartekltg <b...@g...com>
wrote:

>On 29.05.2014 14:19, Adam Wysocki wrote:
>> Chyba że to nie C, a C++, w którym masz wyjątki, a zwalnianiem zasobów
>> zajmą się destruktory po wyjściu z zasięgu. Ale C++ to zupełnie inna
>> bajka.
>
>Wyjątek rzucony w przerwaniu po wyjściu z niego propaguje się
>od miejsca, gdzie funkcja została przerwana?
>Ostatni raz przerwanie widziałem bawiąc się 16 w bitowym
>assemblerze, więc pytanie na poważnie.
>
>pzdr
>bartekltg

Pytanie jest zasadne.

Jezeli wystepuje przerwanie, wykonywanie programu zostaje
pzrekierowane pod adres gdzie powinna znajdowac sie procedure obslugi
przerwan (interrupt handler). Ta procedure zaczyna sie wykonywac, a po
wykonaniu program powraca w miejsce okreslone pzrez programiste
piszacego procedure obslugi przerwania (na ogol jest to nastepna
instrukcja po tej przy wykonywaniu ktorej nastapilo przerwanie, albo
ta sama instrukcja)

Procedyra obslugi pzrerwania mzoe zmienic wartosc jakiegos elementu
pamieci ktory moze byc testowany przez funkcje F. W zaleznosci of tego
elementu pamieci funkcja F mzoe po sobie "posprzatac' Jedyny problem
to taki, ze jak funkcja F sie wykonuje, to nei wladomo w ktorym
momemncie nastapi pzrerwanie. Wiec nei da sie procedury F pzrerwac
natychmniast i z neij wyjsc.

Oczywiscie, procedura obslugi przerwan musi byc napisana przez tego
samego programiste ktory pisze funkcje F i cala reszte.

A.L.

do góry

W dniu 2014-05-30 04:24, A.L. pisze:
> Co to znaczy "pzrerwanie zostanei wywolane"?

Skrót myślowy, "funkcja obsługi przerwania zostanie wywołana".

--
AWa.

do góry

W dniu 2014-05-30 04:35, A.L. pisze:
> Procedyra obslugi pzrerwania mzoe zmienic wartosc jakiegos elementu
> pamieci ktory moze byc testowany przez funkcje F. W zaleznosci of tego
> elementu pamieci funkcja F mzoe po sobie "posprzatac' Jedyny problem
> to taki, ze jak funkcja F sie wykonuje, to nei wladomo w ktorym
> momemncie nastapi pzrerwanie. Wiec nei da sie procedury F pzrerwac
> natychmniast i z neij wyjsc.

To jest oczywiste i czyste podejście.
Ja chciałbym mieć coś co pozbędzie się funkcji F bez jej wiedzy i zgody.
Czyli z funkcji obsługi przerwania wrócimy nie w miejsce w którym główny
program został zatrzymany ale do punktu B.
Problemem jest posprzątanie po F.

Wygląda na to, że ten pomysł może przynieść więcej problemów niż ich
rozwiązać.
Zostanę chyba przy WDT...

--
AWa.

do góry

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/

do góry

Andrzej W. <a...@w...pl> wrote:

> Ja chciałbym mieć coś co pozbędzie się funkcji F bez jej wiedzy i zgody.
> Czyli z funkcji obsługi przerwania wrócimy nie w miejsce w którym główny
> program został zatrzymany ale do punktu B.
> Problemem jest posprzątanie po F.

Jeśli naprawdę bardzo chcesz, to możesz użyć setjmp i longjmp, ale ja
osobiście nie podjąłbym się używania longjmp w ISR (to może spowodować
problemy, które ciężko będzie przewidzieć). W assemblerze to mooooże
jeszcze (analogicznym mechanizmem - skokami), ale w C nie...

Coś takiego:

jmp_buf b;

...

if (setjmp(b) == 0)
{
// tu jesteśmy pierwszy raz
A();
F();
B();
}
else
{
// tu jesteśmy po longjmp

// należałoby przywrócić to, co zostało zmienione w prologu
// funkcji obsługi przerwania (przywrócić przerwania,
// rejestry, zdjąć ze stosu adres powrotu i zignorować go)

B();
}

...

ISR()
{
longjmp(b, 1);
}

A potem jak dodasz coś do ISR przed longjmp i kompilator odłoży na stos
jakiś rejestr, to będziesz musiał pamiętać o zdjęciu go tam, gdzie jest
komentarz "tu jesteśmy po longjmp"...

Poczytaj:

http://pl.wikipedia.org/wiki/Longjmp
http://en.wikipedia.org/wiki/Setjmp.h

> Wygląda na to, że ten pomysł może przynieść więcej problemów niż ich
> rozwiązać.

A to na pewno.

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

do góry

bartekltg <b...@g...com> wrote:

> Wyjątek rzucony w przerwaniu po wyjściu z niego propaguje się
> od miejsca, gdzie funkcja została przerwana?

Szczerze mówiąc nie wiem, ale skoro rzucenie wyjątku powoduje zwijanie
stosu, to tego bym się spodziewał (przy czym na różnych architekturach
różnie się wraca z przerwań, czasem inaczej niż z normalnych funkcji, nie
sądzę żeby kod obsługujący wyjątki miał możliwość realnego sprawdzenia, że
throw poszło podczas obsługi przerwania - ale może na niektórych
architekturach tak?)...

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

do góry

On 2014-05-30, Adam Wysocki <g...@s...invalid> wrote:
> bartekltg <b...@g...com> wrote:
>
>> Wyjątek rzucony w przerwaniu po wyjściu z niego propaguje się
>> od miejsca, gdzie funkcja została przerwana?
>
> Szczerze mówiąc nie wiem, ale skoro rzucenie wyjątku powoduje zwijanie
> stosu, to tego bym się spodziewał (przy czym na różnych architekturach
> różnie się wraca z przerwań, czasem inaczej niż z normalnych funkcji, nie
> sądzę żeby kod obsługujący wyjątki miał możliwość realnego sprawdzenia, że
> throw poszło podczas obsługi przerwania - ale może na niektórych
> architekturach tak?)...

Ale to miało być C, zdaje się. O jakich wyjątkach mowa?

--
Secunia non olet.
Stanislaw Klekot

do góry

Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> wrote:

> Ale to miało być C, zdaje się. O jakich wyjątkach mowa?

Bartek pytał o to po cytacie:

> Chyba że to nie C, a C++, w którym masz wyjątki, a zwalnianiem zasobów
> zajmą się destruktory po wyjściu z zasięgu. Ale C++ to zupełnie inna
> bajka.

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

do góry

Szarym od mżawki świtem Fri, 30 May 2014 09:12:18 +0200, Andrzej W.
wyrzucił pustą ćwiartkę i oznajmił:

> W dniu 2014-05-30 04:35, A.L. pisze:
>> Procedyra obslugi pzrerwania mzoe zmienic wartosc jakiegos elementu
>> pamieci ktory moze byc testowany przez funkcje F. W zaleznosci of tego
>> elementu pamieci funkcja F mzoe po sobie "posprzatac' Jedyny problem
>> to taki, ze jak funkcja F sie wykonuje, to nei wladomo w ktorym
>> momemncie nastapi pzrerwanie. Wiec nei da sie procedury F pzrerwac
>> natychmniast i z neij wyjsc.
>
> To jest oczywiste i czyste podejście.
> Ja chciałbym mieć coś co pozbędzie się funkcji F bez jej wiedzy i zgody.
> Czyli z funkcji obsługi przerwania wrócimy nie w miejsce w którym główny
> program został zatrzymany ale do punktu B.
> Problemem jest posprzątanie po F.

Dokładnie: można w procedurze obsługi przerwania zamiast tak jak
zazwyczaj wraca się z przerwania po prostu robić co innego. Pytanie
jest faktycznie jak posprzątać, a tu brak danych. Zazwyczaj byłoby to:
- jeżeli return adress i rejestry F są na stosie: podmienić i iret
(instrukcja bodajże 8086).
- stos wypadałoby zresetować. Przed wykonaniem F wypadałoby zapisać
SP i jakąś magiczną trampoliną po przerwaniu przywrócić SP sprzed F,
albo lepiej: zapisać sobie w znajomym miejscu rejestry i SP sprzed
wykonania F i w procedurze obsługi przerwania a) sub sb, ile-trzeba,
b) przywrócić pozstałę rejestry, c) jakoś zakończyć obsługę przerwania
- hardware: wypadałoby posprzątać wszystko co F robiła z hardware,
ale jak rozumiem przerywa się F bo coś jej i tak ze sprzętem nie idzie,
może jakiś reset? reinicjalizacja?

No a potem jak dobrze pójdzie mamy stan taki jakby F nigdy nie była
wykonana...

Wszystko co napisałem powyżej zależy też od samego CPU, mechanizmu
przerwań, reguł obsługi rejestrów, zestawu instrukcji itp.

> Wygląda na to, że ten pomysł może przynieść więcej problemów niż ich
> rozwiązać.
> Zostanę chyba przy WDT...

Tak czy inaczej bez odrobiny assemblera się nie da, chyba że przez setjmp.

--
Edek

do góry

On Fri, 30 May 2014 16:01:39 +0000 (UTC), Edek
<e...@g...com> wrote:

>Dokładnie: można w procedurze obsługi przerwania zamiast tak jak
>zazwyczaj wraca się z przerwania po prostu robić co innego. Pytanie
>jest faktycznie jak posprzątać, a tu brak danych. Zazwyczaj byłoby to:
>- jeżeli return adress i rejestry F są na stosie: podmienić i iret
> (instrukcja bodajże 8086).


To nei tak prosto, bo F mogla w momencie pzrerwania robic rozne
rzeczy, na przykald byc w polowie alokowania pamieci czy w polowie
zapisywania czegos do zbioru. Wiec nie mozan jej pzrerwac gdzie sie
chce. Na ogol ustala sie punkty w ktorych procedure moze byc
bezpiecznie pzrerwana z lista operacji do wykonania w ramach
"czyszczenia"

takie cos mozna latwo zrobic w asemblerze, ale nei widze latwego
sposobu aby to zrobic w C

A.L.

do góry