Problemy C - Przerwania

Autor: Dondu

Na początek zapamiętaj najważniejszą zasadę:

PRZERWANIA POWINNY WYKONYWAĆ SIĘ

JAK NAJSZYBCIEJ

I wcale nie mam na myśli szybkiego zegara procesora np. 64MHz, tylko sposób pisania programu.

Do częstych problemów z przerwaniami należą:

1. brak VOLATILE w deklaracji zmiennych
2. używanie niewłaściwych lub starych wektorów przerwań
3. oczekiwanie w przerwaniu
4. włączanie przerwań w funkcji obsługującej przerwanie
5. wykonywanie skomplikowanych obliczeń w przerwaniu

---

1. BŁĄD: Brak VOLATILE w deklaracji zmiennych

To najbardziej popularny problem opisałem tutaj: Problemy C - VOLATILE

---

2. BŁĄD:  Używanie niewłaściwych lub starych wektorów przerwań

To także istotny choć nie zawsze powodujący błędy problem. Aktualnie standardem jest używanie wektorów przerwań według standardu ISR(), a nie SIGNAL().

Dokładny opis tego problemu z listą wektorów i mikrokontrolerów znajdziesz tutaj: AVR Interrupts

---

3. BŁĄD: Oczekiwanie w przerwaniu

To bardzo często spotykany błąd polegający na wstawianiu w procedurę obsługi przerwania:

• funkcji opóźnienia (delay)
• pętli oczekujących na pojawienie się jakiegoś zdarzenia

Funkcje opóźnienia:

ISR(tutaj wektor przerwania){  //wystąpiło przerwanie

   ....    //jakiś kod
 
   _delay_ms(100);   //opóźnienie

   ...     //jakiś kod
}

Pętla oczekująca:

ISR(tutaj wektor przerwania){  //wystąpiło przerwanie

   ....    //jakiś kod
 
   while (ADCSRA & (1<<ADSC));     //oczekiwanie w pętli na zakończenie pomiaru

   ....    //jakiś kod

}

Wprowadzenie opóźnienia za pomocą DELAY czy dowolnej PĘTLI może doprowadzić do sytuacji, w której przerwania będą tracone z powodu dużych opóźnień, ponieważ nowe przerwania przychodzą zanim poprzednie się zakończą.

Co robią wtedy początkujący? Włączają przerwania w funkcji obsługi przerwania, co tylko powiększa katastrofalne działanie programu, co opisuję poniżej.


Są też tacy, którzy wiedzą, że nie powinni stosować DELAY w przerwaniu, ale mimo tego robią to, i w dodatku o czasie 1 sekundy (!!!), jak na przykład kol:

nsmarcin
Za kod z góry przepraszam
Wiem, że nie powinienem stosować delay w przerwaniach :-)

... a później dziwią się, że program nie działa prawidłowo.

---

4. BŁĄD: Włączanie przerwań w funkcji obsługującej przerwanie

To jeden z największych błędów jakie może popełnić początkujący programista robiąc tak:

ISR(tutaj wektor przerwania){  //wystąpiło przerwanie

   ....   //jakiś kod
 
   sei();   //włącz przerwania

   ...    //jakiś kod
}

Dlaczego? Ponieważ:

• odblokowanie przerwań, podczas wykonywania procedury obsługi przerwania, bardzo często prowadzi do nieprzewidywalnego działania programu, przez co ciężko jest ustalić przyczynę błędów.
• wiele kolejnych nie zakończonych przerwań może doprowadzić do przepełnienia stosu
• i pewnie jeszcze wiele innych problemów

Dla baaaaardzo doświadczonego programisty, włączenie przerwań w funkcji przerwania (w specyficznych przypadkach) może być dobrym rozwiązaniem, ale Ty tego nie rób.

Czy można na wszelki wypadek dodać cli() i sei(), na przykład tak?:

ISR(tutaj wektor przerwania) 
{ 
   cli(); 
   ...     //jakiś kod
   sei(); 
}

Zobaczmy, co na to datasheet mikrokontrolera

Tłumaczenie:

