Ankieta lub metoda oparta na przerwaniu

Ankiety należy unikać tam, gdzie to możliwe, ponieważ zwykle niepotrzebnie zjada dużo cykli procesora (chyba, że (a) będziesz ankieta tylko na krótki czas lub (b) możesz sobie pozwolić na sen przez rozsądny czas w pętli ankiety). Marnowanie cykli procesora jest złe nie tylko z punktu widzenia wydajności, ale także zwiększa zużycie energii, co może być problemem w przypadku wbudowanych aplikacji zasilanych baterią.

Decydując się na ankietę lub przerwanie, musisz w pełni zrozumieć naturę wydarzenia, które próbujesz śledzić i swoją odpowiedź na nie.

Przerwania nie wymagają przetwarzania, gdy nic się nie dzieje, ale wymagają całej uwagi, gdy coś się dzieje. Jeśli zdarzenie jest zewnętrzne i ma hałaśliwe krawędzie lub szybkie impulsy, może to powodować poważne bóle głowy z przerwami, musisz być ostrożny przy konfiguracji przerwań.

W tym przykładzie procedura przerwania reaguje na promień lasera, który stał się jasny i ustawia się na zdarzenie, w którym zostaje zablokowany: {]}

   BEAM_INTR_EN = TRUE;   /*re-enable the beam interrupts*/

   /*Set the beam interrupt for the next clear to blocked event*/
   BEAM_INTR_EDGE = CLEAR_TO_BLOCKED;
   BEAM_INTR_FLAG = FALSE; /*Clear the interrupt*/

Istnieją 2 słabe punkty tego kodu: 1) jeśli wiązka lasera została ponownie zablokowana przed usunięciem znacznika przerwania (BEAM_INTR_FLAG = FALSE;). Przerwanie zostanie pominięte, a kod nie będzie zsynchronizowany ze stanem wiązki lasera.

2) Podczas ustawiania przerwań albo w rutynie tła, albo dla wyższego priorytetu niż priorytet ten kod jest włączony, należy zachować ostrożność podczas włączania przerwania. Jeśli flaga przerwania była już ustawiona (nieprawidłowo) przed jej włączeniem, procedura przerwania zostanie wywołana nieprawidłowo, gdy tylko zostanie włączona i być może dla niewłaściwej krawędzi.

Najprostszym sposobem naprawienia 1) jest podwójne sprawdzenie po skonfigurowaniu przerwania, jeśli wystąpiło, Wymuś przerwanie. Aby naprawić 2) Przenieś włączanie przerwań do po podwójnym sprawdzeniu:

   /*Set the beam interrupt for the next clear to blocked event*/
   BEAM_INTR_EDGE = CLEAR_TO_BLOCKED;
   BEAM_INTR_FLAG = FALSE; /*Clear the interrupt*/

   /*Double check beam state to see if it has already gone blocked*/
   if (BEAM_STATE == BEAM_BLOCKED)
   {
      BEAM_INTR_FLAG = TRUE; /*Force the interrupt to re-enter the ISR after exiting*/
   }
   BEAM_INTR_EN = TRUE;    /*re-enable the beam interrupts*/

The wymuszenie przerwania powoduje, że system pracuje z tą samą maszyną stanu, zmuszając go jedynie do ręcznego zakrycia martwego pola.

W zasadzie:

   Set the edge to detect the next interrupt event
   Clear the interrupt flag
   if (the event has already occurred)
   {
      Set the interrupt flag to force the interrupt
   }
   Enable the interrupt

Jeśli czas odpowiedzi na zdarzenie musi być spójny (np. 1ms +/-10us po tym, jak linia wejściowa przekroczy poziom, transmituje sygnał zdarzenia), to zazwyczaj najlepsze są przerwy.

Jeśli czas odpowiedzi na zdarzenie musi być w określonym czasie (np. w ciągu 1 ms od linii wejściowej idącej w górę, prześlij sygnał zdarzenia), wówczas najlepiej byłoby przerwać

Problem z przerwaniami polega na tym, że trzeba zacząć myśleć o wątku i że dwa kawałki kodu mogą uzyskać dostęp do tych samych danych w tym samym czasie.

Przerwania są również dobre dla procesorów, aby przejść do trybów niskiego poboru mocy (sleep/idle itp.) czekając, aż coś się wydarzy.

Powiedziawszy to wszystko, może dać bardzo krótki czas reakcji na zdarzenia, jeśli jest tylko jedna rzecz do zrobienia przez procesor, często przerywać sprzęt zajmuje kilka cykli, aby odpowiedzieć na zdarzenie, podczas gdy zrobi to ciasna pętla Wyborcza.

Jeśli zdarzenie nie jest krytyczne i potencjalnie hałaśliwe (np. ktoś naciska przełącznik), to polling pozwala na proste filtrowanie bez pominięcia długoterminowych przejść. Częstym błędem jest wielokrotne sprawdzanie podczas ustawiania rzeczy:

