Witam,
mam pytanie odnośnie modułu UART np. w ATmedze8. Czy to na pewno jest full duplex tak jak piszą w karcie katalogowej? Wątpliwości nabrałem przez 2 rzeczy:
1) wspólny rejestr UDR - skoro jest wspólny to nie da się jednocześnie nadawać i odbierać danych, bo mogłyby się nałożyć,
2) gdy wysłałem z PC 100 razy bajt 0x00 (odstępy pomiędzy bajtami pomijalnie małe) to w komputerze najpierw zacząłem odbierać jakieś śmieci, a dopiero pod koniec właściwe bajty. Ustawiłem sobie odpowiedź ATmegi na 0x41, a odpowiedź zarejestrowana przez PC (na te 100 bajtów) wyglądała następująco:
0000000000800000000000000000000000000000000000000040000000000000008000000000000000000000000000000000000000400000414141

Nazywają się tak samo, mają ten sam adres, ale to dwa odrębne rejestry. Tak, na pewno jest full-duplex.

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

1. kwarc czy wewnętrzny rc ?
2. Jaki stan połączeń atmega - pc/konwerter ?
3. Wrzuć kod procedur odbioru/nadawania bo z podobnymi przypadłościami już miałem do czynienia w swojej bibliotece

_________________
AVR-UART-lib
AVR-FAST-ENCODER
RFM7x-lib

No właśnie nie doczytałeś tej noty - ale wyżej kolega xor ci wyjaśnił


To jest NAJCZĘŚCIEJ wina softu - ale ty każesz zgadywać - tak się nie da ....

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Znaczy nie chciałem, żebyście zgadywali. Najpierw wolałem się dowiedzieć tego o co zapytałem. Błąd znalazłem (ale czy jedyny), ale nie mam pomysłu jak go naprawić żeby wszystko działało zgodnie z moim zamysłem.
No to teraz moja koncepcja i dane projektu: kwarc 7.372800MHz, z pc komunikuję się przez RS232 i konwerter MAX232. Program ma służyć do komunikacji z aplikacją na pc i zbierania pomiarów z czujników temperatury ds18b20. Użytkownik z komputera wysyła odpowiedni rozkaz, a ja go przetwarzam i odsyłam mu odpowiedź. Ramka danych przesyłanych z pc wygląda następująco: <liczba bajtów ramki> <rozkaz> <opcjonalne bajty w zależności od rozkazu>. Problem napotkałem między innymi w momencie gdy z pc wysyałełm 2 bajty (0x01, 0x02) co odpowiada ustalonej reakcji na taką wiadomość, ale za nim program zdążył odebrać 2 bajt, na ekranie komputera pojawiał się 0xFF, który w zasadzie nie miał prawa zostać wysłany.
Co do odbioru to wiem że problem może leżeć, gdy zaczynam kopiować wiadomość i na ten czas wyłączam przerwania, tylko nie mam pomysłu jak to naprawić.
Obsługa USART.

Główna pętla programu.

Tak lekko mówiąc, dosyć dziwny i zawiły kod, na początek sprawdź czy to samo się dzieje w mk_usart lub w mojej bibliotece.



A nie można przepisać tutaj procedury z TXC ?


Coś takiego należy robić tylko dla UDRIE, reszta robi to automatycznie. Pomijam już utratę przychodzących danych w trakcie opróżniania bufora.

A tak apropo to polecam zapoznać się z obsługą buforów cyklicznych, w BB masz to ładnie opisane.

_________________
AVR-UART-lib
AVR-FAST-ENCODER
RFM7x-lib

dokładnie - polecam zacząć od opisu buforów cyklicznych z Bluebooka

http://atnel.pl/mikrokontrolery-avr-jezyk-c.html

aczkolwiek jak rzuciłem okiem na LIB'sa kolegi jnk0le - to przyznam, że jest zacna pomimo że mocno rozbudowania, no ale coś za coś - za to widzę, że dynamicznie w kodzie obsługuje wiele uartów

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Niestety nie można, bo już zaobserwowałem błąd, jeśli wysyłałem dane, a zaraz potem zmieniałem Baud Rate. Mimo, że UDR był już pusty to zmiana Baud Rate następowała za nim wszystkie bajty zostały wysłane z rejestru przesuwnego i wtedy pojawiały się krzaki.

A co do odbioru danych to bufor cykliczny powinien rozwiązać ten problem? Reszta jest ok?

EDIT:
Co do utraty danych jeśli bufor jest pełny, to to jest działanie zamierzone. Jedynie zastanawia mnie utrata przychodzących danych w momencie, gdy użytkownik opróżnia częściowo zajęty bufor wyłączając na ten czas przerwania.