Datasheet ATmega8 - str. 11
Bit I (flaga zezwolenia na przerwania globalne) jest zerowana sprzętowo w momencie wystąpienia przerwania, a ustawiany przez instrukcję RETI w celu umożliwienia następnych przerwań.

Jak widzisz nie musisz wstawiać rozkazów cli() oraz sei() w funkcji obsługi przerwania.

Jeżeli jednak to zrobisz, to wygenerujesz sobie problem. Zobaczmy co zrobi kompilator GCC dla mikrokontrolerów AVR (asemblerowy kod wynikowy funkcji obsługi przerwania):

//prolog
PUSH      R1             Push register on stack
PUSH      R0             Push register on stack
IN        R0,0x3F        In from I/O location
PUSH      R0             Push register on stack
CLR       R1             Clear Register
PUSH      R24            Push register on stack

CLI                      Global Interrupt Disable //Twój rozkaz cli()
                                                  //nic nie zmienia bo już 
                                                  //przerwania są wyłączone

 ... //jakiś program


SEI                      Global Interrupt Enable  //Twój rozkaz sei() 
                                                  //od tego miejsca przerwania 
                                                  //włączasz - widzisz problem?
//epilog
POP       R24            Pop register from stack
POP       R0             Pop register from stack
OUT       0x3F,R0        Out to I/O location
POP       R0             Pop register from stack
POP       R1             Pop register from stack
RETI                     Interrupt return

Problem który sobie wygenerujesz na własne życzenie polega na tym, że począwszy od linii 17 kodu powyżej przerwania będą włączone, choć powinny być włączone dopiero ostatnim rozkazem RETI. Oznacza to, że jeżeli od linii 17-tej nastąpi przerwanie, zostanie ono obsłużone pomimo, że poprzednie jeszcze nie zostało zakończone. Skutki opisałem na początku tego punktu.

---

5. BŁĄD: Przerwanie z funkcjami z ukrytym oczekiwaniem

Ten problem jest związany z punktem nr 3 (opisany wyżej), choć bezpośrednio programista tego nie widzi. Chodzi o to, że w przerwaniu nie powinno się wykorzystywać funkcji, które zawierają w sobie pętle oczekujące lub opóźnienia.

Niby oczywiste, ale często początkujący nie są świadomi, że wykorzystywane przez nich funkcje bibliotek kompilatora lub innych (np. do obsługi wyświetlacza LCD, komunikacji, itd.), zawierają w sobie pętle oczekujące lub opóźnienia.

Przykład:

Częstym błędem jest takie stosowanie przerwań (wyświetlanie w przerwaniu):

ISR(tutaj wektor przerwania){  //wystąpiło przerwanie

     ....    //jakiś kod
 
     LCD_GoTo(1,1);
     LCD_WriteText('Test LCD');

     ...     //jakiś kod
}

Wykorzystamy (nota bene bardzo dobrą) bibliotekę obsługi wyświetlaczy LCD, której autorem jest Radosław Kwiecień: źródło

Oto definicje kilku najczęściej wykorzystywanych funkcji:

void LCD_Clear(void){
     LCD_WriteCommand(HD44780_CLEAR);
     _delay_ms(2);
}

void LCD_GoTo(unsigned char x, unsigned char y){
     LCD_WriteCommand(HD44780_DDRAM_SET | (x + (0x40 * y)));
}

void LCD_Home(void){
     LCD_WriteCommand(HD44780_HOME);
     _delay_ms(2);
}

Zauważyłeś na pewno, że dwie z powyższych funkcji zawierają opóźnienia _delay_ms() generujące opóźnienie, aż 2 ms(!).

Ale nie tylko to jest problemem, ponieważ wszystkie wyżej pokazane funkcje używają funkcji LCD_WriteCommand(). Zobaczmy więc, co w niej jest:

void LCD_WriteCommand(unsigned char commandToWrite){
     LCD_RS_PORT &= ~LCD_RS;
     _LCD_Write(commandToWrite);
     while(LCD_ReadStatus()&0x80);
}

I tutaj następna niespodzianka, czyli pętla while() oczekująca na potwierdzenie przyjęcia komendy przez wyświetlacz.

Podobnie ma się sprawa z funkcją LCD_WriteText(), której definicja wygląda tak:

