ATNEL tech-forum

Re: Przerwanie a pętla główna

2015-12-02T13:31:09+01:00

Cześć...

To jest zastosowanie czegoś co się nazywa RAII (ang. Resource Acquisition Is Initialization). W C to będzie zasada nie odwoływania się do zasobu z którego (ktoś/gdzieś) korzysta lub odwoływania się w sposób atomowy bez naruszania elementów które zajmuje ktoś inny. Stąd stosowanie ATOMIC_BLOCK bo zasobem jest cały port a nie pojedynczy bit

Statystyki: Napisane przez florekSi — 2 gru 2015, o 13:31

Re: Przerwanie a pętla główna

2015-12-02T12:48:02+01:00

Rozwiązanie bez korzystania z ATOMIC_BLOCk jest też bardzo proste (choć nie zawsze się da tak zrobić ). Nie modyfikuj portu w przerwaniu, tylko ustawiaj w nim zmienną mówiącą, że masz to zrobić oraz ewentualnie z informacją jak. A całą operację zmiany dokonuj w pętli głównej.

--
Pozdrawiam,
Robert

Statystyki: Napisane przez rskup — 2 gru 2015, o 12:48

Re: Przerwanie a pętla główna

2015-12-02T11:38:27+01:00

Dziękuję Krauser!
Sprawdziłem i faktycznie z ATOMIC_BLOCK(ATOMIC_RESTORESTATE) działa, bez nie działa. Trochę mnie Krauser przeraziłeś, ja tu zadaję wydawało by się banalne pytanie a Ty mi wyskakujesz z jakimiś ATOMIC-ikami. W pierwszej chwili blady strach na mnie padł, ale chwila skupienia i wszystko nagle okazało się nie tylko zrozumiałe a wręcz logiczne. Kto by pomyślał, że to takie zdradliwe, na prawdę trzeba mieć oczy z każdej strony.
Dziękuję serdecznie.

Statystyki: Napisane przez Tom277 — 2 gru 2015, o 11:38

Re: Przerwanie a pętla główna

2015-12-02T01:19:53+01:00

