Robiłem proste sterowanie diodą RGB i wszystko wyszło tak jak chciałem. Kiedy jednak podłączyłem oscyloskop, żeby pooglądać przebiegi okazało się, że jeden z kanałów pracuje z dwa razy mniejszą częstotliwością niż pozostałe. Gdzie zrobiłem błąd w programie?

Kanały 8-bitowe pracują z częstotliwością 43,2 kHZ (czyli zgodnie z ustawieniami), a kanał 16-birtowy w trybie 8-bitowym ma częstotliwość 21,6 kHz.



A przy okazji: dlaczego taki zapis nie jest prawidłowy (kompilator pokazuje błąd)?


Oscylogram (na górze kanał OC0, na dole OC1A):

_________________
ATB 1.04, Bluebook wyd.II, Greenbook wyd.II

A pisałem w książce że jak się robi DEFINICE PREPROCESORA #define - to żeby nigdy na końcu średników nie dawać hmmm

Jeśli chodzi o pierwsze pytanie - bo widzę że z marszu wszędzie tak samo ustawiasz sobie bity preskalera CSxn a sprawdziłeś w nocie że niektóre timery mają różne wartości preskalerów ? zwykle timer0 różni się od timer2

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

No oczywiście, z tymi średnikami taki głupi błąd. Na dodatek wiedziałem, że nie dajemy ich przy tych definicjach .
Ale z preskalerem nie widzę błędu. Wg noty akurat ustawienia bitów są takie same. Chyba, że coś źle zrozumiałem z zapisu rejestrów.

Układ, to ATmega32 z kwarcem 11,0592 MHz.

_________________
ATB 1.04, Bluebook wyd.II, Greenbook wyd.II

no tak a sprawdziłeś pan w jakich rejestrach są bity?



bo ja jestem pewien że nie

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

Właśnie przed chwilą do tego doszedłem. A też już kiedyś była na forum o tym mowa.
Poprawnie ma być:

A gdyby nie oscyloskop, to nie wiedziałbym nawet, że zrobiłem błąd.

_________________
ATB 1.04, Bluebook wyd.II, Greenbook wyd.II

Była mowa o tym była i to nie raz ani nie dwa ... no ale cóż - w ten sposób się uczymy - na błędach

------------------------ [ Dodano po: kilkunastu sekundach ]

przy okazji wiesz jak to jest, jeśli ja to komuś na forum 10x powtórzę to jest większa szansa że sam nie zrobię tej pomyłki ... więc zyskujemy obydwaj

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

No więc wszyscy skorzystaliśmy .

W sumie błąd wyboru preskalera szybko odrzuciłem, bo różnica częstotliwości był dwukrotna, a preskaler musiałby dzielić ją przez osiem. Ta różnica częstotliwości naprowadziła mnie na to, że chyba jest włączony inny tryb PWM, no a dalej to już poszło.

_________________
ATB 1.04, Bluebook wyd.II, Greenbook wyd.II

Witam,

Ja mam pytanie dotyczące sposobu określenia częstotliwości sygnału PWM. Nie jestem pewny jak to policzyć prawidłowo. Używam procka Atmega16 z taktowaniem 16MHz. Chcę skonfigurować TIMER2 i wykorzystać go do zrobienia programowego pwm, np jednego kanału pwm1. Timer2 chcę skonfigurować aby generował przerwanie od porównania zawartości licznika z OC0. W sposobie stworzenia programowego pwm oraz procedury obsługi przerwania chcę się oprzeć dokładnie na przykładzie z niebieskiej książki, na podstawie rozdziału o pwm i diodzie rgb. Załóżmy, że określę w inicjalizacji Timera2 wartość OC0 = 200, preskaler Timera2 = 1. Timer2 jest 8 bitowy czyli licznik zlicza do 256.

To jak mam policzyć częstotliwość przebiegu pwm, tak?:

fr_pwm = 16000000/1/256/200

czy też tak

fr_pwm = 16000000/1/256

Głównie nie jest dla mnie do końca jasne czy trzeba dzielić również przez wartość OC0 = 200 w moim przypadku

------------------------ [ Dodano po: 7 minutach ]