void LCD_WriteText(char * text){
   while(*text) LCD_WriteData(*text++);
}

Tutaj nie dość, że jest pętla wysyłająca po kolei znaki napisu, który chcesz wyświetlić (inaczej się nie da), to jeszcze wykorzystuje dla przesłania każdego znaku funkcję LCD_WriteData(), wyglądającą tak:

void LCD_WriteData(unsigned char dataToWrite){
     LCD_RS_PORT |= LCD_RS;
     _LCD_Write(dataToWrite);
     while(LCD_ReadStatus()&0x80);
}

A to oznacza dla każdego wysyłanego do LCD znaku napisu, oczekiwanie w pętli na zakończenie jego odbioru przez LCD, czyli łącznie kupa czekania :-)


Stosowanie bibliotek w funkcjach przerwania, powinno zostać poprzedzone analizą ich zawartości, by nie narazić się na problem zbyt długiej realizacji przerwania. 

---

6. BŁĄD: Wykonywanie skomplikowanych obliczeń w przerwaniu

To jeden z częściej pojawiających się problemów. W skutkach jest on podobny do punktu nr 5, czyli zbyt długiego czasu obsługi przerwania. Mikrokontroler nie nadąża wykonywać funkcji przerwania przed nadejściem następnych przerwań, przez co gubi przerwania.

W funkcjach obsługi przerwań staraj się nie wykonywać bardzo skomplikowanych obliczeń.

W szczególności problem ten dotyczy wykonywania w funkcji obsługi przerwania operacji na danych zmiennoprzecinkowych.

---

Flagi - rozwiązaniem problemu

Rozwiązaniem problemu zbyt długiego czasu wykonywania się funkcji obsługi przerwania może być zastosowanie metody ustawiania w przerwaniu jedynie jakiejś flagi (zmiennej), a wykonywanie właściwego kodu przerwania, dopiero w pętli głównej programu po stwierdzeniu, że flaga została ustawiona przez przerwanie. 

W takim przypadku pamiętaj, że flaga musi być jako volatile, co opisałem w punkcie nr 1 niniejszego artykułu.

Przykład obsługi przerwań z wykorzystaniem flagi:

//flaga musi być zmienną globalną z volatile
volatile char flaga_1;

//funkcja obsługi przerwania
ISR(tutaj wektor przerwania){

  // ... jakiś kod

  //ustaw flagę
  flaga_1 = 1;   

}


//program główny
int main(void){

  // ... jakiś kod

  //pętla główna
  while(1){

     // ... jakiś kod

     //sprawdzamy, czy wystąpiło przerwanie
     if(flaga_1){
       
       //tak, wystąpiło przerwanie

       flaga_1 = 0;  //zgaś flagę
  
       // ... kod, który ma się wykonać w odpowiedzi na przerwanie

     } //koniec if()

     // ... jakiś kod

  } //koniec pętli głównej
}

Takie rozwiązanie ma oczywiście także pewną wadę.
Mianowicie, kod który zostanie wykonany w odpowiedzi na przerwanie nie jest wykonywany dokładnie w momencie rozpoczęcia wykonywania funkcji przerwania. Dzieje się tak dlatego, że przerwanie ustawia jedynie flagę, a pętla główna wykonuje się w bliżej nieokreślonym miejscu. Musi więc dojść do momentu sprawdzania flagi i dopiero wtedy wykona się właściwy kod przerwania.

Dlatego sam musisz zadecydować, czy takie opóźnienie ma dla Ciebie istotne znaczenie. Nie ma to np. znaczenia dla projektu typu zegarek (opóźnienie nie wpłynie na dokładność odmierzanego czasu), ale dla projektu typu bardzo szybki sterownik generujący impulsy z dużą dokładnością, może mieć to znaczenie.

Jeżeli przerwanie ma jedynie ustawiać flagę, to takie rozwiązanie jest nieekonomiczne. W takiej sytuacji należy w pętli głównej sprawdzać flagę przerwania i gasić ją programowo po jej wykryciu (w AVR uważaj na ten wyjątek).

Taki kod wykonywać się będzie szybciej ponieważ nie jest generowany skok do funkcji obsługi przerwania i nie są odkładane na stos niezbędne rejestry.