Kod o którym mówimy w C wygląda następująco
[syntax=c]while(1)
{
PORTB ^= (1<PORTB ^= (1<}[/syntax]
co daje nam taki wynik po skompilowaniu:
[syntax=asm]6c:21 e0 ldir18, 0x01
6e:94 e0 ldir25, 0x04
70:88 b3 inr24, 0x18
72:82 27 eorr24, r18
74:88 bb out0x18, r24
76:88 b3 inr24, 0x18
78:89 27 eorr24, r25
7a:88 bb out0x18, r24
7c:f9 cf rjmp.-14 ; 0x70[/syntax]
w linii 70 pobieramy aktualną wartość portu do rejestru r24, wykonujemy operacje na rejestrze i dopiero w 74 zapisujemy wynik z rejestru do portu. Robimy ponownie to samo w 76 ..7a a następnie skaczemy (wracamy) do 70. I tak w kółko.
Gdy przerwanie wyzwoli się nam po pobraniu wartości z portu w 70 ale przed 74 oraz po 76 ale przed 7a, to wpiszemy do portu wartość już nie aktualną, bo przerwanie nam przecież ją zmieniło i powinna być inna.
Przerwanie przed 72, 74, 78, 7a powoduje problem a przerwanie przez 70, 76, 7c nie powoduje. Ale jak widać szansa na problem to 4/7, czyi ponad 57%

Jak damy delay, który ma do wykonania np. 993 instrukcji w swoim przebiegu, to szansa wystąpienia problemu to 4/1000, czyli 0,4% I już tego nie zauważamy. Choć problem jest nadal. Dlatego ten delay to maskowanie problemu i sposób na prezentację przyczyny problemu a nie jego rozwiązanie.
Oczywiście dla rozwiązania należy użyć operacji w ATOMIC_BLOCK.

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 5 minutach ]

Quote:

Oczywiście macie racje.

Ja się tu męczę a to już nie trzeba udowadniać

Statystyki: Napisane przez rskup — 2 gru 2015, o 01:19

Re: Przerwanie a pętla główna

2015-12-02T01:46:49+01:00

Ok, panowie.

Oczywiście macie racje. Nie dawało mi to spokoju, odkurzyłem zestaw ATB, sprawdziłem i przemyślałem jeszcze raz. Tłumaczenie Kolegi Krauser jest jak najbardziej ok i zjawisko to będzie występowało zawsze, jeśli w programie głównym i w przerwaniu będziemy się odwoływać do tych samych zasobów ( w tym konkretnym przypadku chodzi o PORTB ). Swoją drogą, to całe "C" jest zdradliwe , w .asm nawet mi by do głowy nie przyszło by popełnić tak kardynalny błąd.

Pozdrawiam serdecznie, QuadMan.

Statystyki: Napisane przez QuadMan — 2 gru 2015, o 01:15

Re: Przerwanie a pętla główna

2015-12-02T00:22:44+01:00

QuadMan napisał(a):

Kolega Tom277 napisał o czymś zupełnie odwrotnym, niż Wy usiłujecie Mu wytłumaczyć. Nie wyobrażam sobie, aby opisane przez Niego zjawisko w normalnych warunkach było w ogóle możliwe, dlatego dopytywałem się, jaki to procek, jak ma to wszystko podłączone, itd.

Pozdrawiam, QuadMan.

P.S. Podejrzewam jakiś problem sprzętowy - "to coś" dopięte do portu D powoduje resetowanie się procka, albo np. krótkotrwały spadek napięcia zasilania, itp... Nie wiem, nie znam się, nie pytać...

Jest dokładnie tak jak piszą koledzy. Nie wierzysz? Weź procka i sprawdź.
Najpierw bez wyłączania przerwań w pętli while a potem z wyłączeniem.

Sam się zdziwiłem bo myślałem, że nie będzie miało to wpływu.

rskup napisał(a):

Jak dałbyś jakiś delay-a w pętli głównej, to zmniejszyłbyś prawdopodobieństwo wystąpienia takiego efektu proporcjonalnie do proporcji czasu zajętego na delaya i potrzebnego na toggle.

Dokładnie. Wystarczy w pętli dać opóźnienie o wartości kilkadziesiąt us i już program zaczyna działać poprawnie.

Statystyki: Napisane przez jacekk232 — 2 gru 2015, o 00:22

Re: Przerwanie a pętla główna

2015-12-02T00:05:56+01:00

Panowie,

Tom277 napisał(a):

...Rzecz w tym, że to w przerwaniu timera dzieją się dziwne rzeczy. Nie wszystkie diody zapalają się, czasem zapala się jedna a za chwilę trzy pozostałe lub odwrotnie. Tego nie mogę zrozumieć. To, że w pętli głównej program się nie wyrabia bo przerwanie może wystąpić w "złym" momencie to jest dla mnie jasne, ale dlaczego program w przerwaniu tak fiksuje?

Kolega Tom277 napisał o czymś zupełnie odwrotnym, niż Wy usiłujecie Mu wytłumaczyć. Nie wyobrażam sobie, aby opisane przez Niego zjawisko w normalnych warunkach było w ogóle możliwe, dlatego dopytywałem się, jaki to procek, jak ma to wszystko podłączone, itd.

Pozdrawiam, QuadMan.

P.S. Podejrzewam jakiś problem sprzętowy - "to coś" dopięte do portu D powoduje resetowanie się procka, albo np. krótkotrwały spadek napięcia zasilania, itp... Nie wiem, nie znam się, nie pytać... .

Statystyki: Napisane przez QuadMan — 2 gru 2015, o 00:05

Re: Przerwanie a pętla główna

2015-12-01T21:23:20+01:00

Weź pod uwagę, że to co napisał Krauser, musi nastąpić z bardzo dużym prawdopodobieństwem, bo tylko to robisz w swojej pętli głównej. Więc te operacje operowania na porcie muszą być przerwane przez wygenerowane przerwanie.
Jak dałbyś jakiś delay-a w pętli głównej, to zmniejszyłbyś prawdopodobieństwo wystąpienia takiego efektu proporcjonalnie do proporcji czasu zajętego na delaya i potrzebnego na toggle.

Oczywiście dodanie delay-a nie spowoduje zniknięcia problemu a raczej stworzenia kodu w stylu Windows - działa dobrze ale co jakiś czas coś się wyłoży

--
Pozdrawiam,
Robert

Statystyki: Napisane przez rskup — 1 gru 2015, o 21:23

Re: Przerwanie a pętla główna

2015-12-01T20:53:09+01:00

Tom277 napisał(a):

Tego nie mogę zrozumieć.

Prostsze wytłumaczenie:
1. Procesor wykonuje instrukcje w pętli głównej. Zmiana stanu pinu LED_TEST wygląda tak:
a) odczyt zawartości portu B do rejestru Rx
b) wykonanie operacji Rx ^ 0b00000100
c) zapis liczby z rejestru Rx do portu B