Czy jeszcze może tak:

fr_pwm = 16000000/1/200

_________________
Mój Serwer AVR - http://msavr.besaba.com

W takim przypadku (tryb CTC) to preskaler i OC0 decyduje o częstotliwości pojawiania się przerwań, ale częstotliwość sygnału PWM generowanego programowo jest dużo mniejsza i zależy od licznika, który w tej procedurze przerwania jest zwiększany i porównywany ze zmienną która reguluje PWM. Jak ten licznik jest 8-bitowy i nie jest wcześniej zerowany tylko odlicza do maksimum i się przekręca to prawidłowy jest wzór 1 i nie ma nic wspólnego z tym, że timer jest 8-bitowy.

_________________
Dragonus Cracovus: Biomagia

Dziękuję za odpowiedź. Pomyślałem, że jeszcze pokażę kod żeby się upewnić co do obliczenia częstotliwości programowego pwm.
Poniżej przedstawiam plik silniki_pwm.c i silniki_pwm.h z inicjalizacją TIMERA2 oraz z procedurą przerwania licznika. W pliku main.c określam po prostu w pętli while(1), że np. pwm1 = 50; pwm2=100. Podłączyłem diody i wygląda na to, że wszystko działa. Potrzebuję jedynie jeszcze określić częstotliwość pwm

plik silniki_pwm.c



plik silniki_pwm.h



Licznik cnt zwiększany w przerwaniu jest 8 bitowy. Nie rozumiem za bardzo o jakie "wcześniejsze zerowanie" tego licznika chodzi. Czy w tym konkretnym przypadku (tutaj akurat wartość OCR2 = 125 a nie 200 jak w poprzednim poście) mogę policzyć częstotliwość w ten sposób?:

fr_pwm = 16000000/1/256/125

------------------------ [ Dodano po: 3 minutach ]

Przy okzaji czy orientujecie się jaka powinna być właśnie częstotliwość przebiegu pwm aby można było sterować silnikami układem L293D. Chcę do tego układu podłączyć dwa silniki DC i sterować prędkością z wykorzystaniem pwm. Pytanie tylko o częstotliwość. Czy jest tutaj istotna i jeżeli tak to jaka powinna być.

Z góry dziękuję

_________________
Mój Serwer AVR - http://msavr.besaba.com

Dziękuję za odpowiedź.
Ale czy jeżeli to jest programowy PWM to nie należy jeszcze tego co podałeś z noty podzielić przez 256? To 256 to wartość do której zlicza 8 bitowy licznik programowy w obsłudze przerwania - w kodzie oznaczony jako zmienna cnt w pliku silniki_pwm.c. Czy dopiero to nie da rzeczywistej częstotliwości sygnału pwm? Bo zastanawiam się czy to przeliczenie, które podałeś nie określa jedynie częstotliwości wykonywania samego przerwania od porównania zawartości licznika z wartością OCR2 = 125

Odpowiadając na Twoje pytanie. Oczywiście mógłbym użyć pwm - ów sprzętowych. Jednakże planuje wykorzystać je w projekcie do innych celów. Timer0 np już wykorzystuje do obsługi czujnika odległości i timerów programowych.

_________________
Mój Serwer AVR - http://msavr.besaba.com

step_m .... widzę że troszkę wciąż nie rozumiesz do końca jak się oblicza częstotliwość PWM'a programowego

Oczywiście, że w porównaniu do wzoru na sprzętowy PWM musimy jeszcze dodatkowo podzielić to przez 256 przy programowym PWM'ie ...

dlaczego ?

no pomyśl sobie ... wartość tego licznika to kolejny (tyle że programowy) PRESKALER o wartości 256. Skoro Timer zlicza do 256 to przecież DZIELI nam dokładnie przez tą wartość częstotliwość dostarczoną do niego poprzez ustawienie sprzętowego preskalera oraz wartości OCRx

ale to jeszcze nie częstotliwość naszego programowego PWM'a tylko częstotliwość z jaką timer TYKA sobie - zgodzisz się chyba ze mną. A my to TYKANIE jeszcze dzielimy przez 256 jego kroków w trakcie których obsługujemy przecież nasz programowy PWM ... dlatego jest to coś w rodzaju - jeszcze raz powtórzę "programowego preskalera"

