Witam!

Próbuję wykorzystać Timer1 uC Atmega32 do pracy w dwóch zastosowaniach jednocześnie. Każde z osobna działa prawidłowo (obsługa IR) i multipleksowanie LED, ale łącznie już nie chcą, tzn. działa multipleksowanie, a obsługa IR nie. Czy te dwa tryby pracy mogą współdziałać?

1. Biblioteka IR_UNI:



2. Multipleksowanie wyświetlacz LED:



Pozdrawiam

No weź chwileczkę sam pomyśl .... no pomyśl .... jak to może działać, skoro licznik jest resetowany przez OCR

OCR1A = 2303;

i nigdy nie zlicza dalej

_________________
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 ]

Wpisuję wartość OCR1A odpowiednio do częstości, którą chcę uzyskać i timer liczy "non-stop" 0->CTC->0->CTC itd. Trochę się pogubiłem. Wszystko działało dobrze gdy do obsługi multipleksowania i timerów programowych używałem timera2 - OCR2 ustawione 1x:


Postanowiłem rozdzielić multipleksowanie od timerów programowych i przeniosłem je do Timera1. Multipleksowanie działa nadal, ale "utraciłem" podczerwień. Co robię źle?

Czy jest więc możliwe korzystanie z przerwania ICP Timera1 (IR_UNI) i jednoczesna jego praca w trybie CTC (multipleksowanie LED)? Jeżeli tak to podpowiedzcie proszę jak to zrobić.

W trybie przechwytywania licznik TCNT1 kręci się od zera do swej wartości maksymalnej czyli 65535. Po uzyskaniu tej wartości przekręca się i znów liczy w przedziale 0...65535.
Odpowiednie zbocze podane na pin ICP1 powoduje przepisanie wartości licznika TCNT1 do rejestru ICR. Skoro licznik liczy od 0 do 65535 to wartości z tego przedziału zostaną wpisane do ICR.

W trybie CTC licznik nie kręci się od 0 do 65535 tylko od 0 do wartości jaka jest wpisana do OCR1A (0...OCR1A). Już po tym widać, że skrócenie cyklu zliczania TCNT1 spowoduje błędny pomiar długości impulsów.

Dziękuję. Reasumując nie da się jednocześnie multipleksować wyświetlacza LED (CTC) i obsługiwać podczerwieni (ICP) z użyciem Timera1?

Wydaje mi się, że gdy licznik się przekręci, czyli zmieni wartość z 65535 na 0, zostanie ustawiona flaga przepełnienia. Jeśli odblokowane zostaną przerwania od przepełnienia (Overflow) to to przerwanie powinno się normalnie wywoływać (Timer1_OVF_vect). Wtedy multipleksowanie można by obsłużyć za pomocą tego przerwania.

Trzeba by obliczyć jaka będzie częstotliwość wywołań ww. przerwania. Ale obawiam się, że przy tak dużym dodatkowym podziale (65536), częstotliwość może być za mała do multipleksowania.

zrobiłem tak:



wg:


Multipleksowanie działa dobrze, ale... nadal bark podczerwieni - nie działa przerwanie ICP Timera1 (IR_UNI).

Przerwania od przepełnienia miały być tak przy okazji. Głównym zadaniem Timera1 ma być liczenie długości impulsów. A to oznacza, że nie możesz przypisywać żadnej wartości do TCNT1. Licznik ma wciąż liczyć od 0 do 65535. Nie możesz skracać jego cyklu bo pomiar długości impulsów przestanie działać poprawnie.

Przy taktowaniu 11059200Hz i preskalerze równym 8 przerwania od przepełnienia zgłaszane będą z częstotliwością ok. 21Hz (przerwanie co ok. 47ms). 21Hz to za mało do multipleksowania.

Pięknie dziękuję. Sprawdziłem na wyświetlaczu i rzeczywiście jest jak napisałeś. Bez wpisywania wartości do licznika przerwanie jest co ok 47ms. Działa także podczerwień. Do multipleksowania za mało niestety. Czy masz może pomysł jak to multipleksowanie rozwiązać? W programie działają także dwa timery 8-bitowe i może w nich drzemie potencjał?

