Witam, stworzyłem prosty program sprawdzający transmisję USART podczas którego wysyłany był znak o kodzie 0x37 (czyli '7') jednak na komputerze w programie putty wyświetlany był znak o kodzie 0x64 (czyli 'd'). Co może być przyczyną zmian w transmitowanych danych? Spotkał się już ktoś może z czymś takim?

Oto kod tego programu:





Dodam jeszcze, że korzystałem z mikroprocesora ATmega664pa oraz próbowałem różnych wariantów przy inicjalizacji tej komunikacji(liczba bitów stopu, częstotliwość mikroprocesora, różne kody ASCII wysyłanego znaku) a także sprawdziłem wysyłane dane przy użyciu innego programu niż putty(tak więc problem tkwi z pewnością w programie mikroprocesora, a nie w ustawieniach programu monitorującego).

Jestem wdzięczny za wszelką pomoc.

Po pierwsze czy jesteś pewien, że procek ustawiony jest na 11,0592MHz ??? Tylko może pokaż jakiś zrzut ekranu w którym widać odczytane z procka Fusebity żeby to potwierdzić OK ?

Po drugie czy masz na pewno tak samo ustawione parametry transmisji z programem terminala ?

Bo testowy program tak na pierwszy rzut oka wygląda OK - zatem winę za taki stan rzeczy może ponosić właśnie któryś z wyżej wymienionych punktó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 ]

Najwyraźniej z powyższym wszystko w porządku, oto fotki:
http://imageshack.us/g/189/fusebity.png/

Przy okazji: zapomniałem wcześniej wspomnieć, że używam do tego przejściówki usb-rs232 (jeśli to istotne).

Oczywiście obrazka z fusami pod wskazanym linkiem nie widać niestety.

Kod sprawdziłem i jest napisany w taki sposób że na 100% powinien działać na ATmega644P(A)

Nie mam pod ręką tego procka ale skompilowałem sobie twoje dzieło pod ATmega32 zmieniając oczywiście TYLKO nazwy rejestrów i bitów no i dodając jeszcze bit URSEL bo przy ATmega32 taki akurat jest.

i jak myślisz działa ?

Oczywiście, że działa i to bez mrugnięcia oka wyświetlają się znaki 7 albo dowolne inne które wysyłam.

Dlatego jeszcze raz ci podpowiem - patrz na punkty, które ci wyżej napisałem. Ja obstawiam:

że na 99,999% po skompilowaniu na ATmega644P też by działał ale że nie mam go pod ręką i nie mogę sprawdzić skompilować to daję sobie ten 0,001% że może coś byłoby nie tak

Nadmienię, że także używam przejściówki USB/RS232 wbudowanej w zestaw uruchomieniowy ATB.

_________________
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 ]

Sprawdziłem jeszcze dziesiątki razy czy wszystko dobrze skonfigurowałem i cóż.. wygląda na to, że lepiej już nie potrafię. W ostateczności znalazłem pewną prawidłowość w tych różnicach(pomiędzy znakami w programie ustawionymi do transmisji, a znakami w terminalu). Otóż po przesunięciu bitowym o jedno miejsce w lewo i zamianie zer na jedynki w zapisie binarnym tego znaku zaczął on odpowiadać oczekiwanemu znakowi w kodzie ASCII.

Oto jak ta modyfikacja wygląda w kodzie funkcji transmisji znaku:


Teraz wszystko wyświetlane jest już poprawnie, ale to dlaczego dane są transmitowane w tak dziwny, przekombinowany sposób dalej mnie nurtuje, więc jak ktoś zna odpowiedź chętnie posłucham.

No tak ale tą drogą obchodzisz tylko problem okrężną drogą a nie go rozwiązujesz.

Bo po takim efekcie to tym bardziej można być pewnym, że program bez żadnych przeróbek w procku jest dobry

Lepiej sprawdź sobie czy przypadkiem nie masz zanegowanej transmisji na liniach Tx i Rx w przejściówce USB/RS232 bo coś tak mi pachnie

_________________
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 ]

Sprawdziłem właśnie przy pomocy diody tj. wysyłając na katodę sygnał z portu transmisji mikroprocesora(anoda diody do VCC) i przy wykorzystaniu niezmienionego kodu z początku tego tematu wysłałem znak 0xFF oraz 0x00 i tu obyło się bez niespodzianek -dioda świeciła wyraźnie jaśniej przy wysyłaniu 0x00. Wygląda więc faktycznie na to, że to przejściówka odwraca bity i przez to było te całe zamieszanie. Tak więc tajemnica rozwiana... dzięki za pomoc.