teraz jaśniej ?

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

Tak tak. Już wszystko jasne. Wziąłem kartkę i rozrysowałem sobie generowanie tego przebiegu w oparciu o zliczanie licznika, przerwanie przy porównaniu i jaki stan i kiedy pojawia się na wyjściu pinów programowego pwm przy spełnieniu bądź nie spełnieniu warunku if w przerwaniu. Wszystko się wyjaśniło.

Jednakże zauważyłem jedną rzecz. Ustawiłem wartość OCR2 = 13 aby wygenerować częstotliwość pwm = ok. 5kHZ (dokładnie 4.8kHz). Bo 16000000/256/1/13 dokładnie tyle daje. Wówczas procek praktycznie przestaje działać. Dopiero kiedy zadam OCR2 = 60 co daje częstotliwość pwm = 1.04kHz wszystko zaczyna ładnie pracować. Czy zjawisko to może być spowodowane czasem wykonywania procedury przerwania, która może zajmować cały czas procesora i wówczas program główny nie jest wykonywany?
Podobne wyjaśnienia spotkałem w niebieskiej książce w rozdziale dotyczącym pwm i diody rgb.

_________________
Mój Serwer AVR - http://msavr.besaba.com

Staram się to zrozumieć. Czy to oznacza, że jeżeli procedura przerwania zajmuje powiedzmy co najmniej 6 taktów procesora i wywoływana jest co 14 taktów, to znaczy, że procesor w funkcji main() czy pętli while "zdąży" wówczas wykonać 14-6=8 instrukcji? (Zakładając oczywiście, że każda instrukcja zajmuje jeden takt procesora). I jeżeli w programie głównym jest do wykonania więcej niż 8 instrukcji, to w tej sytuacji procesor po prostu ich nie wykona?
Sorki za może bezsensowne pytania ale jeżeli takie są to wynikają z mojej niewiedzy i jednocześnie chęci ogarnięcia problemu:-)

_________________
Mój Serwer AVR - http://msavr.besaba.com

Czy w takim zbyt częste wykonywanie przerwania lub zbyt długi czas wykonywania procedury jego obsługi może być powodem problemów o których pisałem we wcześniejszych postach?

_________________
Mój Serwer AVR - http://msavr.besaba.com

to jest tak .... jeśli czas trwania przerwania to np 450 cyki zegara ... natomiast przerwanie wywoływane jest co 400 cykli zegara to co się dzieje ? To się dzieje MASAKRA - oczywiście program główny będzie wykonywany ALE ...

ale uwaga! w jaki sposób ?

Otóż ZAWSZE po zakończeniu przerwania po tych 450 cyklach nastąpi powrót z przerwania i skok do programu głównego - wykonanie JEDNEJ !!!! instrukcji asm (a nie linii programu w C), i BACh! znowu skok do przerwania! .. i tak w kółko

więc możesz już sobie wyobrazić co się będzie działo przerwanie będzie "ładnie" śmigać, ale program główny będzie wolniejszy niż najwolniejszy ŚLIMAK na świecie -

można powiedzieć, że zajętość procesora będzie = 99,999999%

----------------------

dla porównania jeśli przerwanie będzie się wykonywało np 200 cykli a wywoływane będzie co 400 cykli to zajętość procesora będzie ok 50% czyli raczej w miarę spokojnie - choć to zależy co tam się będzie miało dziać i jak będą działać inne przerwania


jeśli przerwanie będzie się wykonywało np 40 cykli a wywoływane będzie co 400 cykli to zajętość procesora będzie ok 10%

rozumiesz ?

Przy programowym PWM'ie nie można sobie pozwalać na zbyt wysokie częstotliwości taktowania timera bo wchodzisz tym samym w coraz większe obciążenie procesora

a weź pod uwagę, że jeszcze są inne przerwania, których czas wykonywania także się dolicza sumarycznie do tej zajętości

mam nadzieję, że teraz to już będzie jasne ... ale jeśli jeszcze nie to śmiało pytaj

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