void fnInitialiseSystem(void)
{
   if (MODE_INPUT == MODE_A) /*First polling of the MODE_INPUT*/
   {
      PR2 = PR2_MODE_A;
   }
   else
   {  
      PR2 = PR2_MODE_B;
   }
   OpenTimer2( TIMER_INT_ON &
               T2_PS_1_1     &
               T2_POST_1_8   );

   if (MODE_INPUT == MODE_A) /*Second polling of the MODE_INPUT*/
   {
      CurrentMode = MODE_A;
      PROBE_INT_EDGE = CLEAR_TO_BLOCKED;
   }
   else
   {  
      CurrentMode = MODE_B;
      PROBE_INT_EDGE = BLOCKED_TO_CLEAR;
   }
}

W powyższym przykładzie MODE_INPUT jest zewnętrznym przełącznikiem, jeśli dwa razy MODE_INPUT jest ankietowany, to zachowanie jest nieoczekiwane. Kiedy odczytując tego typu sygnały najlepiej jest użyć filtrowania, aby zdecydować o długoterminowym stanie wejścia i wykonać działania na filtrowanej wersji.

Na przykład z wyłącznikiem odskakującym wystarczy regularnie sprawdzać Przełącznik (co 1ms?) a jeśli ich liczba (powiedzmy 16) różni się (przełącznik zamknięty) od wersji filtrowanej (przełącznik otwarty), zaktualizuj wynik i wykonaj wymaganą akcję. Bądź ostrożny z aliasingiem sygnału, sygnał oscylacyjny może wyglądać stabilnie!

Przykład korzystanie z ankiet i przerwań jest, ponownie, do korzystania z wejścia, które nie zmienia się często, ale jest hałaśliwe, gdy to robi. Po raz kolejny dobrym przykładem jest przełącznik: kod może ustawić przerwanie, aby sprawdzić zmianę stanu przełącznika, gdy wystąpi przerwanie, przełącznik może być regularnie sprawdzany, aż stan przełącznika będzie "stabilny" (albo zmieniony, albo z powrotem do tego, co było). Daje to zaletę niskiego narzutu przetwarzania, gdy nic się nie dzieje, i filtrowania szumów, gdy coś się dzieje.

Czasami trzeba użyć obu. Na przykład, jeśli zdarzenia są sporadyczne, ale występują z dużą prędkością; być może trzeba najpierw odpowiedzieć na przerwanie, a następnie przed ponownym włączeniem ankiety przerwań, aby sprawdzić, czy inne zdarzenie już wystąpiło, unikając niektórych kosztów przełączania kontekstu przerwania. Uważam, że interfejs sieciowy Linuksa działa w tym trybie.

Oto kilka ciekawych linków, na które natknąłem się analizując metody ankiet vs przerwań - http://web.engr.oregonstate.edu/ ~ traylor / ece473 / wykłady/przerwania. pdf - bardzo ciekawe link http://www.atarimagazines.com/compute/issue149/60_Interrupts_made_easy.php
http://www.electro-tech-online.com/micro-controllers/8440-interrupt-vs-polling.html http://www.microchip.com/forums/m397196-print.aspx http://www.cs.huji.ac.il/course/2006/67630/Lectures/interrupts.pdf http://sunsite.nus.edu.sg/LDP/LDP/tlk/node86.html

Mam nadzieję, że to pomoże.

Krótką odpowiedzią jest użycie metody przerwania, gdy ankieta jest zbyt wolna. (mówiąc zbyt wolno, mam na myśli, że jeśli ankieta traci dane, konieczna jest metoda przerwania)

Zasadniczo tryb ankietowany jest używany w przypadku, gdy tryb przerwania jest niedostępny z powodów sprzętowych lub programowych. Tak więc tryb przerwania jest bardziej korzystny z punktu widzenia zużycia energii, wydajności itp. (zgadzam się z Paulem R). Tryb ankietowany może być również używany przy prototypowaniu, dla rdzeni bez konieczności korzystania z urządzeń peryferyjnych i do niektórych celów testowych.

Przerwania są preferowane, gdy wymagane jest małe opóźnienie. Jeśli badasz jakiś warunek N razy na sekundę, to średnio odkryjesz ten warunek w czasie o połowę 1 / n Po tym, jak faktycznie się wydarzył.

Sondowanie jest czasami preferowane, gdy wymagany jest bezwzględny deterministyczny czas. Ze względu na swoją naturę przerwy mogą występować w nieprzewidywalnych czasach i znacznie komplikują analizę czasu, podczas gdy w systemach ankietowanych stosunkowo łatwo jest udowodnić, że satysfakcja z terminu.

