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

AVR - UART - dziwne wyniki w komunikacji z komputerem

Obywatel LutZek 17 Sty 2015 01:14 2445 21
REKLAMA
  • #1 14338442
    Obywatel LutZek
    Poziom 13  
    Witam

    Właśnie uczę się zestawiać połączenia uartowe. W celu testowania wykorzystuję program realterm oraz "legendarny" przewód USB/RS232 - Profilic PL2303.

    Transmisja 19200 8,N,1.

    O cóż się rozchodzi. Zacznę od programu typu "Echo".

    Wysyłając z terminalu wartości jako znaki ASCII otrzymuję inny wynik. Wysyłając plik tekstowy - program działa bez zarzutu.

    Przykład. Wysyłając w ASCII tekst: AAAA,
    otrzymuję PPPP;

    Wysyłając plik txt o treści:

    "AGH - 123 % * &123 // 2"
    ABCDEFGHIJKLMNOPQRSTUVWXYZ
    ABCDEFGHIJKLMNOPQRSTUVWXYZ
    ABCDEFGHIJKLMNOPQRSTUVWXYZ
    ABCDEFGHIJKLMNOPQRSTUVWXYZ

    otrzymuję:

    AVR - UART - dziwne wyniki w komunikacji z komputerem

    Literka w trzecim rzędzie jest pominięta z powodu nieoptymalnego kwarcu. Natomiast nie wiem czy początek transmisji zawsze jest taki "krzaczasty"?

    Napisałem szybko program, który ma wysyłać z mikrokontrolera znak char 'A'. Wynikiem jest znak "_". (To samo jest w przypadku zmiennej "unsigned char". Wysyłając zmienną uint8_t s=1, otrzymuję w terminalu wartość uint8=127. Wysyłając wartość uint8_t=10, otrzymuję 189 :/.

    Podejrzewam, że to coś z kodowaniem ASCII/unicode, natomiast nie umiem sobie tego usystematyzować. Docelowo muszę sterować modułem GSM i chciałbym widzieć na ekranie co się dzieje w środku.
  • REKLAMA
  • #2 14338459
    Piotr Piechota
    Poziom 22  
    Nie pokazałeś ani programu ani schematu/zdjęcia układu a wróżki o tej porze śpią. :D
    Moja wróżba: źle połączona masa, niedokładnie dobrana częstotliwość zegara.
  • #3 14338471
    Obywatel LutZek
    Poziom 13  
    Ach racja. Dorzucam oba kody :)


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



    Program wysyłający:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • REKLAMA
  • #4 14338479
    Piotr Piechota
    Poziom 22  
    Czy w echo nie przeszkadza załączenie przerwania od Transmit Complete i brak jego obsługi? Czy 8MHz to kwarc czy wewnętrzny RC?
  • Pomocny post
    #5 14338513
    kspro
    Poziom 27  
    Tego rodzaju błędy powstają w wyniku wykrycia z jakiegoś powodu fałszywego bitu startu i są typowe dla transmisji non-stop kiedy bit startu kolejnego znaku następuje zaraz po bicie stopu poprzedniego. Przy wysyłaniu non-stop znaku "A" (41H=04000001B) w strumieniu bitów takiej transmisji można znaleźć znak "P" (50H=01010000B) według poniższego schematu (dla łatwiejszej interpretacji znaków ASCII transmisję narysowano od prawej do lewej):
        4  1      4  1      4  1      4  1
      --------  --------  --------  --------
    01010000010101000001010100000101010000010
    --------  --------  --------  --------
      5  0      5  0      5  0      5  0
    

    Podobnie jest w przypadku nadawania znaków "A" (41H), "G" (47H), "H" (48H), " " (20H), "-" (2DH):
       2  D      2  0      4  8      4  7      4  1
     --------  --------  --------  --------  --------
    10010110101001000000101001000010100011101010000010
     --------    --------  --------  --------     ----
       2  D        8  1      2  1      1  D         2
    

    Widać wyraźnie dwa odebrane znaki i fragment trzeciego: GS (1DH), "!" (21H) i wyświetlany jako SOH (01H) kod 81H, po którym nie ma bitu stopu, więc wykrywany jest stan Break trwający przez dwa zera i zakończony jedynką. Następnie odbiornik wykrywa właściwy bit startu rozpoczynający znak "-" (2D) i dalej już odbiór przebiega normalnie. Nie sposób odgadnąć jak powstaje pierwszy odbierany znak "$" (24H), ale najprawdopodobniej w ten sam sposób pojedyncza jedynka kończy złożony z trzech zer stan Break.

    Wydaje mi się, że zbyt szybko rozpoczynasz transmisję zaraz po resecie i pin będący wyjściem Tx UART-a nie jest wystarczająco długo w stanie wysokim (Mark) przed wysłaniem pierwszego znaku, lub też jeszcze przed rozpoczęciem nadawania pierwszego znaku pojawia się na nim jakiś stan przejściowy, który odbiornik terminala przyjmuje za bit startu. Być może jest to kwestia jakichś zakłóceń, bo nie przypuszczam, żeby różnice częstotliwości zegarów były na tyle duże, żeby spowodować tego rodzaju błędy transmisji przy jednoczesnym poprawnym odbiorze kilkudziesięciu znaków z rzędu.
  • #6 14361960
    Obywatel LutZek
    Poziom 13  
    Bardzo dziękuję za odpowiedź. To dużo mi rozjaśnia w kwestii tego co dzieje się w układzie. Mikrokontroler mam umieszczony na "jakiejś" płytce uruchomieniowej, w każdym razie nie ma tam złącza DB9. Piny męskiego złącza DB9 podłączone są 20-cm przewodami z pinami na płytce. Przewód ma dodatkowe 50cm. tak wygląda połączenie. Niestety nie pomogło dorzucenie drugiego bitu stopu i kombinowanie z bitami parzystości. Nie pomogła również wymiana przewodu USB/RS232 (na ten sam model) oraz dorzucenie trzysekundowego delay'a przed pętlą w której wysyłany jest znak.
  • #7 14362049
    Konto nie istnieje
    Konto nie istnieje  
  • #8 14362072
    Obywatel LutZek
    Poziom 13  
    Nie używałem układu max232 ze względu na to, że konwerter (o ile czegoś zdrowo nie poprzestawiałem), toleruje poziomy logiczne TTL:

    AVR - UART - dziwne wyniki w komunikacji z komputerem
  • REKLAMA
  • Pomocny post
    #9 14362117
    Konto nie istnieje
    Konto nie istnieje  
  • #10 14365064
    Obywatel LutZek
    Poziom 13  
    Bardzo dziękuję za odpowiedź. Dorzuciłem dzisiaj układ MAX232 i ogólnie - działa :). Rzeczywiście brakowało tej negacji. Program typu echo działa bez zarzutu. W przypadku wysyłanie tego samego znaku wynik jest następujący:

    AVR - UART - dziwne wyniki w komunikacji z komputerem

    Wysyłana jest zmienna typu uint8_t o wartości 10. Jak widać - pojawia się ona na początku, później transmisja się wykracza, jak mniemam z powodu tego, że cały czas wysyłany jest ten sam znak.

    Póki co nie zamykam tematu, gdyż będzie to trochę dłuższa praca i podejrzewam, że będą kolejne kłopoty.

    Docelowo program ma służyć do komunikacji z modułem GSM. Po włączeniu modułu następuje autobauding - mikrokontroler musi wysyłać komendę 'AT' z prędkością 9600/19200/57600 bps tak długo, aż otrzyma odpowiedź 'OK'. Obawiam się, że również przy tym mogą wyjść "krzaczki"
  • #11 14365517
    BlueDraco
    Specjalista - Mikrokontrolery
    Nie można przez UART transmitować znaków ciągle. Musisz co kilkadziesiąt znaków odczekać czas nie krótszy, niż czas transmisji jednego znaku - inaczej odbiornik zgłupieje i przestanie się synchronizować z nadajnikiem. Jeśli piszesz prosty test transmisji - nadawanie w kółko jednej litery, to pomiędzy kolejnymi znakami odczekaj, chociażby w pętli opóźnienia.
  • #12 14396617
    Obywatel LutZek
    Poziom 13  
    Kolejne małe udoskonalenie. Chciałem napisać funkcję wysyłającą ciąg znaków.

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


    Tym razem program działa... pewnym sensie. Wysyła co drugi znak. Pisząc "Lubie chleb ze smalcem", wynikiem jest "Lbeclbz mle". Lub wytwór bardzo podobny. Niestety bez komendy return(0) program wychodzi z pętli for i rozpoczyna się od nowa :/.
  • #14 14401234
    Obywatel LutZek
    Poziom 13  
    Bardzo dziękuję za odpowiedź :). Rzeczywiście średnik jest zbędny :). Dzięki zlikwidowaniu przerwań od TXC program już nie wychodzi z pętli. Oto wyniki jakie otrzymuję wysyłając cały czas zdanie "Lubie chleb ze smalcem" (:D). (Drugi screen pokazuje wartość wskaźnika.

    AVR - UART - dziwne wyniki w komunikacji z komputerem AVR - UART - dziwne wyniki w komunikacji z komputerem

    Funkcja nie działa też w takiej formie:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Na ten moment najlepiej działa ta:

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


    Podejrzewam, że to moze być coś z typami zmiennych.

    Kiedy zadeklaruję command jako const char - niestety program nie przyjmuje takiej deklaracji funkcji w programie.
    Pozdrawiam :)
  • REKLAMA
  • #15 14406343
    Obywatel LutZek
    Poziom 13  
    Właśnie przetestowałem jak działa program gotowy, napisany przez kogoś innego. Wyniki dokładnie te same, czyli to musi być jakiś problem ze sprzętem (?). Ale to mi się nijak kupy nie trzyma, dlaczego program typu echo działa poprawnie?
  • #16 14406358
    BlueDraco
    Specjalista - Mikrokontrolery
    Pokaż ustawienia terminala (zakładka Port) i cały najkrótszy z niedziałających programów, który Twoim zdaniem powinien działać.
  • #17 14406383
    Obywatel LutZek
    Poziom 13  
    Oto ustawienia:
    AVR - UART - dziwne wyniki w komunikacji z komputerem

    A oto program, który powinien zadziałać:

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


    Bardzo dziękuję za odpowiedź
  • #18 14406539
    BlueDraco
    Specjalista - Mikrokontrolery
    A jakie są wyniki działania tego programu na terminalu? Pokaż też schemat połączeń - to może być błąd w zasilaniu MAX232 lub podłączeniu jednego z kondensatorów.
  • #20 14408653
    Obywatel LutZek
    Poziom 13  
    Więc wyniki działania powyższego programu:
    AVR - UART - dziwne wyniki w komunikacji z komputerem

    Tekst: "To jest wynik programu 'ECHO' wykorzystujacego przerwanie RXCIE" Jest wysyłany cały czas z poziomu tego samego programu - po prostu dołączyłem ponownie wspomniane powyżej przerwanie od RXCIE, a to jest odpowiedź na tekst wysyłany z terminala.

    Wyniki zastosowania dwóch funkcji (UART_TX i UART_String_TX) są dość mizerne. Program jest znacznie stabilniejszy przy zastosowaniu mojej własnej funkcji:

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


    Wówczas wyniki prezentują się następująco
    AVR - UART - dziwne wyniki w komunikacji z komputerem
  • #21 14408793
    BlueDraco
    Specjalista - Mikrokontrolery
    Podejrzewam odjazd częstotliwości wbudowanego oscylatora ATmega w górę. Możesz to zweryfikować wstawiając po UDR=command[i]; Jakieś opóźnienie rzędu ok. milisekundy.

    To jest za to zbędne (drugi raz, po załadowaniu rejestru UDR):
    while(!(UCSRA&(1<<UDRE)));

    A jeżeli wstawienie tego pomaga, to by wskazywało na objaw, o którym piszę. Procedury wysyłania łańcucha, które pokazałeś, powinny działać jednakowo.

    Inny prosty test na to samo - zwiększ o 1 wartość wpisywaną do UBRR.
  • #22 14408835
    p.kaczmarek2
    Moderator Smart Home
    Obywatel LutZek napisał:

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


    Od kiedy to 10 oznacza A? Tutaj miałeś jeden błąd, nie wiem jak inne, ale to psuło pierwszą pętle...
    Pomogłem? Kup mi kawę.
REKLAMA