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

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:


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



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

Jak wygląda obsługa przerwania od TXC? Czy jak wysyłasz znaki pojedynczo, to też giną?

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ę.

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?

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.


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.

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.

1. Co to jest:
UCSRB|=(1<<UCSZ1)|(1<<UCSZ0);

2. Najpierw wpisz parametry transmisji w innych rejestrach, potem dopiero włącz transmisję w UCSRB.

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.

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