Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Przerwanie od UART zakłóca sterownie fazowe triaków

MES Mariusz 23 Jan 2013 13:34 2271 13
Computer Controls
  • #1
    MES Mariusz
    Level 36  
    Witam.

    Na obecnym etapie pewnego projektu wyrzuciłem instrukcję Input blokującą pętlę do czasu wprowadzenia klawisza ENTER. Teraz pobieranie znaków przychodzących na UART odbywa się z użyciem przerwania (przykładowy kod poniżej).

    Code: basic4gl
    Log in, to see the code


    Sposób wyśmienicie się sprawdził, z jednym tylko zastrzeżeniem. Z jakiegoś powodu zaburza on pracę sterowania fazowego (triaki załączane po odliczeniu nastawionego czasu opóźnienia). Przesłanie znaku powoduje mrygnięcie żarówki.

    Sterowanie fazowe odbywa się z wykorzystaniem Timera1 (TIMER1 (16 bit) - odliczanie 0,0001s odcinków czasu na potrzeby sterowania fazowego). Obsługa przerwania do Urxc najwyraźniej zaczęła zaburzać działanie Timera1. Niestety w helpie niczego takiego nie udało mi się przeczytać.

    Ktoś ma jakiś pomysł, dlaczego URXC może zaburzać działanie TIMER1 ?
  • Computer Controls
  • #2
    tadzik85
    Level 38  
    Bo masz strasznie długą obsługę tego przerwania?
  • #3
    BlueDraco
    MCUs specialist
    Parę uwag:

    Disable Urxc - zbędne, po co?

    If Kod_znaku <> 13 Then Enter = 0
    If Kod_znaku = 13 Then Enter = 1

    Po co dwa sprawdzenia? Bascom jest okrutnie wolny i bez tego.

    Ale tak naprawdę to chodzi o to:
    Waitms 20

    Co 3 dni piszę tutaj to samo zdanie:
    "żadnego oczekiwania w obsłudze przerwania!"

    Skoro specjalnie blokujesz przerwanie na 20 ms, to dlaczego się dziwisz, że przestaje Ci chodzić sterowanie triakiem?

    I dalej:
    Print
    Print "Enter=" ; Enter ; " Znak: " ; Tekst;
    Print
    Następne oczekiwanie w obsłudze przerwania!

    Timer zgłaszający przerwania z częstotliwością 10 KHz to już prawie zabójstwo dla ATmega, a pod Bascomem nawet bez "prawie".
  • Computer Controls
  • #4
    dondu
    Moderator on vacation ...
    BlueDraco wrote:
    Timer zgłaszający przerwania z częstotliwością 10 KHz to już prawie zabójstwo dla ATmega, ...

    Oj, coś przesadziłeś tym bardziej, że tutaj jest zegar 8MHz - o ile dobrze rozumie BASCOM.
    Co do reszty to "święta prawda" i faktycznie powtarzana co 3 dni :)

    @Mariusz
    Masz już tyle fajnych projektów na koncie, a takie podstawowe błędy robisz. Trochę wstyd :)
    I nie można tego wytłumaczyć pomyłką, bo to świadome działanie.
  • #5
    BlueDraco
    MCUs specialist
    800 instrukcji procesora to Bascom potrafi skonsumować na jakieś dwie linie kodu źródłowego :) - zwłaszcza przy operacji sumowania łańcuchów - podejrzewam, że szybkie to nie jest.

    W tym konkretnym przypadku można byłoby spróbować czytać znaki z UARTa w przerwaniu timera, bo wiadomo, że w jednym okresie timera nie ma szans na odebranie dwóch bajtów. Przynajmniej byłby gwarantowany czas odpowiedzi na przerwanie timera, a zapewne to jest główny problem.
  • #6
    MES Mariusz
    Level 36  
    Zatrzymanie obsługi przerwania na 20ms zatrzymuje wszystkie zadania procesora czy też Urxc wykorzystuje w jakiś sposób Timer1 ?
  • #7
    BlueDraco
    MCUs specialist
    Przy jednopoziomowym systemie przerwań, takim jak w AVR, podczas obsługi przerwania procesor nie zauważa innych przerwań. Można co prawda zrobić tak, żeby zauważał, ale dla początkującego programisty wyniknie z tego więcej kłopotu niż pożytku.
  • #8
    szulat
    Level 23  
    BlueDraco wrote:
    Przy jednopoziomowym systemie przerwań, takim jak w AVR, podczas obsługi przerwania procesor nie zauważa innych przerwań. Można co prawda zrobić tak, żeby zauważał, ale dla początkującego programisty wyniknie z tego więcej kłopotu niż pożytku.

    nieprawda uzasadniona nieprawdą a na końcu sprzeczność :P

    gdyby system był jednopoziomowy, bo na przykład zapamiętywanie stanu byłoby robione nie na stosie, tylko w jakichś wydzielonym obszarze jednorazowego użytku to nie mógłbyś tak po prostu "zrobić tak żeby zauważał". AVR ma różne ograniczenia ale akurat przerwania są wielopoziomowe bez ograniczeń na liczbę poziomów przerwania (pomijając ograniczenie pamięci).

    a jeżeli kogoś interesuje obsługa kolejnego przerwania bez kończenia poprzedniego to nie ma powodu mieszać do tego wyimaginowanych wad AVR tylko wystarczy wspomieć że globalny bit zezwolenia na przerwanie jest wyłączany przy wejściu do każdego przerwania i albo programista sobie go z powrotem włączy albo nie.
    ale podobnie jak ty, uważam że na początku przygody z procesorami lepiej nie włączać ;)
  • #9
    kamyczek
    Level 38  
    Przy tak pisanych programach nawet ARM się nie wyrobi . W przerwaniu powinieneś odebrać znak , wpisać go do ram i ustawić jakąś flagę żeby program gł. wiedział ze ma coś z tą zmienna zrobić w wolnym czasie . Już widywałem takie programy w których młodzian płakał ze my się zegar spóźnia kwarc ok, konfiguracja licznika ok , a zegar chodzi dwa razy wolniej . Procedura obsługi taka że w trakcie jednej zegar przepełniał się dwa razy ...
  • #10
    BlueDraco
    MCUs specialist
    Kolego Szulat, wydaje mi się, że Kolega nie rozumie pewnych pojęć podstawowych, które są dość dokładnie zdefiniowane. Jako stary informatyk, praktyk, lecz również teoretyk, podtrzymuję każde z pogrubionych przez Kolegę zdań. Oczywiście drugie z nich jest drobnym uproszczeniem - nie chciałem młodego adepta straszyć formalizmami. Chętnie wyjaśnię Koledze te podstawowe terminy w razie czego.
  • #11
    szulat
    Level 23  
    BlueDraco wrote:
    Chętnie wyjaśnię Koledze te podstawowe terminy w razie czego.

    chętnie posłucham dlaczego twierdzisz że AVR ma jednopoziomową obsługę przerwań a już w kolejnym zdaniu okazuje się ona wielopoziomowa i jednak da się obsłużyc przerwanie w przerwaniu. nawet jeżeli stosujesz jakieś niestandardową terminologię i "jednopoziomowy system przerwań" oznacza u ciebie coś czego nawet nie próbuję sie domyślać, to od sprzeczności logicznej nie uciekniesz - albo procesor coś obsługuje albo nie. a u ciebie nie obsługuje ale można to włączyć. przecież to jakiś żart :)
  • #12
    BlueDraco
    MCUs specialist
    Jednopoziomowy system przerwań - to taki, w którym procesor ma, jak sama nazwa wskazuje, dwa poziomy priorytetowe wykonywanego kodu :) (czasami nawet trzy, ale zostawmy ten niebezpieczny wątek - chodzi o przerwanie niemaskowalne). Oznacza to, że wszystkie przerwania są zgłaszane na tym samym poziomie priorytetowym, chociaż mogą się one różnić tzw. podpriorytetami. Przy przyjęciu przerwania procesor samoczynnie zmienia poziom priorytetowy na poziom przyjętego przerwania; w systemie jednopoziomowym nie ma tu pola do manewru - mamy dwa poziomy - "kodu zwykłego" (w ARM zwany poziomem "wątku") i przerwania. Jak jest na poziomie przerwania, to nie przyjmuje przerwań (bo więcej poziomów już nie ma, a przerwanie można przyjąć, gdy ma ono poziom wyższy od bieżącego poziomu procesora, Tyle ideologii i teorii, teraz przechodzimy do praktyki:

    Oczywiście programista może w procedurze obsługi przerwania w procesorze z systemem jednopoziomowym obniżyć priorytet i nawet czasami nie narobi w ten sposób dużych szkód; częściej jednak narobi. Zagrożeń jest wiele: podwójne przyjęcie przerwania z tego samego źródła, inwersja priorytetów itp. przyjemności. Dobra zasada: nigdy nie należy programowo zmieniać priorytetu. Oczywiście, jak to zwykle bywa, można podać przykład, gdzie taka zmiana nawet przyniesie jakiś pożytek, przynajmniej na krótką metę.

    Istotą systemu jednpoziomowego jest to, że nie da się w prosty sposób powiedzieć procesorowi "kiedy obslugujesz przerwanie 2, to nie przyjmuj przerwania 1, ale przyjmij przerwanie 3". I, jak to zwykle bywa - da się to osiągnąć, ale metodą "lewą ręką za prawe ucho", czyli przez indywidualne wyłączanie przerwań od poszczególnych urządzeń, co zwykle też się dobrze nie kończy (wyjaśnienie dlaczego pominę).

    Podpriorytet określa, które z równocześnie zgłoszonych przerwań o tym samym priorytecie zostanie obsłużone, ale jak już zaczniemy obsługę, to zgłoszenie innego o wyższym podpriorytecie i tym samym priorytecie pozostanie niezauważone, czyli: procesor będzie kontynuował obsługę przerwania mniej ważnego, zamiast zabrać się za to ważniejsze.

    Priorytet jest również zwany bardziej opisowo "priorytetem wywłaszczania", bo przerwanie o wyższym priorytecie przerywa procedurę przerwania o niższym priorytecie, czyli dokonuje wywłaszczenia.

    Jednopoziomowy system przerwań mają AVR i MSP430 (przynajmniej te starsze - nowszych nie oglądałem), ale również do całkiem niedawna miały go procesory x86, używane w PC. Wielopoziomowy system przerwań miały np. 51 i 68000, a obecnie mają go m.in. ARMy wszelkiej maści, od najmniejszych począwszy.

    Procesory z jednopoziomowym systemem przerwań na ogół nie nadają się do zastosowania w poważnych systemach nadążnych.

    W pewnym zakresie można wycisnąć z inteligentnego sterownika przerwań "wielopoziomowość" nawet przy jednopoziomowym procesorze, ale ma to spore ograniczenia i nie do wszystkiego się nadaje.

    Dodam jeszcze, że poziomów priorytetowych nie należy mylić z poziomami zaufania, bo to zupełnie inna bajka i inne bity w rejestrze stanu procesora.

    Wystarczy na początek?
  • #13
    szulat
    Level 23  
    BlueDraco wrote:
    Wystarczy na początek?

    dziękuję za ciekawy wykład :) prezentujący znaczenie terminu "wielopoziomowy system przerwań" jeszcze inne od wersji które znałem.

    w tym znaczeniu system przerwań w AVR (oprócz xmegi, której nikt nie używa) działa jak jednopoziomowy (chociaż tak naprawdę w ich terminologii nie ma czegoś takiego jak "poziom priorytetowy" :P) więc to co wcześniej napisałeś to najprawdziwsza prawda, ale mimo wszystko uzasadnianie że procesor "nie zauważa przerwania w przerwaniu" BO nie ma wielopoziomowych przerwań, jest w kontekście AVR anachronizmem i wypaczeniem, skoro przerwania w przerwaniu to żaden cud tylko możliwość opisana przez producenta i normalnie wykorzystywana. właściwym uzasadniem w tym konteście jest "BO przerwanie wyłaczyło flagę I a ty jej nie włączyłeś"!
    a że od strony programistycznej taka obsługa poziomów przerwań jest mniej oczywista i trudniejsza niż byłoby w bardziej zaawansowanych architekturach... to już inna sprawa.
  • #14
    BlueDraco
    MCUs specialist
    Oczywiście, że w AVR jest "poziom prorytetowy", przechowywany w bicie blokującym przerwania - to jest właśnie informacja dla procesora o tym, że jest "w przerwaniu".

    W każdym procesorze można programowo zmienić priorytet w przerwaniu. Robiło się to od zawsze w PC. Kiedy się zmieni priorytet procesora na priorytet wątku, to procesor już nie wie, że jest "w przerwaniu" i dlatego zauważa przerwania, więc - jak widzisz raczej panuję nad tym, co piszę, chociaż wcześniej chciałem napisać krótko. No, ale skoro zacząłeś drążyć wątek- to masz. :)

    Cały kłopot w tym, że programowe zmiany priorytetów generują mnóstwo sytuacji niebezpiecznych i niepożądanych. Praktycznie zawsze (oprócz najprostszych przypadków) można pokazać możliwy kłopot wynikający z takiego rozwiązania.