TIMER0 - tryb fast PWM generuje sygnał PWM dla przetwornicy step-up (30-60V):


TIMER2 - tryb CTC jest podstawą dla timerów programowych:


Może widzisz możliwość wyciśnięcia z nich częstości "multipleksowej"?

Pozdrawiam

Przerwania od Timera2 wywołują się co 5ms. Jeśli masz nie więcej niż 4 wyświetlacze to wrzuć multipleksowanie do przerwania od tego timera. Na jeden wyświetlacz przypadnie 50Hz.

Kilka timerów programowych w przerwaniu nie zaszkodzi multipleksowaniu jak i multipleksowanie nie zaszkodzi timerom. Jedno i drugie powinno dobrze działać.

Dziękuję. Tak miałem zrobione dla 4 wyświetlaczy LED i wyglądało dobrze. Teraz jest 6 lamp VFD (IV-11) i wygląda źle. Doświadczalnie widzę, że potrzeba ok. 400Hz. Próbowałem zmniejszyć podstawę dla timerów programowych do 2.5ms i multipleksowanie ładnie wygląda, ale z niezrozumiałych dla mnie przyczyn przestaje działać czujnik wilgotności DHT22, który nie ma związku z timerami (tak mi się wydaje). Toleruje on częstotliwość do 200Hz i tyle - poźniej wyświetla 0. W bibliotece dla niego są liczne _delay_ms i _delay_us, ale wg mnie np. _delay_ms(100) znaczy zawsze to samo (chyba, że się mylę). Ostatecznie zaakceptuję multiplexowanie 400-600Hz bez czujnika DHT22, ale nie lubię niewiedzieć dlaczego nie działa.

Pozdrawiam

Witam.

Dopiero zaczynam zabawę z C więc z góry zastrzegam, że mogę się mylić. Ale z tego co czytałem, jeżeli używamy przerwań to funkcja _delay_ms() może nie być dokładna i w czasie opóźnienia należy uwzględnić obsługę przerwań. Dlatego przy konieczności utrzymania dokładnych zależności czasowych należy posłużyć się timerami.

Pozdrawiam.

Witam.
Problem wygląda tak. Program obsługuje w pętli while() wiele eventów od różnych urządzeń, w tym od czujnika wilgotności DHT22. Odczyt wilgotności jest prosty, a funkcja dedykowana temu zadaniu nie wymaga powoływania żadnych timerów. Zdziwiła mnie dlatego sytuacja, że gdy "podkręciłem" TIMER2 (8-bit) z 200 do 400Hz (multipleksowanie 6 lamp VFD) - czujnik przestał odczytywać wilgotność i temperaturę. Po zmniejszeniu częstości odczyty powracają natychmiast. Wywnioskowałem więc, że zmiana częstości TIMERA2 wpływa jakoś "ogólnie" na uC, program (?) i liczne _delay_ms i _delay_us, którymi najeżona jest biblioteka do obsługi tego czujnika, przestają "trzymać" czasy potrzebne do komunikacji. Innego wytłumaczenia nie widzę. Co do zastąpienia tych czasokresów timerami programowymi to nie wypali, gdyż rozjeżdżają się one bardzo na skutek przeładowania pętli głównej programu eventami (które nie blokują teoretycznie). Może ktoś z Kolegów pochyli się nad tematem i pomoże w rozwiązaniu zagadki.

Pozdrawiam

Masz wykorzystanych kilka procedur obsługi przerwań, jeszcze pytanie jak długo się one wszystkie wykonują. Bo może zaistnieć sytuacja że wykonywanie się przerwań na tyle zajmuje procesor że ten bardzo powoli wykonuje pętle główną stąd rozjechanie czasów przeliczanych przez _delay_ms i _delay_us. Może rozwiązaniem będzie wymiana kwarca na 16Mhz