Programowy UART - problem (Atmega168)

[michalb]

Witam wszystkich.

Parę lat temu poskładałem robota z czasopisma ks ekspert. Ostatnio dowiedziałem się, że można sterować uC przez UART i chciałem to wykorzystać w tym robocie.

Niestety - jak widać na schemacie - piny tdx i rdx są już tam zajęte. Dlatego chciałem spróbować wykorzystać programowy UART na jedynych wolnych pinach - PC1 i PC2.

Najpierw przetestowałem to rozwiązanie na płytce testowej z procesorem Atmega8 i działało wszystko tak jak chciałem. Niestety po wgraniu identycznego programu do robota (Atmega168) w terminalu leciały same krzaki.

Myślałem, że to może coś z procesorem więc przełożyłem ten zaprogramowany z płytki testowej, ale to nic nie zmieniło.

Do komunikacji z komputerem używam modułów radiowych mobot, ale to raczej nie jest przyczyna, bo na płytce testowej wszystko działa bez problemu.

Może ktoś z was ma jakiś pomysł co może być nie tak?

Płytkę testową, na której to działa składałem z tego schematu.

Program pisałem w Bascomie, w razie czego mogę wrzucić kod, ale to raczej też nie jest przyczyną tego problemu.

[KD93]

Masz te same baudy poustawiane na pewno?

[michalb]

Tak, wszędzie mam 57600, po za tym tak jak pisałem, przełożyłem do robota procesor z płytki testowej, na której wcześniej wszystko działało i dalej były krzaki. Jak będę miał więcej czasu to spróbuję przerobić płytkę robota, tak żeby przepiąć to z PD0 (RDX) i PD1 (TDX) na PC1 i PC2 i sprawdzić czy sprzętowy UART będzie działał.

Kombinowałem jeszcze trochę z tym i odkryłem ciekawą rzecz. Jeżeli do modułu radiowego podłączyłem zasilanie z płytki testowej, to te "krzaki" wyglądały inaczej i można było między nimi znaleźć to co chciałem przesłać.

Zmieniłem moduł radiowy na połączenie przez maxa232 i było tak samo - jeśli max był podłączony pod zasilanie robota to były same krzaki, a jeśli pod zasilanie z płytki testowej to krzaki + tekst.

Niestety na elektronice się nie znam i nie wiem czym się różnią zasilania na obu płytkach, jak zmierzyłem napięcie to na płytce testowej było 4,47V, a na robocie 4,97V, ale to przecież nie powinno mieć znaczenia bo ten moduł radiowy powinien działać 2,7-5V.

Sprawdziłem - sprzętowy UART działa normalnie, ciekawi mnie dlaczego programowy nie chce, ale nie będę już z nim nic raczej kombinował, bo szkoda czasu.

[BlackJack]

Ja bym proponował najpierw sprawdzić sobie standardową szybkość 9600 bod, jak będzie ok, to krokami zwiększać aż dojdziesz do granicy stabilności łącza.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[marek1707]

Hm, taktujesz procesor wewnętrznym oscylatorem RC - to może być problem jego częstotliwości. Istnieje (wręcz niewiarygodnie) silna zależność f od temperatury i od napięcia zasilania. To może tłumaczyć dlaczego procek przełożony do innej płytki nie działa. W jednym z moich sterowników (attiny84) musiałem wbudować procedury autobaudrate, które kalibrowały podzielniki timera do uzgodnionego znaku wzorcowego przysyłanego z PC. W zasadzie jeżeli chce się w sposób pewny używać transmisji asynchronicznej, to kwarc jest niezbędny.

W atmega48 masz rejestr OSCCAL - spróbuj w nim pogrzebać, zmieniając jednorazowo wartość w nim zastaną małymi kroczkami, np. o 2 w górę lub dół:

OSCCAL += 2;

lub

OSCCAL -= 2;

i sprawdź, czy się poprawiło. U mnie pomagało przestrajanie o 5 ale zależało od sztuki procesora i odpuściłem tę metodę. Przy jednorazowym projekcie warto popróbować.

Normalny UART ma fajnieszy algorytm próbkowania bitów odbieranych. Robi to 3 razy i sprawdza czego było więcej. Nawet jeśli prędkość jest "na styk" i pod koniec znaku moment próbkowania zbliża się do granicy bitów, to dorosły UART sobie poradzi a procedury programowe nie. Chyba, że zrobiłeś automat jak tam ale to wymaga conajmniej 4 krotnie szybszych przerwań niż baudrate i nie zawsze jest możliwe do przyjęcia ze względu na obciążenie CPU.

Skoro jeszcze nikt się nie dopisał to dodam moje trzy (kolejne) grosze. Przyszło mi do głowy, że to może być też problem przesyłania full-dupleksowego, czyli jednoczesnego w obie strony. UART radzi sobie z tym bezproblemowo bo po pierwsze ma oddzielne bloki nadajnika i odbiornika a po drugie buforuje conajmniej jeden znak w każdą stronę. Jeżeli procedury programowe są oparte np. na aktywnym oczekiwaniu i pętlach opóźniających (zamiast na automacie pracującym na przerwaniach) to nie mogą pracować w full-dupleksie i pogubią się gdy protokół tego wymaga. Wystarczy, że np. procek będzie odsyłał echo do PC tego co odebrał a PC (lub cokolwiek bądź) będzie przysyłał znaki ciurkiem bez przerw. Wtedy kicha bo będziesz zajęty nadawaniem gdy coś właśnie będzie przychodziło.

Edit: dopisałem ostatni akapit (o UART).

Edit2: dopisałem kolejne poszlaki (o full-dupleksie)

[michalb]

Dzięki za odpowiedzi, zapomniałem włączyć powiadomień o nowych postach i teraz dopiero tu zajrzałem. Jak kiedyś będę miał więcej czasu to może jeszcze pobawię się tym programowym UART'em. Na razie przerobiłem sobie płytkę tak, żeby działał sprzętowy i aktualnie uczę się go obsługiwać.