2. W przerwaniu inne operacje na porcie B zmieniają jego wartość.

3. Jeśli przerwanie wystąpi we wskazanych miejscach i zmieni wartość portu B to jaka będzie wartość na końcu?
a) odczyt zawartości portu B do rejestru Rx
======= przerwanie i zmiana wartości portu B
b) wykonanie operacji Rx = Rx ^ 0b00000100
======= przerwanie i zmiana wartości portu B
c) zapis liczby z rejestru Rx do portu B

Odpowiedź:
Wynikająca z odczytanej i zmienionej przez Rx = Rx ^ 0b00000100. Zmiany wykonane w funkcji obsługi przerwania zostaną nadpisane w ostatnim kroku c

Statystyki: Napisane przez Krauser — 1 gru 2015, o 20:53

Re: Przerwanie a pętla główna

2015-12-01T19:30:34+01:00

A próbowałeś zrobić tak jak radzą koledzy? Sprawdziłem to i faktycznie umieszczenie kodu z pętli głównej w ATOMIC_BLOCK sprawia, że diody w przerwaniu zaczynają działać poprawnie.

Statystyki: Napisane przez jacekk232 — 1 gru 2015, o 19:30

Re: Przerwanie a pętla główna

2015-12-01T18:24:04+01:00

Witam,

a jaki to konkretnie procek? I co masz podłączone do tych wyjść LED_TES_TOG i WDI_TOG ? Najlepiej pokaż schemat, jak masz to wszystko podłączone.

Pozdrawiam, QuadMan.

Statystyki: Napisane przez QuadMan — 1 gru 2015, o 18:24

Re: Przerwanie a pętla główna

2015-12-01T06:42:55+01:00

Ale, mnie nie zastanawiają problemy z pętlą główną
[syntax=c]while(1)
{
WDI_TOG;
LED_TEST_TOG;
}[/syntax]
Rzecz w tym, że to w przerwaniu timera dzieją się dziwne rzeczy. Nie wszystkie diody zapalają się, czasem zapala się jedna a za chwilę trzy pozostałe lub odwrotnie. Tego nie mogę zrozumieć. To, że w pętli głównej program się nie wyrabia bo przerwanie może wystąpić w "złym" momencie to jest dla mnie jasne, ale dlaczego program w przerwaniu tak fiksuje?

Statystyki: Napisane przez Tom277 — 1 gru 2015, o 06:42

Re: Przerwanie a pętla główna

2015-11-30T21:57:47+01:00

Twój przykład jest zgodny z zapisem jak użyjesz parametr ATOMIC_FORCEON. Bo wtedy nie jest zapamiętywany stan SREG a przerwanie jest włączane automatycznie.
[syntax=c]ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
{
...
}[/syntax]
daje
[syntax=asm]inr24, 0x3f
cli
....
out0x3f, r24[/syntax]
a użycie
[syntax=c]ATOMIC_BLOCK(ATOMIC_FORCEON)
{
...
}[/syntax]
daje
[syntax=asm]cli
...
sei[/syntax]

Statystyki: Napisane przez rskup — 30 lis 2015, o 21:57

Re: Przerwanie a pętla główna

2015-11-30T21:38:52+01:00

krzysssztof napisał(a):

jest równoznacze z

oczywiście, że nie jest .... bo pomyśl co się stanie gdy któregoś razu wywołasz to wtedy gdy przerwania mają być wyłączone ? Wtedy się na siłę włączą

równoważne jest temu

[syntax=c]uint8_t sreg = SREG;
cli();
//... twoje operacje
SREG = sreg; // tutaj przywracamy SEI jeśli wcześniej było włączone[/syntax]

Statystyki: Napisane przez mirekk36 — 30 lis 2015, o 21:38

Re: Przerwanie a pętla główna

2015-11-30T21:37:37+01:00

Prawie, bo zależy od użytego parametru. W tym przykładzie nie będzie sei() tylko odtworzenie zapamiętanego przed cli(); rejestru SREG.
Polecam zaglądać do dokumentacji http://www.atmel.com/webdoc/AVRLibcReferenceManual/group__util__atomic.html lub do atomic.h - w eclipse wchodzi się przez klik z controlem.

--
Pozdrawiam,
Robert

Statystyki: Napisane przez rskup — 30 lis 2015, o 21:37

