Mam dziwny problem ze znikającym jednym tickiem w liczniku gdy są włączone przerwania przy przepełnieniu. Licznik pracuje w trybie normalnym, taki sam efekt przy 8 i 16 bitowym, zaobserwowałem na atmedze 16 i 644P (bo takie miałem akurat pod ręka).
Normalnie bez przerwań, licznik przy przepełnieniu zeruje się i zaczyna liczyć od 0, wszystko tak jak można byłoby się spodziewać. Poniżej fragment kodu:
Po zatrzymaniu licznika, zawiera wartość 5. Wszystko ok.
Po włączeniu przerwań i dosyć prostym kodzie obsługi przerwania przepełnienia, zajmującej 12 cykli:
Ten sam kod, zachowa się nieco inaczej:
Na koniec, po zatrzymaniu licznika, jego wartość powinna wynosi tak jak wcześniej, powiększone o czas obsługi przerwania, czyli 17, a otrzymuję 16.
Wygada to tak, jakby w punkcie [1], po ustaleniu, ze wymagane jest wykonanie przerwania, TCNT jest zerowane. Zrobiłem test wyłączając licznik w przerwaniu i po odjęciu narzutu tego kodu, TCNT wskazywał 0. Mimo, iż teoretycznie powinien wskazać 1, bo przerwanie nastąpiło po wykonaniu tego 1-cyklowego NOP-a. Gdy zamienię go na coś innego, np. jakaś 4-cyklową instrukcję, to oczywiście przerwanie wykona się po jej zakończeniu, ale licznik nadal pokaże o 1 cykl mniej, czyli 3.
Przeszukałem siec i dokumentacje, ale nie mogłem nigdzie znaleźć żadnej wzmianki o tym zachowaniu. Być może jest to coś oczywistego i tak prostego, że aż nieprawdopodobnego, przez co to pomijam.
Może ktoś potrafi coś więcej na ten temat powiedzieć, albo miał podobny problem?
Uprzedzając pytania, po co, na co, do czego mi to, użyj innego um… itd. Chciałbym po prostu wiedzieć wtf , skąd wynika takie zachowanie. A potrzebne może to być w różnych dziwnych sytuacjach wymagających dokładnego reżimu czasowego, np., bramkowanie przy pomiarach, licznik cykli (AVR-Tick-Counter) etc.
Update:
Poprawiłem nieco formatowanie...
BTW, syntax mógłby wycinać CRLF jeśli występujące po nim, aby nie wprowadzać dodatkowej pustej linii w formatowanym kodzie, i standardowo alignować taba do 4 znaków...
Normalnie bez przerwań, licznik przy przepełnieniu zeruje się i zaczyna liczyć od 0, wszystko tak jak można byłoby się spodziewać. Poniżej fragment kodu:
Kod: AVR assembler
Po zatrzymaniu licznika, zawiera wartość 5. Wszystko ok.
Po włączeniu przerwań i dosyć prostym kodzie obsługi przerwania przepełnienia, zajmującej 12 cykli:
Kod: AVR assembler
Ten sam kod, zachowa się nieco inaczej:
Kod: AVR assembler
Na koniec, po zatrzymaniu licznika, jego wartość powinna wynosi tak jak wcześniej, powiększone o czas obsługi przerwania, czyli 17, a otrzymuję 16.
Wygada to tak, jakby w punkcie [1], po ustaleniu, ze wymagane jest wykonanie przerwania, TCNT jest zerowane. Zrobiłem test wyłączając licznik w przerwaniu i po odjęciu narzutu tego kodu, TCNT wskazywał 0. Mimo, iż teoretycznie powinien wskazać 1, bo przerwanie nastąpiło po wykonaniu tego 1-cyklowego NOP-a. Gdy zamienię go na coś innego, np. jakaś 4-cyklową instrukcję, to oczywiście przerwanie wykona się po jej zakończeniu, ale licznik nadal pokaże o 1 cykl mniej, czyli 3.
Przeszukałem siec i dokumentacje, ale nie mogłem nigdzie znaleźć żadnej wzmianki o tym zachowaniu. Być może jest to coś oczywistego i tak prostego, że aż nieprawdopodobnego, przez co to pomijam.
Może ktoś potrafi coś więcej na ten temat powiedzieć, albo miał podobny problem?
Uprzedzając pytania, po co, na co, do czego mi to, użyj innego um… itd. Chciałbym po prostu wiedzieć wtf , skąd wynika takie zachowanie. A potrzebne może to być w różnych dziwnych sytuacjach wymagających dokładnego reżimu czasowego, np., bramkowanie przy pomiarach, licznik cykli (AVR-Tick-Counter) etc.
Update:
Poprawiłem nieco formatowanie...
BTW, syntax mógłby wycinać CRLF jeśli występujące po nim, aby nie wprowadzać dodatkowej pustej linii w formatowanym kodzie, i standardowo alignować taba do 4 znaków...