Zawsze używaj przerwania. W ten sposób nigdy nie stracisz danych. W aplikacjach sterowanych zdarzeniami lub gwintowanych nawet najwolniejsze sygnały powinny być sterowane przerwaniem.

Jedyny czas, kiedy powinieneś użyć ankiety, to Korzystanie z harmonogramu, a bufory na twoim sprzęcie są wystarczająco głębokie, aby zapewnić brak utraty danych.

Istnieje wiele ograniczeń projektowych, które mogą napędzać decyzję. Moja aplikacja ma kombinację przerwania i ankiety:

• zewnętrzne i wewnętrzne źródła zegara wyzwalają przerwania - jest to kluczowe dla oba znaczniki czasu są dokładne, abyśmy mogli je zsynchronizować.
• przychodzące wiadomości seryjne wywołują przerwania. Odbiornik FIFOs musi być serwisowany przed ich przepełnieniem.
• wiadomości wychodzące wywołują przerwy, gdy FIFO jest częściowo puste - musi być napełnione przed niedociągnięcia.
• semafory ISR ustawione w tle. Ma to 2 zalety:
  • obliczenia potrzebne do obsługi przychodzących zdarzeń mogą być długie; jeśli zostaną pozostawione w ISR, może to opóźnić innych ISR poza ich terminami serwisowymi.
  • zdarzenia mogą być sekwencjonowane. Na przykład, pętla polling może zapewnić, że obliczanie X zawsze występuje między gromadzeniem danych ADC a analizowaniem wiadomości przychodzącej, nawet jeśli czasami wiadomość dociera nieco wcześniej niż się spodziewałem.

Tryb Polling może być przydatny w systemach ze zdarzeniami o wysokiej częstotliwości, gdzie narzut związany z wprowadzaniem i opuszczaniem programów obsługi przerwań zużywa więcej cykli procesora niż zwykłe polling. Na przykład w routerze IP można użyć polling, aby zmaksymalizować przepustowość procesora dostępną dla przetwarzania pakietów.

Nie chcesz, aby twój host czekał w pętli zajętości przez długi czas, a także sondowanie może stać się nieefektywne, gdy częste kontrole są dokonywane dla danych, które nie są tam często. Więc tam dla, Jeśli t on host i urządzenie są zarówno szybkie, a następnie ankiety, jeśli dość szybko.

O wiele lepiej wybrać Interrupt based design w porównaniu do polling based ponieważ ankiety oparte jest wadliwe w tym sensie, że oczekuje, że dane zostaną zwrócone w każdej ankiecie. Teraz możesz powiedzieć, że obejdę tę sprawę, w której jedna ankieta zwróciła mi błąd, ale po cholerę marnować wszystkie cykle procesora, sondując coś, gdy równie dobrze może zwrócić błąd ?? A oczekiwanie, że ankieta może się nie udać, jest praktycznym scenariuszem produktu.

Interrupt based designs mieć jeszcze większy sens, gdy jest dużo warstw funkcji biorących udział w jednej ankiecie. Dla mnie jest to powszechna praktyka: czy pytałbyś (ankiety ) twój przyjaciel ponownie i ponownie codziennie, czy ma informacje, których potrzebujesz, czy po prostu powiedz mu, że interrupt mnie, gdy masz informacje, których potrzebuję. Myślę, że postępujemy właściwie w codziennym życiu, ale nie zdajemy sobie sprawy.

Ale interrupt based architectures po wdrożeniu wymagają solidnego zrozumienia publish-subscribe design principle. I, gdy odbywa się w domenach aplikacji, wymagają części kodu wysyłanie przerwań, aby były naprawdę dobrze napisane. To dobrze, ponieważ ściska złożoność w jednym miejscu, jak również.

Oprócz powyższego, poniżej znajdują się inne zalety, które architektura oparta na ankietach zapewnia bezpłatnie:

• Asynchrounous
• pasuje dobrze w przypadku rzadkich zdarzeń / aktualizacji
• Aktualizuj tylko wtedy, gdy dostępne są scenariusze danych
• Lepsza obsługa i zarządzanie błędami
• lepsze wykorzystanie cykli procesora
• lepiej żywotność baterii mgmt
• utrzymuje słuchaczy z dala od złożoności pod spodem

Ilekroć projektujesz sw i masz ten wybór, zawsze powinieneś wybrać projekt oparty na interrupt zamiast projektu opartego na polling, ponieważ projekt oparty na interrupt może wypełnić dla sytuacji opartej na polling przy użyciu słuchaczy, ale projekt oparty na sondażach nigdy nie spełni wymogu wymagającego projektu opartego na interrupt.

Poniżej znajduje się krótka macierz porównawcza:

                     -INTERRUPT-      -LOOP-
Speed                  fast            slow
Eficiency              good            poor
CPU waste              low             high
multitasking           yes             no
complexity             high            low
debugging              +/- easy        easy
critical in time       excellent       poor
code bloat             low impact      high impact