Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

ATmega tryb CTC (sprzetowe generowanie sygnalu na OC2)

adamusx 06 Maj 2006 23:33 5098 13
  • #1 06 Maj 2006 23:33
    adamusx
    Poziom 27  

    Witam

    Czy ktos symulowall tryb CTC w AVRstudio? Chodzi mi o to ze w przypadku nastapienia porownania i wygenerowania sygnalu na koncowce OC2 w AVRstudio podlgladajac port PB3 ( ktory odpowiada koncowce OC2) nie zmienia sie jego stan

    Oto fragment kodu:


    Code:

    #define _0_0125ms ( ( 0.0125 * ( xtal / 8000 ) ) - 1 ) //polowa okresu 40kHz


    int main(void)
    {
    DDRB|=(1<<3);                                   // ustawienie portu PB3 (OC2) jako wyjscie
    TCCR2|=(1<<CS21)|(1<<WGM21)|(1<<COM20); //preskaler 8 ; wlaczony tryb CTC; zmiana stanu OC2 na przeciwny gdy nastapi porownanie
    OCR2=0_0125ms;                        // zaladowanie rejestru porownania

    while (1)
    {}

    }

    W przypadku porownania PORTB 3 powinien sie zmienic na przeciwny, wiec w symulacji AVRstudio takze powinno byc to sygnalizowane w podlgadzie rejestru PORTB, a jednak jest on cały czas zgaszony... Wie ktos dlaczego ?



    [/code]

    0 13
  • #2 06 Maj 2006 23:58
    maly35
    Poziom 13  

    Może problem leży w tym co wpisujesz do OCR2. Powinna być wartość od 0..255 (to określa wypełnienie sygnału). Jaką masz częsotliwość zegara?

    Na jaki procek piszesz? Bo np. na Atmega16 na PB3 masz OC0 więc u ciebie nie ten port ustawiasz

    0
  • #3 07 Maj 2006 00:06
    adamusx
    Poziom 27  

    Kwarc 16Mhz, program pisze na Atmega 8 wiec na pewno OC2 odpowiada pinowi PB3.
    A wartosc _0_0125ms wynosi 24, wiec nie przerkacza rozmiaru licznika.
    Jakies inne sugestie ? :)

    0
  • #4 07 Maj 2006 00:08
    szymtro
    Poziom 30  

    A sprawdzałeś czy w rzeczywistosci działa? Mi jak tylko wybiorę tryb ze sterowaniem automatycznym to odrazu tracę kontrolę nad pinem. Dokumentacja twierdzi że wewnętrzne sterowanie jest typu set/reset a u mnie nie da się zmieniać stanu portu - nawet jak zatrzymuje tajmer to i tak nie działa. Poradziłem sobie z tym wykorzystujac przerwanie od porównania.
    Problem juz kiedys był na forum ale wtedy też nie padły żadne konkretne wyjaśnienia.

    0
  • #5 07 Maj 2006 00:39
    Nawigator
    Poziom 33  

    AVR Studio może mylnie pokazywać zachowanie tego pinu. Gdzieś to chyba czytałem w helpie.
    Lepiej podłącz oscyloskop lub leda i zmniejsz częstotliwosć aby cośkolwiek zobaczyć.
    Pozdr. N.

    0
  • #6 07 Maj 2006 00:52
    zumek
    Poziom 39  

    Twój program - po poprawkach - działa :)

    Code:

    #include <avr/io.h>
    #define F_CPU 16000000UL
    #define _0_0125ms ( ( 0.0125 * ( F_CPU / 8000UL ) ) - 1 ) //polowa okresu 40kHz


    int main(void)
    {
    DDRB|=(1<<3);                                   // ustawienie portu PB3 (OC2) jako wyjscie
    TCCR2|=(1<<CS21)|(1<<WGM21)|(1<<COM20); //preskaler 8 ; wlaczony tryb CTC; zmiana stanu OC2 na przeciwny gdy nastapi porownanie
    OCR2=_0_0125ms;                        // zaladowanie rejestru porownania

    while (1)
    {}

    }


    szymtro
    Nie dość dokładnie czytałeś dokumentację :( Aby odzyskać panowanie nad pinem OCx , nie wystarczy zatrzymać timer (nawet nie jest to konieczne) wystarczy wyzerować bit w TCCRx , który odpowiada za podłączenie/odłączenie pinu od przerzutnika timera.
    Dla powyższego przykładu TCCR2&=(1<<COM20); //przywracamy PB3 do "normalności")

    Piotrek
    PS
    Zmiana preskalera na 1 , poprawi dokładność generowanej częstotliwości.
    #define _0_0125ms F_CPU / 80000UL - 1

    0
  • #7 07 Maj 2006 01:09
    szymtro
    Poziom 30  

    ale to nie chodzi o całkowite odłaczenie
    Jak ustawimy ze po porównaniu ma wyzerować port to juz wtedy nie mozna ustawić go w stan wysoki - tak jakby cały czas był zerowany co jest sprzeczne z dokumentacją. Dzieje sietak pomimo zatrzymania tajmera.
    Dla mnie sformułowanie: 'clear port on compare match" jest jednoznaczne: wyczyść port jezlei wartości "spasują" i to powinno wystapić tylko raz.
    I co ty na to?

    0
  • #8 07 Maj 2006 01:41
    zumek
    Poziom 39  

    szymtro napisał:
    ale to nie chodzi o całkowite odłaczenie
    Jak ustawimy ze po porównaniu ma wyzerować port to juz wtedy nie mozna ustawić go w stan wysoki - tak jakby cały czas był zerowany co jest sprzeczne z dokumentacją. Dzieje sietak pomimo zatrzymania tajmera.
    Dla mnie sformułowanie: 'clear port on compare match" jest jednoznaczne: wyczyść port jezlei wartości "spasują" i to powinno wystapić tylko raz.
    I co ty na to?

    Nie bardzo rozumiem o co Ci chodzi.Jeśli timer zrównał się z OCR-em , to przerzutnik ustawia się w taki stan, w jaki zażyczył sobie programista- koniec.Żeby zmienić stan tego przerzutnika , to musi nastąpić ponowne zrównanie wiadomych rejestrów , ze zmienionym "życzeniem" programisty ;) Ciekawe co by się stało , jeśli pin OCx ustawiony był na wyjście ze stane wysokim , a OCR wymusił by na nim 0:?: Dym pewnie by się pojawił , a może i ogień ;)
    Jeśli chcesz programowo zmieniać stan pinu OCx , to musisz go odłączyć od timera.Niektóre z AVR-ów(nie pamiętam które) pozwalają programowo "zresetować" przerzutnik OCR-a , ale tylko "zresetować" , bo programowo nie da się zmieniać dowolnie jego stanu , a jedynie sprzętowo przy porównaniu.Podobnie jest z pinami AC/DC albo są wejściem przetwornika , albo pinem portu inaczej powstał by wielgachny galimatias ;)

    Piotrek

    0
  • #9 07 Maj 2006 02:11
    szymtro
    Poziom 30  

    OK spokojnie.

    Żywym tekstem w dokumentacji nie ma nigdzie napisane że załaczenie opcji oc rozłacza całkowicie sterowanie z rejestru port. Nie jest o tym wspomniane ani przy opisie wyboru trybu oc ani w opisie samej końcówki.
    Dopiero jak zacząłem przeglądać obrazki ze schematami portu to mozna wywnioskowac ze stan >0 dla trybu oc odłacza sterowanie z rejestru port.
    Dla mnie jak cos jest napisane że jest set to naturalnie że mozna tamu zrobic reset.
    Dochodze do wniosku ze projektanci atmela nioe potrafia sie zrozumiale wysławiać. Na podobny bład natrafiłem aplikujac TWI w trybie slave do układu.
    Tak czy tak dzięki za indformacje - przydadzą sie napewno i innym.

    0
  • #10 07 Maj 2006 02:20
    zumek
    Poziom 39  

    Ja dodam tylko , że nie znalazłem w dokumentacji cytatu "clear port on compare match" , a "clear OCx on compare match".Tyle , że ten OCx to nie alternatywna nazwa pinu ,a właśnie ów nieszczęsny przerzutnik.

    Pozdrawiam
    Piotrek

    0
  • #11 07 Maj 2006 12:01
    adamusx
    Poziom 27  

    Witam

    Narazie chodzi mi o fakt ze w symulacji Avrstudio przy zmianie OC2 nie widac zmian portu PORTB3 .

    Code:

    OCR2=_0_0125ms;


    Tu rowniez mialem dobrze w programie wpisane _0_0125ms; , tylko przy pisaniu posta zrobilem blad. Czyli w "realu" OC2 sie zmienia tak ? Czyli tylko w AVRStudio jest problem z symulacja tego trybu..?

    Stan OC2 mozna wymusic tez recznie przez wpisanie 1 do bitu FOC2 rejestru TCCR2. Teoretycznie powinien zmienic sie takze stan koncowki PB3 jesli jest podlaczony do OC2 . W AVRstudio nic sie nie zmienia.

    0
  • #12 07 Maj 2006 12:32
    zumek
    Poziom 39  

    adamusx napisał:
    Witam
    ...
    Stan OC2 mozna wymusic tez recznie przez wpisanie 1 do bitu FOC2 rejestru TCCR2. Teoretycznie powinien zmienic sie takze stan koncowki PB3 jesli jest podlaczony do OC2 . W AVRstudio nic sie nie zmienia.

    Hmmmm... u mnie się zmienia ;)
    Jedyne co mi przychodzi na myśl to , czy aby symulator napewno "symuluje" proca , na którego skompilowano kod :?:
    Jeśli chodzi o FOC - przybyło mi wiedzy ;)

    Piotrek

    0
  • #13 07 Maj 2006 12:45
    adamusx
    Poziom 27  

    Tak ,symulator na pewno jest ustawiony na wlasciwego proca (Atmega8)
    W sumie to generowanie sygnalu na OC2 to tylko czesc kodu . Sprubuje zasymulowac tylko czesc kody generujaca te impulsy.


    Zumek miałes racje, cos musialo mi sie zmienic w AvrStudio bo przestawilo mi sie na Atmege 16:) Bylem swiecie przekonany ze caly czas jest ATmega8.
    Teraz sie zmienia stan PINB3 wiec jest ok.

    0
  • #14 15 Mar 2012 13:03
    MichałS
    Poziom 11  

    Nie chcę rozpoczynać nowego tematu, a problem bardzo zbliżony

    szymtro napisał:

    Jak ustawimy ze po porównaniu ma wyzerować port to juz wtedy nie mozna ustawić go w stan wysoki - tak jakby cały czas był zerowany co jest sprzeczne z dokumentacją. Dzieje sietak pomimo zatrzymania tajmera.
    Dla mnie sformułowanie: 'clear port on compare match" jest jednoznaczne: wyczyść port jezlei wartości "spasują" i to powinno wystapić tylko raz.

    Potrzebuję odmierzyć czas. TIMER2, bo inne są już zajęte. Wpisuję czas do OCR2, startuję TIMER2, tryb non-PWM clear OC on compare. Upływa czas, OC2 zostaje wyzerowany i nie ma już jak go ustawić w stan wysoki. Potrzebuję co jakiś czas wygenerować impuls na OC i OC musi być ustawiany na początku impulsu.

    0
  Szukaj w 5mln produktów