Witam. Mam problem z wysyłanymi znakami z uC. Znaki są wysyłane, ale wyświetlane są inne znaki niż powinny.
Np. zamiast A jest _ , zamiast B jest /, zamiast ) jest K. Głowię się nad tym problemem i nie mogę sobie poradzić.
Program napisany i sprawdzony z poradnikiem o ADC część 3 i zgodnie z tym co w karcie katalogowej.
Program pisany na atmega 32A , podłączony do rs232 TLL (echo sprawdzone i jest poprawne) , taktowanie ustawione na 16 Mhz lub wewnętrzne 8 Mhz, podpinam pin TxD uC do RxD rs'a a GND rs'a do GND uC (lub TxD->RxD i RxD->TxD), ubrr obliczany ze wzoru
( FOSC + BAUD * 8UL ) / (16UL * BAUD) -1 lub ( FOSC / 16.0 / BAUD - 0.5 ). Prędkość transmisji ustawiona na 9600 lub 19200.
Problem ciągle pozostaje taki sam... kod programu :

A kolega chyba nie rozróżnia ' od " w jeżyku C
Spróbój wysłać znaki tak:


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

i to koniecznie usuń z kodu bo razi, tego nie podajemy w kodzie programu a ustawiamy tą wartość we właściwościach projektu.

_________________
Migracja z punktu B do punktu C
Pozdrawiam

Skasuj to:



i ustaw procesor i kwarc we właściwościach projektu.

Proponuję ci przy korzystaniu z UARTu używać kwarce typy 11,0592, 14,7456 lub 18,432 MHz
Są to "przyjazne" kwarce dla UARTa.
Sprawdz również filtrację zasilania i czy zastosowałem kondensatory przy rezonatorze.

Wydaje mi się, że w tym przypadku to nie zadziała. Taki zapis 'A' to stała znakowa czyli kod Ascii odpowiadający dużej literze A.
A taki zapis "A" to już C-string czyli kod Ascii dużej litery A plus znak końca stringa NULL.

Funkcja USART_Transmit jako argumentu oczekuje zmiennej char. I taki argument dostaje w przypadku takiego wywołania


Natomiast w tym przypadkudo funkcji został by przekazany wskaźnik na pierwszy znak C-stringa. Już to spowoduje, że kompilator zgłosi warninga.

Niestety, ale po zamianie ' na " zupełnie się krzaczy i wyskakuje :warning passing argument 1 of 'USART_Transmit' makes integer from pointer without a cast [enabled by default] . A co do zapisu F_CPU... poprawione.

Faktycznie, kolega @jacekk232 ma 100% racji, to ja oczywiście pomyliłem znaczenie " i ' - przepraszam za wprowadzenie w błąd.

Wracając do problemu, to kod wydaje się być poprawny, rozwiązania szukałbym w podłączeniach, sprzęcie, ew. konfiguracji terminala i komunikacji RS232 w nim ustawionej.

_________________
Migracja z punktu B do punktu C
Pozdrawiam

Pin 15 atmegi 32a podłączony do 2 pinu rs232. Prędkości są te same w programie i terminalu. Ramka 8n1. Znaki w terminalu odpowiadają znakom w tablicy ASCII. Czy możliwe, że kompilator może mieć coś inaczej? (wydaje mi się, że nie powinien)

A jakiego terminala używasz?
Ja sprawdziłem twój kod na zestawie ATB i w terminalu Putty działa bez zarzutu.

_________________
Migracja z punktu B do punktu C
Pozdrawiam

Sprawdzam na PuTTY i również na Realterm i wynik jest identyczny.


edit. Problem rozwiązałem. Zastąpiłem przejściówkę rs232 na moduł usb-uart i wszystko działa prawidłowo.
Dziękuję wszystkim za pomoc.

Witam.
Mój kłopot jest niemal identyczny do powyższego. Korzystam z zestawu ATB_v1.04 oraz terminala Putty, ATMEGA644pa.
Chciałem dokonać pierwszej transmisji. Użyłem nawet udostępnionego wyżej kodu zamieniając nazwy rejestrów na odpowiadające.
Efekt - otrzymuje znaki "u", lub znak "y" z różnymi akcentami (kropki, kreski, daszki nad literą). Nie posiadam żadnych modułów rozszerzających
Wklejam kod prosto z Eclipse'a.


Ustawienia rejestrów UBRR0L i UBRR0H z tabeli w dokumentacji. W mkAVR Calculator ustawiłem 8MHz z wewnętrznego oscylatora. Prędkość 9600 bez bitu parzystości, jeden bit stopu.
Pytanie moje brzmi, co jest źle? Jak mogę dokonać najprostszej poprawnej transmisji?
Proszę o pomoc.

Fajnie że ustawiasz UCSZ0x, szkoda, że przy starcie są już ustawione dobrze

