Witam.
Mam pewien problem z biblioteką do UART'a z BB. Jest wgrana na dwa procki ATmega8 i ATmega16. Komunikacja z putty na każdym z nich działa bez problemu w obie strony. Problem pojawia się gdy podepnę 2 procki ze sobą. W przerwaniu odbioru po znaku return (\r - 13) powinna nastąpić inkrementacja linii i obsługa zarejestrowanego callbacka.
Problem polega na tym, że przy użyciu funkcji puts("Test\r") drugi procek nie odbiera znaku końca linii '\r'. Natomiast po wysyłaniu każdego znaku z przykładowo sekundowym delayem znak 'r' jest odbierany. Sprawdziłem to migającą diodą.
Procki są taktowane 16MHz kwarcem, a prędkość UART to 0,5 Mbps. Od razu dodam, że wpiąłem się również przejściówą RS232-USB do procesora, który wysyła dane (m16) i w putty wszystko wygląda ok. Więc jest to problem w przewaniu odbierającym dane.

Dodatkowo testowałem odbiór danych terminalem HTerm, który nie wysyła znaków pojedyńczo po każdym kliknięciu (jak putty), lecz jednym ciągeim i w tym przypadku również występuje ten sam problem.

Czy ktoś z was używał i testował kiedyś te biblioteki z BB do wysyłania danych między prockami? Ktoś miał kiedyś taki problem? Być może jest to wina prędkości uarta w moim przypadku, albo bug w kodzie.

Proszę o porady w tej sprawie.
Pozdrawiam.

Coś nieźle namieszałeś w kodzie bo w BB nie było calbacka w bibliotece

Owszem, pomyliłem BB z GB, gdzie jest callback dodany (lekcja 21 - uart-ascii-at)

a może masz starsze wydanie książki i nie zaglądasz nigdy na stronę wydawnictwa

http://atnel.pl/uaktualnienia-programow-do-dvd.html

a tam masz dla GB



i link po prawej z wyjaśnieniem

_________________
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 w 1 poście pojawił się błąd, który mógł zmniejszyć czujność. Jeden z procesorów (m8) był taktowany z prędkością 8MHz wewnętrznym oscylatorem i zasilany napięciem 3,3V ze wezlędu na kompatybilność z innymi urządzeniami peryferyjnymi.
Problem polegał na tym, że odbierane dane nie były poprawne ze względu na niedokładne taktowanie. Rozwiązaniem była kalibracja rejestru OSCCAL lub wymiana na zewnętrzny kwarc 8MHz.
W tym przypadku zdecydowałem się na wykorzystanie zewnętrznego kwarca, gdyż myśle, że będzie działał stabilniej niż wewnętrzny oscylator, a dodatkowo układ może pracować w różnych warunkach atmosferycznych.
Dziękuję również za podpowiedź dotyczącą uaktualnienia kodu źródłowego.