logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

ATmega32 UART 19200 16MHz avr-gcc – błędny odbiór danych mimo poprawnych rejestrów

mgradzki 23 Cze 2006 20:43 1396 10
REKLAMA
  • #1 2757700
    mgradzki
    Poziom 16  
    Posty: 295
    Pomógł: 7
    Ocena: 11
    Mam problem, który był już poruszany na tym forum, ale nie mogę go przeskoczyć. Próbuję odczytać z RS-a dane (program w avr-gcc).

    ATmega32 pracuje z kwarcem 16MHz

    Inicjując UARTa ustawiam:

    UBRRH = 0x00;
    UBRRL = 0x33;

    W datasheecie dla prędkości 19200 przy tym kwarcu jest 51 więc w hex jest 33



    UCSRB = 0b10010000;

    Uruchamiam przerwanie od RXC i włączam odbiornik


    UCSRC = 0b10000110;

    Najstarszy bit wskazuje na zapis do UCSRC
    Praca asynchroniczna
    Parzystość NONE
    Słowo 8 bitów
    1 bit stopu

    Procedura przerwania:

    SIGNAL (SIG_UART_RECV)
    {
    tmp = UDR;
    PORTB=tmp;
    }

    zmienna tmp zadeklarowana gdzie indziej

    Podaję z prawidłowo skonfigurowanego terminala (19200,8,N,1) dane i albo idą jakieś przypadkowe krzaki, albo w ogóle nic nie odbiera.

    Przypuszczam, że problem jest gdzieś w UBRRH, UBRRL, choć jest tak jak w tabeli w datasheecie (sam też to samo wyliczyłem).

    Czy ktoś wie o co chodzi ??

    Dodano po 37 [minuty]:

    Właśnie po kilku zmianach w programie. przez przypadek zauważyłem, że wszystko pięknie działa (nawet z echem z powrotem do terminala) jeśli w terminalu ustawi się 2 razy szzybszą transmisję niż w UART-cie procesora.

    Pewnie gdzieś plącze mi się jeszcze jakaś flaga.
  • REKLAMA
  • #2 2757892
    GienekS
    Poziom 32  
    Posty: 1971
    Pomógł: 139
    Ocena: 15
    A czym ustawiasz rejestr UCSRA = ?. W nim jest bit odpowiedzialny za podwojenie prędkości usarta.
  • #3 2757932
    mgradzki
    Poziom 16  
    Posty: 295
    Pomógł: 7
    Ocena: 11
    No właśnie nie ustawiam.
    Teraz zauważyłem, że dalej idą krzaki, a echo na terminalu jest wynikiem działania samego terminala, bo wchodzi nawet jak odłączę kabel od płytki.
    Czyli ciągle NIE DZIAŁA. :cry:
  • REKLAMA
  • #4 2761556
    wacek_
    Poziom 13  
    Posty: 35
    Pomógł: 4
    Ocena: 5
    Nie wiem jak to w ATmedze 32, ale w ATtiny jest coś takiego jak preskaler - dzielnik częstotliwości zegara przez 8. Ustawia się to za pomocą CKDIV8 Fuse. Pamiętam, że jak jescze nie wiedziałem, że coś takiego istnieje, też mi mieszało w prędkości UARTu. A właściwie w prędkości działania całego uC.

    Pozdrawiam!
  • REKLAMA
  • #5 2761701
    mgradzki
    Poziom 16  
    Posty: 295
    Pomógł: 7
    Ocena: 11
    Miże coś w tym jest.
    Douczę się jak to sprawdzić :) i się pobawię.
  • #6 2761737
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    mgradzki napisał:
    Miże coś w tym jest.
    Douczę się jak to sprawdzić :) i się pobawię.

    To może zacznij od sprawdzenia fusebitów. Jesteś pewien na 100% , że Twoja M32 "napędzana" jest zewnętrznym kwarcem :?:

    Piotrek
  • #7 2762243
    mgradzki
    Poziom 16  
    Posty: 295
    Pomógł: 7
    Ocena: 11
    zumek napisał:

    To może zacznij od sprawdzenia fusebitów. Jesteś pewien na 100% , że Twoja M32 "napędzana" jest zewnętrznym kwarcem :?:

    Piotrek



    Rezonator 16MHz
    CKSEL3=1
    CKSEL2=1
    CKSEL1=1

    Odczytane PonyProgiem
    Dokumentacja mówi, że jest to ustawienie dla Frequency Range 1.0<= (zakładam, że chodzi o 1 MHz i więcej) oraz 3-8 MHz. To dwie pozycje tabeli do które pasują do ustawienia CKSEL3..1.

    Wygląda na to, że jest OK.


    EDIT

    Faktycznie układ zachowuje się jakby pracował przy 1 MHz:?:.
    Jak ustawię transmisję na 38400 to działa przy ustawieniu w terminalu 2400.

    Pogrzebię jescze w dokumentacji do procesora i do zestawu uruchomieniowego, na którym to wszystko chodzi.
  • Pomocny post
    #8 2762526
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    mgradzki napisał:
    ...Wygląda na to, że jest OK.

    Tak wyglądają fusy w mojej M32 , pracującej na zewnętrznym kwarcu 11059200 Hz.Pony inaczej(odwrotnie) pokazuje stan bezpieczników niż np. ISPprog i na to należy zwrócić uwagę.

    Piotrek
    Załączniki:
    • ATmega32 UART 19200 16MHz avr-gcc – błędny odbiór danych mimo poprawnych rejestrów M32.GIF (17.07 KB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #9 2762623
    mgradzki
    Poziom 16  
    Posty: 295
    Pomógł: 7
    Ocena: 11
    Teraz rozumiem. Tak jak edytowałem w poprzednim poście - ustaliłem, że ta moja maszyna pracuje jednak na 1 MHz.
    Nie wpadłbym na pomysł, że PonyProg odwrotnie pokazuje. Odhaczyłem CKSEL3..1 i zaczęło działać jak należy.

    Jak kupowałem zestaw to rozmawiałem ze sprzedawcą i udało mu się wmówić mi, że "Procesor jest skonfigurowany do pracy z płytką ZL3AVR" - nie wiedziałem o co mu chodzi, ale widzę, że kłamał.

    Dzięki
  • REKLAMA
  • #10 2762764
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    mgradzki napisał:
    Odhaczyłem CKSEL3..1 i zaczęło działać jak należy.

    Aby pokazać Ci wskazania Ponyproga , musiałem specjalnie dla Ciebie , wlutować mostki do mojego dongla STK200 (a przymierzałem się do tego , od jakiegoś czasu :D ).Wracając do wskazań Pony'ego , to te dziwne ustawienia fusebitów , są opisane - wprawdzie na szaro- w okienku do ich odczytu i zapisu.

    Piotrek
  • #11 2763160
    mgradzki
    Poziom 16  
    Posty: 295
    Pomógł: 7
    Ocena: 11
    zumek napisał:
    Wracając do wskazań Pony'ego , to te dziwne ustawienia fusebitów , są opisane - wprawdzie na szaro- w okienku do ich odczytu i zapisu.
    Piotrek


    Faktycznie, teraz zauważyłem. Wygląda to jak jakaś niedostępna opcja i nie zadałem sobie trudu przeczytania.

    Grunt, że wszystko działa. Im więcej kłopotów tym szybciej się człowiek uczy.

    Pozdrawiam
    EOT

Podsumowanie tematu

✨ Problem dotyczył błędnego odbioru danych przez UART w mikrokontrolerze ATmega32 pracującym z kwarcem 16 MHz i ustawionym baud rate 19200 (UBRR=0x33). Pomimo poprawnej konfiguracji rejestrów UCSRB, UCSRC oraz przerwania RXC, odbierane dane były losowe lub brakowało ich całkowicie. Wskazano, że rejestr UCSRA, zawierający bit podwajający prędkość transmisji (U2X), nie był ustawiany, co mogło wpływać na komunikację. Kolejnym istotnym odkryciem było to, że fusebity mikrokontrolera nie były poprawnie skonfigurowane – układ faktycznie pracował z zegarem 1 MHz zamiast 16 MHz, co powodowało rozbieżności w prędkości UART. Po sprawdzeniu i poprawnym ustawieniu fusebitów CKSEL3..1 oraz potwierdzeniu pracy na zewnętrznym kwarcu 16 MHz, transmisja UART zaczęła działać prawidłowo. Wskazano również, że narzędzie PonyProg może wyświetlać fusebity w odwrotny sposób niż inne programatory, co może wprowadzać w błąd. Ostatecznie problem rozwiązała korekta fusebitów i potwierdzenie rzeczywistej częstotliwości pracy mikrokontrolera.
Wygenerowane przez model językowy.
REKLAMA