PS. ... i że są w innym rejestrze

_________________
Nie pisz komentarzy - dobry kod komentuje się sam.

Fakt Przy N-tej zmianie musiałem źle wpisać.
Poprawiłem, ale nic to zbytnio nie dało. Nadal mam zamiast 'A' znak 'u' z kropkami u góry.

Poszlaką w sprawie może być nie zawsze działający poprawnie program Putty.
To jest, nie zawsze umie otworzyć terminal. Problemy występują kiedy każę mu wyłączyć flow control... Ale to może być coś nie związanego.
W każdym wypadku nie wyświetla się to co powinno.

No to panie masz poszlaki - .... niech to gęś kopnie .... sorki ale nie mogę się powstrzymać - no jak nie umiesz czegoś obsługiwać - to nie pisz, że to źle działa - tylko albo staraj się nauczyć obsługi albo weź inne prostsze czy tam lepsze dla siebie narzędzie. Bo przy takim podejściu to twoja droga do nauczenia się czegoś wydłuży się w nieskończoność - i nie odbieraj tego źle co piszę tylko weź się w garść i szukaj błędów w tym co robisz .... a robisz ... już chociażby po tym zdaniu widać - że robisz coś o czym pojęcia nie masz:


A wiesz co to jest to "flow control" ? bo ja po tym co napisałeś jestem pewien, że nie wiesz - a nawet jeśli wiesz - to nie wiesz jak się z tego korzysta ....

Więc teraz podpowiem ci "nie każ mu włączać flow control" daj sobie z tym spokój i nie włączaj mechanizmów o których nie wiesz jak działają - to już będzie pierwszy krok do sukcesu.

Poza tym co to w ogóle znaczy:

Co to znaczy - nie umie ? ... panie kochany uwierz mi - na tym etapie to ty nie umiesz - bo program SAM nic nie robi, a ty po prostu albo się gubisz w ustawieniach i konfiguracji sprzętowej albo masz totalny bałagan w sterownikach.

Na co dzień od ponad 6 lat używam Putty jako podręcznego i solidnego terminala o sporych możliwościach m.in takich:
http://mirekk36.blogspot.com/2013/05/te ... z-lcd.html

o czym pewnie nawet nie słyszałeś jeszcze ....

W wielu poradnikach wideo opowiadam nawet jak go skonfigurować....

Jeśli masz ATmega644P - to pokaż swój kod po naprawach - wyżej kolega wskazywał ci błędy - a ty zamiast szukać dalej - to winy szukasz w jednym z najlepszych terminali ...

Masz zestaw ATB to masz komfortową sytuację bo MkAvrCalculator podpowiada ci jaki jest port COM - numerek

jeśli jednak używasz wbudowanego programatora to MUSISZ wiedzieć, że oparty jest on o układ FT232R czyli jeśli np odpalisz terminal i nawiążesz połączenie to wtedy np nie uda ci się zaprogramować procka wbudowanym programatorem, trzeba na chwilę rozłączyć terminal - zaprogramować i wtedy dopiero można znowu włączyć

WYWAL z kodu ten OSCCAL .... masz w książce opisane w jaki sposób NAJPROŚCIEJ sprawdzać komunikację wysyłając po jednym znaku a ty kombinujesz z OSCCAL ... nie wiedząc jeszcze dokładnie o co chodzi z tym OSCCAL bo pewnie całego rozdziału jeszcze nie przeczytałeś.

Ja wiem, wiem i rozumiem, że człowiekowi się śpieszy, że chciałby JUŻ, teraz OD RAZU - ale jak widzisz co nagle to po diable

poza tym jeśli chodzi o ustawianie prędkości UBRR to zajrzyj że na bloga

http://mirekk36.blogspot.com/2013/01/rs ... trick.html

I jak mówię - chcesz aby ci szybko i skutecznie pomóc ? To najpierw pomóż sam sobie i DOKŁADNIE opisuj problem a jak poprawiasz kod to pokaż że go tu na forum a nie opowiadasz tylko że poprawiłeś - bo lecisz z totalnych chaosem mówię ci

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

Jeśli chodzi o flow control to przeczytałem co z definicji robi i zostawiłem z boku. Ponieważ w jednym z video poradników, Pan uruchamiał z wyłączonym, więc na wszelki wypadek również taką możliwość sprawdziłem.

W kodzie zmienia się jedna litera przy UCSR0C|=(1<<UCSZ01)|(1<<UCSZ00) było B jest C. Tak jak Pan pisał usunąłem zmianę OSCCAL.


Co do nie włączania się terminalu: Doskonale rozumiem, że korzystam z jednego fizycznego połączenia przy programowaniu jak i późniejszej transmisji. Za każdym razem rozłączam Terminal przed wgrywanie poprawionego kodu. Problem z otwarciem występował już kiedy procesor "nadaje". Może to kwestia ustawień więc jeszcze poszukam w nagraniach.