Re: Przerwanie a pętla główna

2015-11-30T21:22:35+01:00

Czy Atomic Block to jest tylko wyłączenie przerwań, czy spełnia jeszcze jakieś inne funkcje?

Bo zastawiam się, czy zapisanie
[syntax=c]ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
{
WDI_TOG;
LED_TEST_TOG;
}[/syntax]
jest równoznacze z
[syntax=c]{
cli();
WDI_TOG;
LED_TEST_TOG;
sei();
}[/syntax]
?

Statystyki: Napisane przez krzysssztof — 30 lis 2015, o 21:22

Re: Przerwanie a pętla główna

2015-11-30T21:01:32+01:00

Zmiana stanu na przeciwny z użyciem PORTx ^= (1<[syntax=c]#include

//...
ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
{
WDI_TOG;
LED_TEST_TOG;
}[/syntax]
Innym sposobem jest użycie rejestru PINx do funkcji toggle, ale dostępne jest to w nowszych mikokontrolerach np. atmega644PA. Wtedy zmiana stanu to tylko jedna instrukcja asemblera.

Statystyki: Napisane przez Krauser — 30 lis 2015, o 21:01

Przerwanie a pętla główna

2015-11-30T10:58:00+01:00

Czy może mi ktoś pomóc w wyjaśnieniu dlaczego tak się dzieję, że diody LED które powinny mrugać co 1 sekundę, a tego nie robią?
W poniższym programie (maksymalnie uproszczonym) diody led1,2,3,4 powinny zmieniać swój stan na przeciwny po doliczeniu licznika cnt_1ms do 1000.
[syntax=c]#include
#include

#define WDI (1<#define WDI_TOG PORTB ^= WDI//makro zmiany stanu watchdog-a

#define LED_TEST (1<#define LED_TEST_TOG PORTB ^= LED_TEST//makro zmiany stanu led-a

#define LED1 (1<#define LED1_TOG PORTB ^= LED1//makro zmiany stanu

#define LED2 (1<#define LED2_TOG PORTB ^= LED2//makro zmiany stanu

#define LED3 (1<#define LED3_TOG PORTB ^= LED3//makro zmiany stanu

#define LED4 (1<#define LED4_TOG PORTD ^= LED4//makro zmiany stanu

int main(void)
{
//inicjalizacja
DDRB |= WDI | LED1 | LED2 | LED3 | LED_TEST;//kierunek wyjciowy
PORTB &= ~(WDI | LED1 | LED2 | LED3 | LED_TEST);//stan niski

DDRD |= LED4;//kierunek wyjciowy
PORTD &= ~(LED4);//stan niski

//timer programowy tic/przerwanie co 1ms********config Timer2
TCCR2 |= (1<TCCR2 |= (1<TIMSK |= (1<OCR2 = 61;//Timer programowy

sei();

while(1)
{
WDI_TOG;
LED_TEST_TOG;
}
}

// przerwanie Timer2
ISR (TIMER2_COMP_vect)//przerwanie co 1ms
{
static uint16_t cnt_1ms;

cnt_1ms++;
if(cnt_1ms>999)
{
cnt_1ms = 0;
LED1_TOG;
LED2_TOG;
LED3_TOG;
LED4_TOG;
}
}[/syntax]
Rzecz w tym, że jak mam w pętli głównej te dwie linijki
[syntax=c]WDI_TOG;
LED_TEST_TOG;[/syntax]
Program źle działa. Jak je usunę to jest ok.
Wydawało mi się że nie ważne co jest w głównej pętli programu to, że jak już program wejdzie w przerwanie to póki go nie wykona w całości to w głównym programie nic się nie dzieje. Niestety diody led mrugają nieregularnie lub nawet niektóre wcale co jest dla mnie bardzo dziwne. Zrozumiałby gdyby było ta, że to w pętli głównej są problemy np. przerwanie za często lub za długo, ale dlaczego przerwanie źle działa?
Program jest banalny na razie to tylko początek dla sprawdzenia czy procesor jest dobrze przylutowany i czy ledy działają. W docelowym programie linijkę
[syntax=c]WDI_TOG;
LED_TEST_TOG;[/syntax]
umieszczę w warunku wykonywanym np co pół sekundy, ale na próbę zrobiłem tak jak wyżej i mocno zastanowiły mnie efekty. Poproszę o wyjaśnienie

Statystyki: Napisane przez Tom277 — 30 lis 2015, o 10:58