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

[Atmega8/C] Atmega8 - UART niepoprawnie odbiera dane z PC, gubi bajty po pierwszym

lycon5 26 Wrz 2013 12:50 2088 8
REKLAMA
  • #1 12779299
    lycon5
    Poziom 11  
    Napisałem sobie obsługę protokołu modbus pod Atmege8 (taką prowizoryczną). W fazie projektowej symulowałem zapytanie od Mastera które było analizowane zaraz po wystartowaniu. uC reaguje prawidłowo tzn. Wysyła ramkę zgodną z oczekiwaniami. Problemy zaczęły się przy odbiorze danych po interfejsie UART. Otóż dane odbierane przez uC nie zgadzają się z tym co wysyłam z PC. Dla testów w przerwaniu natychmiast zwracam otrzymany bajt i zauważyłem, że pierwszy bajt zawsze jest poprawny. Każdy następny jest już uszkodzony, ponadto występuje zjawisko gubienia bajtów. Np. wysyłam 4 to zwraca 3, wysyłam 8 zwraca 6. Przykładowa ramka:
    M: [05][03][00][00][00][02][C5][8F]
    S: [05][20][00][02][71][FC]


    Błędy są konsekwentny, tzn. nie pojawiają się losowe dane lecz powtarzalne.

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


    Próbowałem zmieniać konfigurację połączenia itp. ale raczej wtedy wszystko by się sypało a nie tylko odbiór na sprzężeniu.

    Help :)
  • REKLAMA
  • #2 12779349
    Tomasz Gumny
    Poziom 28  
    Jak wygląda obsługa przerwania od TXC? Czy jak wysyłasz znaki pojedynczo, to też giną?
  • #3 12779351
    szelus
    Poziom 34  
    Rejestr danych nadajnika w Atmedze8 nie jest buforowany. Nie możesz wpisywać następnego bajtu nie upewniwszy się, że wysyłanie poprzedniego zakończyło się.
  • REKLAMA
  • #4 12779452
    tmf
    VIP Zasłużony dla elektroda
    szelus napisał:
    Rejestr danych nadajnika w Atmedze8 nie jest buforowany. Nie możesz wpisywać następnego bajtu nie upewniwszy się, że wysyłanie poprzedniego zakończyło się.


    Nie jest to prawdą. Posiada on jednopoziomowy bufor - dane z rejestru data są przesyłane do rejestru szeregowego nadajnika, a w trakcie ich nadawania kolejne dane możemy zapisać do rejestru nadajnika.
    Do autora: sprawdzałeś stan rejestru Status? Nie wskazuje on na jakiś błąd, np. parzystości, przepełnienia, czy overrun? Od tego bym zaczął. Jak jest taktowana ATMega?
  • REKLAMA
  • #5 12779499
    lycon5
    Poziom 11  
    Tak wygląda program z buforowaniem. Napisałem go wcześniej ale efekt był tak sam a szukajac informacji spotykałem się z tym, że UDR był nadpisywany zaraz w przerwaniu od RX.
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Nie mam możliwości sprawdzenia statusu w sensowny sposób. Nie mam debbugera a układ nie ma żadnego interfejsu (LCD, Dioda) oprócz rs232. ATmega taktowana jest kwarcem 11,0592 a prędkość transmisji to 9600.

    @Tomasz - Gdy wysyłam pojedyńczo nic nie ginie. Zawsze pierwszy bajt transmisji jest ok.

    Jest jedna myśl - zorientowałem się, że projektant podłączył V+ przez kondensator do masy zamiast do napięcia. Czy może mieć to duże znaczenie ? Przecież komunikacja uC->PC jest bez zarzutu tylko w drugą stronę się kaszani.
  • REKLAMA
  • Pomocny post
    #6 12779749
    tmf
    VIP Zasłużony dla elektroda
    V+ z układu MAX232, znaczy element pompy ładunkowej? Może mieć znaczenie, być może w czasie szybkiej transmisji napięcie siada i poziomy się rozjeżdżaja. Połącz bez procka Rx z Tx za MAXem i sprawdź echo na PC. Albo popraw ten błąd.
  • Pomocny post
    #7 12779773
    BlueDraco
    Specjalista - Mikrokontrolery
    1. Co to jest:
    UCSRB|=(1<<UCSZ1)|(1<<UCSZ0);

    2. Najpierw wpisz parametry transmisji w innych rejestrach, potem dopiero włącz transmisję w UCSRB.
  • Pomocny post
    #8 12779920
    Tomasz Gumny
    Poziom 28  
    lycon5 napisał:
    [...] Gdy wysyłam pojedyńczo nic nie ginie. Zawsze pierwszy bajt transmisji jest ok.
    Zatem nie nadążasz odbierać z PC, nadpisujesz bufor ze znakiem wysyłanym do PC albo PC nie nadąża z odbiorem. Stawiam na drugi przypadek.
  • #9 12779936
    lycon5
    Poziom 11  
    V+ do masy nie było problemem. Jednak inicjalizacja rzeczywiście była niepoprawna. Dziwi mnie strasznie ten błąd zwłaszcza, że komunikacja uC->PC działała poprawnie. @BlueDraco - Miał to być port UCSRC, czeski błąd. W sumie nadpisywało to instrukcja poniżej. Mniejsza.

    Dzięki wszystkim, problem rozwiązany :-)
REKLAMA