Re: Przerwanie w przerwaniu 8051 i AVR

Jul 09, 2003 8 Replies


Witam!


> Byæ mo¿e kto¶ z Was wie czy z wnêtrza procedury obs³ugi przerwania mo¿na wymusiæ software'owo wyst±pienie innego przerwania?
> Chodzi o przypadek, w którym mamy przerwanie o wysokim priorytecie, które wykonuje jakie¶ szybkie operacje, np. próbkuje jak±¶ liniê

Nie wiem czy masz takie selektywne maskowanie przerwan bo malo znam 8051 Ogolnie zagniezdzanie przerwan to wyzsza szkola jazdy. W malych prockach ogolnie nalezy tego unikac. Mozesz bardzo szybko przepelnic stos i wogole latwo jakis blad zrobic ktory bedzie straszny w skutkach. Szczgolnie gdy maska jest jedna moga ci sie tak slicznie spietrzyc przerwania ze sie nie pozbierasz.


Dobra metoda jest dla testowania prawidlowosci czasowych obslugi przerwan zrobic male wstawki (kod warunkwy) do programu ktore beda ci przelaczac stan na jakims wyjsciu na ten czas nie uzywanym do innych celow. W ten sposob zobaczysz jak dlugo program ci sterczy w obsludze przerwania jak sie okaze ze dluzej siedzi w przerwaniu niz poza nim to juz jest kiepskawo.


Pozdro Grzechu

Troszke to zawile napisane i nie do konca rozumie, ale wywolywan przerwan mozna dokonywac na rozne sposoby. Mowa tu o 51. Nawet gdy masz przerwanie na wyzszym poziomie, mozna wywolac przerwanie z nizszego poziomu stosujac odpowiednie triki. Polegac moze na tym, ze przerwanie z wyzszego poziomu na samym poczatku zmienia swoj priorytet na nizszy, a temu drugiemu nadac wyzszy priorytet. W trakcie zmiany tych priorytetow moze dojsc do sytuacji, ze bedzie potrzebne 2 przerwanie. Aby to nie zostalo zapomniane, trzeba pomyslec o jakims ukladzie czasowym. To tyle jesli chodzi o przerwania hardwarowe. W softwer. trzeba to zrobic za pomoca wykorzystania odpowiednik komorek flag. Tez napisalem zawile, ale moze uda ci sie zrozumiec moj tok rozumowania.

W opisanym przypadku naj³atwiej chyba bêdzie ustawiæ okre¶lon± flagê, która jest sprawdzana w programie g³ównym. Wywo³ana zostanie procedura, która mo¿e zostaæ przerwana dowolnym przerwaniem.

pozdr.

A nie byłoby prościej zamiast programowo wywoływać przerwanie zmieniając bity - poprostu wykonać CALL przerwanie_X ??

Ale po co? Ca³± ide± "przerwania" jest w³asnie fakt, ¿e PRZERYWA ono dzia³anie programu g³ównego w nieoczekiwanym i nieprzewidywalnym momencie... Je¶li Ty wiesz, ¿e w tym "momencie", w tej linii kodu, potrzebujesz wywo³aæ jak±¶ PROCEDURÊ to u¿ywasz CALL. Ale nie ma sensu tego nazywaæ przerwaniem, zapisywaæ na stosie kontekst procesora i powracaæ z przerwania RETI. Wystarczy zwyczajny CALL procedury z kodu w³asnie.

U¿ytkownik "Janusz Ch" snipped-for-privacy@wp.TOWYTNIJ.pl> napisa³ w wiadomo¶ci news:beh34a$bt8$ snipped-for-privacy@atlantis.news.tpi.pl...

A czy nie da siê tego zrobiæ w ten sposób, ¿e na koñcu "szybkiego" przerwania o wysokim priorytecie ustawiam ODPOWIEDNI bit steruj±cy, wychodzê z obs³ugi przerwania i natychmiast wywo³ywana jest procedura obs³ugi przerwania o ni¿szym priorytecie (spowodowane ustawieniem tego ODPOWIEDNIEGO bitu)? Mam nadziejê, ¿e piszê wystarczaj±co jasno. Nie jestem tego pewien... Wojtek

Tylko czas reakcji będzie zupełnie inny - tu masz natychmiast (us).

Do autora: możesz tak zrobić, sprawdzone.

MC

Nie bardzo rozumiem gdzie tkwi ró¿nica, czy móg³by¶ rozwin±æ? I które konkretnie rozwi±zanie bêdzie Twoim zdaniem szybsze? Nie widzê ¼ród³a opó¼nienia... Chodzi Ci o reti?

Chodzi o to, że pętla główna może potrzebować czasu na zbadanie znacznika który ustawiło przerwanie chyba, że będzie zajęta czekaniem tylko na jego stan.

MC

Join the Discussion

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

Didn't find your answer?

Ask the community — no account required