Witam, od jakiegoś czasu używam timerów programowych zaproponowanych w BB i jak dotąd nie miałem większych problemów. Ale w tym przypadku brak mi pomysłu. Program uprościłem do minimum aby wyeliminować wszelkie możliwości błędu. Schemat jest ultra prosty: Atmega 2560 do pinu PB4 podłączona katodą dioda led. Poniżej lisitng programu:


Dopóki nHeartbeatTimer wewnatrz głównej pętli ustawiam na wartość poniżej 256 to jest wszystko OK, ale gdy wartość tą przekroczę to miganie diodą wykonuje się nie do końca regularnie. tzn. co któreś mignięcie jest krótsze.

Nie wiem w czym przyczyna. Proszę o pomoc.

Panie panie, przede wszystkim to spróbuj mi ale sobie też wyjaśnić dlaczego zastosowałeś TAKI typ w przerwaniu:



spróbuj wyjaśnić i się na głos sam zastanowić.

Po drugie ANI słowa nie napisałeś - ANI Z KOMENTARZY w kodzie to nie wynika (masakra) ... a sam wiesz, że w książce piszę o komentarzach i zobacz już tutaj jak by się przydały - szczególnie, że tobie nie chce się opisać tekstem tak istotnej dla sprawy rzeczy albo wręcz uważasz ją za mało ważną - więc nie napisałeś z jaką częstotliwością działają u ciebie timery programowe

Po trzecie po co piszesz takie rzeczy?


zamiast



? hmmm ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Panie Mirku, dziękuję za uwagi ale męczę się z tym problemem od kilku godzin i faktycznie program który zamieściłem jest już po kliku przeróbkach i testach. Ten typ unit32_t i rejestr OCR1A L i H to efekt tych testów. po zmianie spowrotem na uint16_t i na OCR1A = 43. Efekt pozostaje bez zmian.

------------------------ [ Dodano po: 4 minutach ]

Timer wywoływany co około 1ms. (kwarc 11,0592 MHz podzial 256).

No widzisz i do tego chciałem cię właśnie sprowokować i to podejrzewałem. A teraz przypomnij sobie co pisałem już w BB o podstawowej rozdzielczości czasowej dla timerów programowych ? Jak myślisz pisałem to ot tak sobie bez podstaw ?

Przypomnę więc - że w książce pisałem wyraźnie, że nie warto schodzić z rozdzielczością poniżej 100 Hz a zszedłeś do 1 kHz i się dziwisz ? Żeby schodzić niżej niż 100 Hz trzeba mieć na uwadze właśnie różne tego typu zjawiska jak np długość wykonywania się przerwania timera - wtedy wręcz jeśli zależy na czasie to trzeba wręcz nieraz sięgać po wstawki asemblerowe. Trzeba też w zasadzie w każdym wypadku zadbać o atomowość (o czym może akurat nie wspominałem w książce) no ale to bywa równie ważne czyli np jak przeładowujesz timer wartością już 16-bitową przy TAK krótkich czasach to zadbaj o atomowość



a najlepiej to jak mówię zastanów się czy w ogóle konieczny jest tak krótki czas 1 ms bo mi się wydaje, że to jest bez sensu w wielu wypadkach. Gdy potrzeba tak krótkich czasów to już się zaczyna korzystać z przerwań sprzętowych..

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Witam

Ot taki przerobiony na "atomowo":

...z armatą na komary, ale jak już trafi...

Pozdr.

kicajek dobrze - no bo warto jeszcze warunki IF() sprawdzać jak już przy 16-bitowych wartościach ....

oczywiście jak mówię można do tego podejść jeszcze na wiele innych sposobów ale ....

gdy się korzysta z rozdzielczości 10 ms to wtedy nawet tak prozaiczne sposoby odpadają bo zwykle wystarczają wartości 8-bitowe na takie timery

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dziękuję za odpowiedź. Niestety nawet przy zmniejszeniu czestotliwości 10x (OCR1A = 430) i zastosowaniu kodu który Pan zaproponował efekt jest nadal bez zmian. (tz wszystko wykonuje sie 10x wolniej ale nadal nie regularnie.)

Dopiero zastosowanie kodu zaproponowanego przez kolegę "kicajek" jest OK.

Najlepsze jest to że na innym procesorze (atmega 1284) Wszystko dziala bez stosowania technologii atomowej . Nie wiem w czym leży przyczyna.