Przerwanie Timera w ATmega

Witam,

Mam proste pytanko, na które jednak nie umiałem znaleźć odpowiedzi w specyfikacji (jest gruba więc mogłem przegapić - jak tak to proszę o namiary) Piszę program na ATmega128, w głównej pętli sprawdzam cyklicznie stan portów i w momencie zmiany zapisuje stan i czas do pamięci. Zliczanie czasu jest zrealizowane na 16bitowym Timerze1 z dzielnikiem 8 co na 16MHz zegarze daje zliczanie co 0,5 mikrosekundy. By móc zmierzyć kilka sekund dołożyłem dodatkowy rejestr inkrementowany w przerwaniu Timera1

Przepelnienietimera: in r20, SREG inc r22 out SREG, r20 reti

A pytanko jest takie: Czy może się zdarzyć tak, że najpierw przepełni się licznik Timer1, później w głównej pętli zostanie zapisany czas, a dopiero później zostanie obsłużone przerwanie? Inaczej mówiąc - czy mogą wystąpić jakieś przekłamania czy też skok do przerwania występuje dokładnie z przejściem Timera z max na bottom ? Doświadczalnie niczego takiego nie stwierdziłem ale wolałbym się upewnić.

I przy okazji drugie pytanko - opóźnienie czasu zapisania zdarzenia w głównej pętli o obsługę przerwania to: 3 takty na zawartość procedury przerwania, 4 takty na powrót z przerwania (reti) a ile taktów na skok do przerwania ? Inaczej - ile taktów zajmie cała przedstawiona procedura ?

Reply to
Jacek_FH
Loading thread data ...

Jacek_FH napisal:

Zalezy jak napisales procedure w petli glownej - moze sie zdazyc nastepujaca "nieszczesliwa" kombinacja - timer jest bliski przepelnienia, zachodzi zmiana na porcie - petla glowna zaczyna kopiowac czas zdaznia - kopiuje zawartosc timera, w tym momencie wchodzi przerywanie ktore inkrementuje twoj dodatkowy licznik, petla glowna kontynuuje - kopiuje zawartosc licznika. Czas wynikowy - pomylka "do przodu" prawie o jeden okres timera. Jesli zmienisz kolejnosc przepisywania czasu (najpierw licznik, potem timer) podobny scenariusz wyprodukuje ci pomylke "do tylu". Jest to wyjatkowo upierdliwy blad - wystepuje stosunkowo zadko i trudno go zasymulowac. Tak na goraco proponowlbym nastepujace rozwiazanie - kopiowac najpierw timer, potem licznik - nastepnie odczytac timer jeszcze raz i sprawdzic czy jego wartosc nie jest mniejsza niz przy pierwszym odczycie (co wskazuje na wystapienie przepelnienia pomiedzy odczytami) - jesli tak, inkrementowac kopie licznika. Przy okazji - nie napisales czy przerywanie od timera jest jedynym ktorego uzywasz, jesli nie - wejscie do jego obslugi moze sie opoznic o czas obslugi tego innego przerywania. GRG

Reply to
Gregor

Gregor snipped-for-privacy@wiecej.piwa.a.nie.spamuj.pl> napisał(a):

W takim przypadku , na czas odczytu zablokowałbym przerwanie od Timera.

Piotrek

Reply to
Piotrek Sz.

Wyraziłem się trochę niejasno w powyższym pytaniu. Sposób obsłużenia problemu o którym piszecie już mam (poniżej). Pytam się trochę o coś innego - czy na pewno nie zdarzy się sytuacja że najpierw przepełni się timer, później wykonam oba odczyty (licznika i timera), a dopiero na końcu wykona się procedura przerwania. Lub też odwrotnie - procedura przerwania wykona się gdy w timerze będzie najwyższa wartość, później będą moje odczyty a dopiero po nich przekręci się timer.

Taki sposób działania jest całkiem nielogiczny (co pewnie spowodowało niezrozumienie mojego pytania) ale chciałem się po prostu upewnić że avr czegoś takiego nie wyczynia.

A w odpowiedzi:

Dnia 2006-01-21, "Piotrek Sz." snipped-for-privacy@WYTNIJ.gazeta.pl> pisze:

Akurat takie rozwiązanie mogłoby spowodować podwójne inkrementowanie licznika. Trzeba by jeszcze raz odczytać licznik w przypadku różniących się timerów. Zamierzam zrobić to tak że licznik będę porównywał i przy różnych odczytach uznam wyższy i zapiszę do pamięci na pozycji timer - zero.

Jedyne.

Timer leci niezależnie od przerwań, tylko ten dodatkowy mój licznik zostanie wtedy zatrzymany. Więc może nastąpić przepełnienie bez inkrementowania licznika i wynik też do kitu. Musiałbym i zatrzymywać przerwania i zliczanie timera ale wtedy tracę "poczucie czasu" ;)

Reply to
Jacek_FH

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.