Dotychczas AVR-y programowałem w czymś innym niż C (ale nie będę pisał w czym, bo wstyd .

Teraz chwyciłem za serię poradników do RS232 pana Mirka i napisałem sobie kod dla Atmegi32, który ma słać znak "A" w pętli, przy prędkości 4800 8,n,1, przy okazji co sekundę zmienić stan LED-a.

Led niby miga poprawnie, ale oczywiście (na szczęście? ) coś nie do końca działa z transmisją po UART i pewnie zaraz dojdę w czym problem. Aż jestem ciekaw co i jak bardzo spaprałem

Natomiast piszę tutaj na forum, na żywca, żeby pokazać, jak fajnie mieć do dyspozycji wygodne narzędzia (na przykład analizator stanów logicznych, w moim przypadku klon Salea-e prosto z Chin za 10 zł

Najpierw "mój" kod:


Ustawienia projektu:


Fusebity Atmegi32:


Dobra, czyli nie docierają do mojego putty znaki "A" wysyłane w pętli przez Atmegę32. Wpinam się więc analizatorem Saleae do TX-a Atmegi i sprrawdzam co się dzieje. Więc tak, jakaś transmisja jest:



ale widać, że analizator kodu sygnalizuje błędne ramki. Analizator skonfigurowany jak widać poniżej:



Ramki wyglądają tak:





I teraz czas na rewelacyjną funkcję Saleae



Pewnie spaprałem coś z timingami / baudrate-m. Może źle załadowałem jakieś rejestry UART-a.

Po zaznaczeniu autobaud Saleae twierdzi, że baudrate jest w rzeczywistości 304 (zamiast 4800)



I przy takim właśnie baudrate zaczyna rozpoznawać znaki "A"



A teraz czas namierzyć problem... Hmm... 4800 / 304 = 15,789473684210526315789473684211
Hmm, czyli transmisja jest około 16 razy wolniejsza niż planowałem. Chyba muszę trochę pomyśleć Znikam, i mam nadzieję, wracam niebawem

_________________
http://www.jaglarz.info

Zerkam do przykładów bibliotek Mirka i widzę że tam makro do liczenia __UBRR wygląda inaczej. Może to w tym problem?!

_________________
Podpis...

Hmm... Muszę się temu przyjrzeć. Niemnniej kod do UBRR wziąłem stąd:



A, zaraz, gdzieś czytałem, bodajże na blogu pana Mirka że ten wzór ponoć ma nie działać dla kwarców innych niż przyjazne dla UART. No nic, muszę przyjrzeć się tematowi. Ale, czyżby efektem mogło być spowolnienie baudrate'a 16 razy?

witam,
Chyba brak ustawionego bitu URSEL w UCSRC. ?

Hmm...

Z noty wynika, że ten bit jest domyślnie ustawiony po resecie na "1".



Jak rozumiem, URSEL przełącza dostęp między rejestrami UCSRC oraz UBRRH. Musi być jedynką podczas pisania do UCSRC.

Niby tak, ale w kodzie jest : UCSRC =...
A nie UCSRC |=.. ?

------------------------ [ Dodano po: 2 minutach ]

Czyli zerujemy pozostałe bity.

Hmm. Nie wiem, dlaczego, ale ustawienie (1<<URSEL) rzeczywiście rozwiązuje problem.
Ja tego nie rozumiem nazbyt, ale jeśli ktoś potrafi to jakoś wytłumaczyć chętnie prześledzę.

Poprawny kod:

------------------------ [ Dodano po: 4 minutach ]

zauważ że wpisem '=' wpisujesz w rejestr dokładnie to co jest z prawej. UCSRC=3<<1 /(UCSZ0)
w tym wypadku nie korzystamy z zapisu |=...dlatego pozostałe bity kasuje.

------------------------ [ Dodano po: 10 minutach ]

gdybyśmy tego rejestru nie ustawiali to domyślnie byłoby tak jak piszesz.
pozostałby ustawiony pierwszy i siódmy bit w rejestrze.
ale my to zmieniamy na: 1,2,7.

OK. Czyli po resecie URSEL teoretycznie ustawione na 1 ale ja i tak to zmieniałem, ustawiając (3 << UCSZ0).
Dobra, wygląda na to, że wszystko jasne. Dzięki.

PS. Wcześniej chyba za bardzo zaabsorbowałem się tym momentem:

no można się machnąć, tam jest ustawienie dla Atmegi328 . jest trochę inaczej.

------------------------ [ Dodano po: 8 minutach ]

zerknij do BB bo widzę że masz. rozdział 5,8 Komunikacja RS232/RS485. jest przykład.

Generalnie już wszystko działa (tak jak pisałem post wyżej) i wiem, gdzie robiłem błąd. Ale i tak zajrzę