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.

atmega8 timer2 w trybie CTC i zmiana czętotliwości

ele_marek 20 Sie 2016 17:50 1092 9
  • #1 20 Sie 2016 17:50
    ele_marek
    Poziom 6  

    Witam wszystkich,
    rzadko pisze bo zwykle jakoś sobie radzę, ale po trzech dniach walki jestem zdesperowany i zaczynam szukać pomocy u Was.
    Zrobiłem emulację odbierania RS232 na nóżce INT0.
    Zbocze opadające oznacza że mamy bit startu.
    Tak startuje odbieranie:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Timer uruchamiam gdy jest bit startu przez podłączenie taktowania.
    nie wiem czy to można zrobić lepiej, ale tak działa i to nie jest opisywany problem.
    Skoro już uruchomiłem timer 2 to jeszcze pokażę jak go skonfigurowałem:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Do kompletu kod wykonywany w przerwaniu t2:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Starałem się dobrze okomentować kod.
    A teraz mój problem.
    Wszystko pięknie działa i prawidłowo są odbierane dane zaraz po zaprogramowaniu uC.
    Jak odłączę zasilanie i ponownie włączę nic już dobrze nie działa.
    Analizatorem sprawdziłem, że timer2 działa z innymi częstotliwościami około 2x szybciej. Powinienem jeszcze dodać że taktowanie jest z wewnętrznego oscylatora który jest ustawiony na 2MHz.
    Wiem że na tym forum jest paru specjalistów dla których uC nie mają tajemnic.
    Czy mogę liczyć na jakąś podpowiedź. Co jest z tym timerem2 o czym jeszcze nie wiem i mam takie problemy?
    O jeszcze jedno.
    Szukając rozwiązania wstawiłem w przerwanie od T2 coś takiego:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Czyli przy każdym próbkowaniu bitu kontrolowałem OCR2 który jest kluczowy żeby T2 dobrze działał. Po zaprogramowaniu uC wartości zwracane były do przewidzenia czyli w HEX:
    2A 9A 2A 67 2A 67 ....
    Po odłączeniu zasilania już jakieś głupoty:
    A3 1B D5 AD 68 itd.
    Czy możliwe że uC ma coś z wewnętrznym zegarem?
    Dlaczego tak sądzę?
    Ponieważ jak w analizatorze ustawiłem BitRate na AUTO to nagle dane ponownie zaczęły wyglądać prawidłowo czyli 2A 9A 2A 67 2A 67 ... tyle że prędkość się zrobiła 16949bps. to 1,76 razy szybciej tak jak by zegar o tyle przyśpieszył.
    Czy to możliwe?
    Wiem że mogę podłączyć zewnętrzny kwarc ale to nie rozwiązuje sprawy bo projekt musi działać bez kwarca. Taką próbę też zrobię tyle że jest sobota, a ja nie mam Q=2MHz.
    Trochę się rozpisałem, ale chciałem dobrze zreferować problem.
    Może ktoś się przez to przebije i coś podpowie?

    0 9
  • Pomocny post
    #2 20 Sie 2016 18:44
    excray
    Poziom 39  

    Myślę, że masz 2 problemy. Po pierwsze używanie OR w liniach inicjujących rejestry mści się na Tobie. Po drugie brak ustawionego BOD.

    0
  • #3 20 Sie 2016 19:09
    ele_marek
    Poziom 6  

    Dzięki za odzew, a mogę prosić ciut jaśniej?
    Nigdy nie słyszałem że nie należy stosować OR ustawiając konfigurację w rejestrach, ale jestem samoukiem więc może nie miał mi kto tego powiedzieć, a w materiałach które czytałem się z tym nie spotkałem.
    Możesz odrobinę rozwinąć temat bo nie rozumiem jak kod po zaprogramowaniu działa prawidłowo a po zdjęciu zasilania już nie. O co chodzi z tymi ORem.
    Czy chodzi między innymi o te linie:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    O takie ORy chodzi?
    Czy to znaczy że mam każdy bit ustawiać z osobna?

    I głupio mi to pisać, ale nie wiem co to BOD?

    Napisz coś jeszcze proszę.

    0
  • Pomocny post
    #4 20 Sie 2016 19:14
    excray
    Poziom 39  

    Chodzi mi o takie ORy:
    TCCR2 |= (1<<FOC2) | (1<<WGM21);
    Dzięki niemu zagwarantowałeś, że różne śmieci które były w rejestrze pozostały tam. A wystarczy przy pierwszym użyciu zapisać TCCR2 = (1<<FOC2) | (1<<WGM21);
    BOD to Brown-Out Detector - układ zapewniający, że procesor zostanie prawidłowo zresetowany przy zbyt niskim napięciu zasilania. Ustawia się go fusebitami.

    0
  • #5 20 Sie 2016 19:55
    ele_marek
    Poziom 6  

    Tak teraz te ORy rozumiem, ale zawsze wiedziałem że uC jak startuje to w rejestrach konfiguracyjnych są wszędzie zera i ustawiamy tylko bity które chcemy żeby były ustawione na 1. To jak to jest z tymi rejestrami?
    Faktycznie jak zrobiłem korekty zgodnie z Twoją rada to uC zachowuje się inaczej ale jeszcze nie idealnie.
    Więc coś na rzeczy jest.
    Dopiero jak ustawiłem BODEN na 1 i BODLEVEL na 2V7 to wszystko zaczęło działać jak trzeba :)
    Bardzo Ci dziękuję, sam bym tego nie rozwiązał.

    0
  • #6 21 Sie 2016 11:09
    ele_marek
    Poziom 6  

    Problem wprawdzie wydaje się rozwiązany, ale jeszcze zauważyłem jeden mój błąd i chętnie się tymi spostrzeżeniami podzielę. Może to komuś kiedyś ułatwi rozwiązania swojego problemu.
    Gdy odłączałem uC od zasilania to linie TXD i RXD były nadal połączone z kompem. Wygląda na to że atmega8 pobierał sobie odrobinę energii z tych linii i nie do końca się resetował.
    Wprowadzone zmiany które dzięki pomocy excray zastosowałem wyeliminowały problem, ale badając gruntownie temat ustaliłem, że bez tych zmian jak wyłączę zasilanie i dodatkowo odłączę TXD i RXD to moje problemy nie występują.
    Oczywiście ten przypadek nauczył mnie co to jest BODEN i od teraz będę bardziej świadomie ustawiał fusbity.
    Gdyby ktoś jeszcze zechciał napisać coś na temat tych początkowych wartości w rejestrach to będę wdzięczny. Inni lamerzy zapewne też :)

    0
  • #7 21 Sie 2016 13:27
    2675900
    Użytkownik usunął konto  
  • #8 22 Sie 2016 08:23
    ele_marek
    Poziom 6  

    Ale to nie jest udokumentowana sposób zasilania?
    Czy faktycznie w praktycznych projektach można tą cechę wykorzystać?

    0
  • #9 22 Sie 2016 10:15
    2675900
    Użytkownik usunął konto  
  • #10 23 Sie 2016 08:24
    dondu
    Moderator Mikrokontrolery Projektowanie

    ele_marek napisał:
    Gdyby ktoś jeszcze zechciał napisać coś na temat tych początkowych wartości w rejestrach to będę wdzięczny.

    ... ale zawsze wiedziałem że uC jak startuje to w rejestrach konfiguracyjnych są wszędzie zera i ustawiamy tylko bity które chcemy żeby były ustawione na 1. To jak to jest z tymi rejestrami?


    Tak oczywiście można postępować, ale jeśli zmieniasz w jednym rejestrze różne bity wielokrotnie w czasie działania programu, to należy na ich ustawianie i zerowanie należy zwracać szczególną uwagę. Dlatego też czasami warto jest użyć przypisania, a nie OR, AND czy XOR, by mieć 100% pewności jaki będzie stan wszystkich bitów w rejestrze.

    Wartości początkowe bitów (po resecie, czy włączeniu zasilania) dla każdego rejestru są podane w dokumentacji mikrokontrolera i opisane jako "Initial Value" i nie zawsze są zerami.


    ele_marek napisał:
    ... linie TXD i RXD były nadal połączone z kompem. Wygląda na to że atmega8 pobierał sobie odrobinę energii
    ...
    Ale to nie jest udokumentowana sposób zasilania?
    Czy faktycznie w praktycznych projektach można tą cechę wykorzystać?


    Czy zastanawiałeś się dlaczego tak się dzieje?
    Jeśli nie, to przeanalizuj schemat blokowy pinu:

    atmega8 timer2 w trybie CTC i zmiana czętotliwości

    To tzw. zasilanie pasożytnicze. Jeśli więc mikrokontroler zasilał się w ten sposób, to de facto po włączeniu głównego zasilania nie następowało resetowanie mikrokontrolera, a przez to niewłaściwe używanie OR i AND mogło prowadzić do błędnego działania programu.

    0