Popatrz - masz

1. W książce
2. w nocie PDF procka
3. we wszystkich przykładach w necie

pewną kolejność inicjalizacji UBRR - a ty robisz po swojemu - jak myślisz ? może to mieć znaczenie czy nie ? Jeśli nie jesteś pewien to RÓB zawsze tak jak w nocie PDF - powtarzam to w książce po tysiąckroć - a ty po swojemu ...

------------------------ [ Dodano po: 1 minucie ]

Poza tym pewnie masz źle ustawione fusebity - ale nawet nie pokażesz jak je ustawiłeś .... więc jak można pomóc ?

Jeszcze raz powtórzę - gdy się ma problemy z TAK PODSTAWOWYMI zagadnieniami to się pokazuje WSZYSTKO co się robi - tym bardziej, że ty zmieniasz wiele rzeczy (co ci pokazałem wyżej) - "po swojemu"

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

Rozumiem że chodzi o odwrotną kolejność zapisania młodszego i starszego bitu. Poprawione.


Co do fusebit'ów, dołączam spakowane "zdjęcia" z mkAVR Calculator. Mogą być źle ustawione jeszcze ich nie sprawdzałem.

Zobacz ten poradnik: https://www.youtube.com/watch?v=JbLHXkFZwsE&feature=player_embedded#t=1570 i wyciągnij wnioski.
Może, po obejrzeniu zrozumiesz o co chodzi (nie ma sensu ręcznie wpisywać wartości do rejestrów UBRR0H i UBRR0L).

Zobacz, tutaj masz gotowca na podstawie noty pdf procka (str 177):


Resztę znajdziesz w poradniku pana Mirka.

Na wszelki wypadek zmieniłem tak jak jest w poradniku. Stworzyłem bibliotekę i wsadziłem tam funkcje. Wartość rejestrów też z funkcji tak jak napisałeś.
w głównym pliku zostało:


Funkcje:

Oraz plik nagłówkowy:

Dalej dostaje tego typu efekt:

No to teraz pokaż jak masz skonfigurowaną prędkość w PUTTY

------------------------ [ Dodano po: 1 minucie ]

aha i przy okazji nie podpiąłeś przypadkiem czegoś sobie pod nogi procka PD0 i PD1 ?

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

Mam tylko podłączone kabelki do programowania procka.
Włączam albo od razu na domyślnych zmieniając tutaj port na odpowiedni:

Albo w ustawieniah portu szeregowego zmieniając to samo

No teraz to mi się podoba. Widzę, że kolega odrobił "pracę domową".
Sprawdź jeszcze, czy na pewno masz wybrane taktowanie 8000000Hz w opcjach projektu w Eclipse, bo przecież wybrałeś taktowanie z oscylatora RC 8MHz. Jeśli masz wybrane inne, zrób Clean Project, kompilacja i wgraj do procka.

Niestety jest 8 MHz w Eclipsie Jeśli chodzi o kwarc też sprawdzę, ale to muszę sprawdzić jak się go podpina co chwilę zajmie

------------------------ [ Dodano po: 16 minutach ]

Podłączyłem zewnętrzny oscylator kwarcowy i DZIAŁA

Dziękuję wszystkim za pomoc!!!

przecież pisałeś, że masz zestaw ATB ? czy się mylę - to co tu masz do sprawdzania ? jeśli domyślnie kwarc jest właśnie podłączony do procka

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

Tak, teraz już wiem, ale musiałem zajrzeć do instrukcji i ustawić. Co też zrobiłem. Przecież bez sensu pytać o każdy drobiazg gdy zostały opisane wcześniej. Zastrzegłem, że chwilę może mi to zająć i sprawdziłem. Tak jak pisałem na zewnętrznym kwarcu działa i wszystko gra. Dla czego na wewnętrznym nie chce? Nie wiem, ale na tę chwilę nie będę kombinował

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

Też nie wiem co tam robi "lub", ale ja się tylko podpiąłem pod temat użytkownika aduill ze względu na podobieństwo. Nie chciałem od razu tworzyć nowego tematu, skoro ten pasował.

W Bluebooku masz pięknie opisane dlaczego może (ma prawo nie działać na wewn. oscylatorze) ... po to właśnie jest ćwiczenie z OSCCAL aby go w razie czego dostroić - i warto jednak to ćwiczenie przejść żeby zrozumieć - a teraz powinno ci być już łatwiej skoro widzisz - że wszystko po kolei ładnie działa

Moim zdaniem powinno ruszyć na wewn oscylatorze 8 MHz w ATmega644PA ... ale to i tak oczywiście do testów i sprawdzenia bardziej niż do docelowych układó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 ]