Jak zsynchronizować pętlę główną i przerwań w AVR?

Jak używać pętli głównej i tej z przerwania?
Z tego co doczytałem pętla główna chodzi równolegle do pętli przerwania ustawionego jako timer.
Jakie zależności zachodzą pomiędzy nimi tzn. czy da się jakoś przewidzieć ile pętli wykona pętla główna, a ile pętla przerwania, ustalić w którym dokładnie momencie przeskoczy z pętli głównej i z powrotem?
Czy nie lepiej zbudować cały program w pętli z przerwania, wtedy wydaje mi się to być bardziej uporządkowane. Wykorzystywanie kilku pętli np. jeszcze z innych timerów może powodować błędy? Niewielką wiedzę mam na ten temat w avr'ach i stąd prośba o rozjaśnienie tej kwestii.

Pętla główna to jest to co się wykonuje w procesorze poza wszystkimi innymi procedurami.
Nie ma czegoś takiego jak pętla przerwań, poprostu na czas wykonywania przerwania program jest zatrzymywany, a po zakończeniu wznawiany od tego samego miejsca.

No tak, ale jak zadeklarujemy np: Timer0 jako Timer, w znienawidzonym bascomie będzie to:
Config Timer0 = Timer , Prescale = 1024
On Ovf0 Petla2:
Enable Timer0
Enable Interrupts

Do
instrukcje
Loop

Petla2:
instrukcje
np: if przycisk1 = 1 then
cośtam
endif
Return

to Petla2 bedzie wykonywana cały czas więc można tam wrzucić cały wykonywalny program?

tomasz256 napisał:

to Petla2 bedzie wykonywana cały czas więc można tam wrzucić cały wykonywalny program?

Można, tylko "po co"?

hm... choćby dlatego, że jeżeli chcę wykorzystać timer i zliczanie np czasu, sprawdzanie stanu wejść co robię w Petla2 i jednocześnie np. wyświetlanie czasu, komunikacja po I2C, oraz jakieś zależności z Petla2 wykorzystywane w pętli Do .. Loop to wygodniej chyba jest to wrzucić w jedną pętlę.

Mam jeszcze pytanie jak przeskakiwać z Do ... Loop do Petla2. Są jakieś komendy, kolejność, czy te pętle wykonywane są jednocześnie w przypadku skonfigurowania jako Timer, a nie przerwanie, bo rozumiem, że Timer (Petla2) jest wykonywana cały czas, a przerwanie tylko gdy wystąpi określone zdarzenie.

elektryk napisał:

tomasz256 napisał:

to Petla2 bedzie wykonywana cały czas więc można tam wrzucić cały wykonywalny program?

Można, tylko "po co"?

A no czasem się przydaje, ale faktem jest, że dość rzadko.

Może to być przydatne, jeżeli procesor ma tryb pracy, w którym aktywne są przerwania, a nieaktywny jest rdzeń i pobiera wtedy mniej prądu. '51 od Atmela tak mają.
Np. cały program sterujący aparatem telefonicznym TSP-91 (budka telefoniczna, niebieski) jest zrobiony tak, że najpierw w głownej pętli jest inicjalizacja, potem uruchamiane są przerwania, a na koniec instrukcja STOP (a może HLT, nie pamiętam ,co tam w motorolce było). W przerwaniach była cała obsługa "otoczenia" procka.

Jeżeli nie trzeba oszczędzać prądu, to takie rozwiązanie tylko komplikuje program i dodatkowo spowalnia jego wykonywanie.

Zazwyczaj robi się tak, że w przerwaniach wykonuje się bardziej "krytyczne" fragmenty programu, gdzie bardzo ważne jest, w którym momenci się on wykona. Na przykład termometr, powiedzmy że mmamy jakiś wyimaginowany cyfrowy detektor temperatury z magistralą I2C, czyli synchroniczną. W głównej pętli mamy odczyt temperatury i przeliczanie wyniku. Nawet, jeżeli te dwie operacje zostaną przerwane przez przerwanie ( ), to nic się nie stanie. A w przerwaniu mamy sterowanie wyświetlaczami LED (multipleksowane) i gdyby ta operacja została przerwana, to wyświetlacz na chwilę się zatrzyma (będzie świeciła tylko jedna cyfra)

Można to jeszcze wykorzystać do prostego multitaskingu. W przerwaniu co jakiś czas będzie się wykonywał scheduler, czyli program zarządzający zadaniami. W zasadzie zrobienie takiego multitaskingu bez alokacji zasobów to banał na 5 minut, wystarczy tylko przydzieić miejsce na kilka osobnych stosów (każde zadanie musi mieć własny) i po wywołaniu przerwania zrzucić tam rejestry. Potem wybiera się zadanie, które ma być wykonane (np. po kolei w systemie "każdemu po równo" 1, 2, 3, 4...). Przestawić wskażnik stosu na stos danego zadania, pobrać ze stosu wszystkie rejestry i wykonać instrukcję RETI.

A co do przewidywania, w którym momencie wykona się przerwanie - jest to jak najbardziej możliwe, ale jest równoznaczne z symulacją danego programu, inaczej się nie da, bo przerwanie zawsze jest wywoływane dopiero, gdy zakończy się instrukcja wykonywana w momencie zgłoszenia przerwania, a różne instrukcje wykonują się w różnej ilości cykli.

Użycie na raz kilku przerwań nie będzie powodowało błędów, pod warunkiem, że program będzie napisany prawidłowo.

obsługa przerwania timera nie może też trwać zbyt długo żeby nie było "przerwania w przerwaniu" - kilka tyknięć zegarka i masz zawalony stos adresami powrotu (zwiecha)

starob napisał:

obsługa przerwania timera nie może też trwać zbyt długo żeby nie było "przerwania w przerwaniu" - kilka tyknięć zegarka i masz zawalony stos adresami powrotu (zwiecha)

Nie. Jeźeli przerwanie jest aktualnie wykonywane, to drugie takie samo przerwanie poczeka grzecznie aż zakończy się pierwsze. Jeżeli w tym czesie jeszcze wystąpi trzecie przerwanie to zostanie zignorowane.

Jeszcze nie widziałem, żeby gdzieś stosowano kolejkowanie przerwań (więcej niż jednego tego samego poziomu), a tym bardziej przerwanie, które przerywa samo siebie. Aktualne przerwanie może zostać przerwane tylko przez przerwanie o wyższym priorytecie, przerwania o takim samym i niższym priorytecie zaczekają

Ale faktycznie główny program się zawiesi, ale dla tego, że ciągle będą wykonywane przerwania jedno po drugim. Nie wiem, jak w innych architekturach, ale w '51 i MC68k Nawet w takiej sytuacji główny program będzie się wykonywał po każdym zakończeniu przerwania po jednej instrukcji (zresztą w '51 można to do debugowania wykorzystać)