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

FT232RL - problem z transmisją UART-USB z ATmega8A, wysyłanie danych przerywane

jedmie 13 Gru 2015 00:26 1377 16
REKLAMA
  • #1 15235411
    jedmie
    Poziom 9  
    Posty: 8
    Cześć.
    Od jakiegoś czasu próbuję rozwiązać problem związany z komunikacją UART-USB przez port COM. Używam mikrokontrolera ATmega8A (wewnętrzny generator RC 8MHz), konwertera FT232RL i w tym momencie próbuję sprawić, aby stała się najprostsza możliwa rzecz, czyli wysłanie 2 literek na port. Mój projekt jest trochę bardziej skomplikowany, ale dopóki nie naprawię tego, nie mam co ruszać dalej. Zastanawiam się, czy aby na pewno moje połączenia są prawidłowe, albo czy w kodzie nie dzieje się jakaś głupota. Warto wspomnieć, że jakiś czas temu wszystko działało i poszedłem z projektem dalej, po czym (bez majstrowania w funkcjach zw. z UARTEM), nagle przestało działać i w formie takiej jak przedstawiam zacina się.

    Efektem użycia kodu, który wklejam jest to, że przez jakiś czas wysyłają się moje upragnione literki, po czym pojawia się '?' i transmisja pada, a program zaczyna wykonywać się w kółko od zera, dochodzi do momentu wysłania, i wraca znów do początku. Po odłączeniu i podłączeniu zasilania program robi to samo - po dojściu do momentu transmisji wraca do początku.

    Chciałbym zapytać, czy w tym (dość standardowym chyba) kodzie jest jakieś niedociągnięcie, ew. może zrobiłem coś źle ze schematem (Rx i Tx idą na krzyż do ATmegi), a wreszcie czy możliwe jest, że mój FT232RL się jakoś uszkodził? Wiem, że nie ma co zrzucać na sprzęt, więc ostatnią opcję raczej odrzucam. Może jakimś tropem będzie to, że jak dodaje opóźnienie w USART_Transmit, to jakby działało dłużej... Będę wdzięczny za każdą pomoc i sugestię.

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    FT232RL - problem z transmisją UART-USB z ATmega8A, wysyłanie danych przerywane
  • REKLAMA
  • Pomocny post
    #2 15235424
    tomekgl
    Poziom 16  
    Posty: 119
    Pomógł: 13
    Ocena: 57
    Włączyłeś przerwania, jednak nigdzie nie masz procedury obsługi dla RXCIE i TXCIE. Wywołanie przerwania powoduje skok programu pod adres zdefiniowany w tablicy wektorów przerwań, czyli w Twoim przypadku reset procka.

    Cytat:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Druga sprawa to błąd w tej funkcji. Ona nigdy się nie zakończy, gdyż brakuje inkrementacji wskaźnika s w pętli. Ale zakładam, że to błąd przy przeklejaniu, skoro piszesz, że u Ciebie działa i wysyła wszystkie 3 znaki poprawnie.
  • REKLAMA
  • #3 15235432
    jedmie
    Poziom 9  
    Posty: 8
    Przepraszam, nie zamieściłem fragmentu kodu. Mam je obsłużone na zasadzie pustego pola { }. Rozumiem to tak, że program skacze do obsługi przerwania, a że nic tam nie ma to za chwilę z powrotem jest w tej samej części kodu i w zasadzie nic się nie dzieje. Czy ma to sens? Już poprawiam kod w pierwotnym poście.

    edit: tak, to błąd przy wklejaniu..
  • REKLAMA
  • #4 15235445
    tomekgl
    Poziom 16  
    Posty: 119
    Pomógł: 13
    Ocena: 57
    Ma sens, ale po co dokładać sobie potencjalnych przyczyn problemów. Sprawdź w skompilowanym kodzie, czy nie znikły w ramach "optymalizacji", a najlepiej wyłącz na razie obsługę przerwań.
  • #5 15235457
    jedmie
    Poziom 9  
    Posty: 8
    Obsługa wyłączona, problem niestety nie zniknął.
    Czy może to być jakaś inna przyczyna? Zastanawiałem się czy może to być błąd w synchronizacji funkcji wysyłającej jeden znak w funkcji jej używającej odpowiedzialnej za całe słowo. Ale w sumie czekam na ustawienie UDRE, więc chyba to jest zabezpieczenie przed czymś takim.

    Wspomnę, że płytkę wytrawiałem na uczelni w sposób 'domowy', FT232RL mam w wersji SMD. Piszę to dlatego, że mimo dobrze połączonych ścieżek, cały czas obawiam się, czy mogłem coś spalić podczas lutowania i wewnątrz układu coś nie działa jak powinno.
  • Pomocny post
    #6 15235771
    tmf
    VIP Zasłużony dla elektroda
    Posty: 14318
    Pomógł: 2090
    Ocena: 2203
    Jednym z problemów jest to, że ATMega8 dla pewnej obsługi UART wymaga stabilnego taktowania, czego nie zapewnia generator wewnętrzny. Więc trzeba dodać kwarc, lub taktować z układu FT lub napisać funkcję kalibracji generatora.
  • REKLAMA
  • #7 15235904
    jedmie
    Poziom 9  
    Posty: 8
    Do jutra nie wmontuję niestety zewnętrznego kwarcu. A chciałbym jak najszybciej rozwiązać problem.
    Czy kalibracja generatora za pomocą USBasp jest możliwa? Na stronach Atmela znalazłem jakiś dokument, ale dotyczy on STK®500, AVRISP, AVRISP mkII, JTAGICE i JTAGICE mkII.
  • #8 15235912
    tmf
    VIP Zasłużony dla elektroda
    Posty: 14318
    Pomógł: 2090
    Ocena: 2203
    Nie, soft do USBasp nie realizuje tej funkcji. Najprościej to w FT232 ustaw zegar na jednym z pinów i podaj go na XTAL1 procesora, oraz przełącz fusebity na taktowanie z zewnętrznego źródła.
  • #9 15236602
    tomekgl
    Poziom 16  
    Posty: 119
    Pomógł: 13
    Ocena: 57
    Proponuję uprościć kod do minimum, i skupić się na zegarze. Można albo użyć zewn. sygnału, ale wymaga to tyle samo pracy co przylutowanie kwarcu na pająka, a jest o tyle ryzykowne, że jak nie coś nie zadziała, to nie przeprogramujesz już układu.
    Z jakiego napięcia zasilasz układ? Wewn. oscylator jest kalibrowany pod 5V, jeżeli masz mniej, to zamiast 8MHz możę być nawet coś w okolicy 7MHz przy 3V. Odczytaj bajt kalibracyjny programatorem, i spróbuj poprawić kalibrację.
    Program poniżej ustawia rejestr kalibracji na wartość odebranego bajtu, użyj terminala który umie wysyłać dowolne znaki i nie wysyła znaku nowej linii.
    W drugą stronę powinien wysyłać ciąg "AAAAAA...."
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Konieczna lektrura: datasheet, str. 30
  • Pomocny post
    #10 15236665
    BlueDraco
    Specjalista - Mikrokontrolery
    Posty: 6479
    Pomógł: 939
    Ocena: 421
    Czy masz komunikację przy zapętleniu samego FT232, bez ATmega?
    Czy wyłączyłeś synchronizację (handshake) w terminalu? (Ew. czy połączyłeś wejścia DSR i CTS FT232 do masy?)
  • #11 15237006
    jedmie
    Poziom 9  
    Posty: 8
    Układ zasilam właśnie przez ft232rl z USB komputera. Pokazuje stabilne 5V. Co robi linijka UBRRL=51 - ustawia jakiś niski baud rate? Używam HyperSerialPort - nie wysyłam znaku nowej linii.

    BlueDraco - kontrolę przepływu mam ustawioną na None, ale wszystkie nieużywane piny (czyli między innymi DSR i CTS) nie są z niczym połączone. Czy to może być przyczyna?
  • Pomocny post
    #12 15237096
    piotrva
    VIP Zasłużony dla elektroda
    Posty: 6409
    Pomógł: 625
    Ocena: 735
    Sprawdź sam FT232 - odłącz od niego wszystko, następnie zewrzyj piny RxD i TxD i podepnij do komputera - na terminalu powinieneś dostać to co wysyłasz.
  • #13 15237227
    tomekgl
    Poziom 16  
    Posty: 119
    Pomógł: 13
    Ocena: 57
    jedmie napisał:
    Układ zasilam właśnie przez ft232rl z USB komputera. Pokazuje stabilne 5V. Co robi linijka UBRRL=51 - ustawia jakiś niski baud rate? Używam HyperSerialPort - nie wysyłam znaku nowej linii.

    Ten niski baudrate to właśnie Twoje 9600. :)

    jedmie napisał:

    BlueDraco - kontrolę przepływu mam ustawioną na None, ale wszystkie nieużywane piny (czyli między innymi DSR i CTS) nie są z niczym połączone. Czy to może być przyczyna?

    Raczej nie, jeżeli nie masz poprowadzonych żadnych długich ścieżek spod tych pinów, to wewnętrzne pull-upy powinny wystarczyć w niezakłóconym środowisku.

    Czy udało Ci się określić czy procek się po prostu resetuje, czy działa stabilnie a problem to zakłócenia w transmisji? Dorzuć do kodu inny znak na starcie programu, żeby było można to rozróżnić. Od tego zależą dalsze kroki.
  • #14 15237230
    jedmie
    Poziom 9  
    Posty: 8
    @piotrva
    Tak - w tej sytuacji komunikacja działa. Zatem chyba wygrywa opcja ze złym taktowaniem. Nie chce przyblokować ATmegi, więc chyba jednak poczekam do jutra i wlutuję porządnie kwarc.

    Tutaj nowe pytanie. Mam na płytce kwarc 11,0592 połączony do nóżek Xtal + kondensatory 20 pF na obu. Niestety, gdy programowałem fusebity (wg. kalkulatora http://www.engbedded.com/fusecalc/ na 'High Freq' (lfuse:w:0xff:m -U hfuse:w:0xd9:m)), to kontakt z mikrokontrolerem zanikał. Co ciekawe, przy dotknięciu czymś metalowym nóżki kwarcu przy XTAL1, kontakt był. Dlatego zdecydowałem się na posługiwanie się póki co wewnętzrnym generatorem. Wszystko przepikałem, więc to chyba nie problem jakiegoś zimnego lutu.
    Ktoś zasugerował, abym odlutował kondensatory od XTAL1 i XTAL2, bo 'może' mam już włączone wewnętrzne kondensatory - jednak z tego co doczytałem to tylko zaprogramowanie bitu CKOPT (0) je włącza, a moje ustawienie tego nie robi.
  • #15 15237310
    tmf
    VIP Zasłużony dla elektroda
    Posty: 14318
    Pomógł: 2090
    Ocena: 2203
    Dla kwarcu na XTAL nie ma żadnych wewnętrznych kondensatorów, ktoś sobie to pomylił z kwarcem zegarkowym i timerem w trybie asynchronicznym. Być może kondensatory 20 pF dla kwarca 11 MHz są ciut za duże, daj 8-11 pF.
    Swoją drogą jeśli przestawiasz fusebity to jakie znaczenie ma czy je przestawiasz na kwarc zewnętrzny, czy na zewnętrzne taktowanie na XTAL1? To samo ryzyko. Poza tym jeśli myślisz co robisz, to ryzyka praktycznie nie ma.
  • #16 15243474
    jedmie
    Poziom 9  
    Posty: 8
    Nie wiem dlaczego, ale zmiana z HyperSerialPort na Advanced Serial Port Terminal 6 pomogła. Przestało zacinać, wysyła to, co chcę, odbiera również.

    Dziękuję bardzo wszystkim za odpowiedzi - mimo, że zaczęło działać na takim układzie i kodzie jaki mam, już jestem w trakcie stosowania się do Waszych rad - zewnętrzny kwarc, dobra obsługa przerwań... Jeszcze raz wielkie dzięki!
  • #17 15243633
    piotrva
    VIP Zasłużony dla elektroda
    Posty: 6409
    Pomógł: 625
    Ocena: 735
    Na przyszłość polecam RealTerm ;)

Podsumowanie tematu

✨ Użytkownik zmagał się z problemem komunikacji UART-USB przy użyciu mikrokontrolera ATmega8A i konwertera FT232RL. Po pewnym czasie działania, transmisja danych zaczęła się przerywać, a program resetował się. W odpowiedziach zasugerowano sprawdzenie obsługi przerwań, stabilności taktowania oraz użycie zewnętrznego kwarcu, ponieważ wewnętrzny generator RC nie zapewniał odpowiedniej stabilności. Po wyłączeniu przerwań problem nie zniknął, co skłoniło użytkownika do rozważenia błędów w połączeniach lub lutowaniu. Ostatecznie, zmiana terminala z HyperSerialPort na Advanced Serial Port Terminal 6 rozwiązała problem z transmisją, a użytkownik planuje wprowadzenie dalszych poprawek, w tym dodanie zewnętrznego kwarcu.
Wygenerowane przez model językowy.
REKLAMA