Witam.

Mam 'niewielki' problem ze zbudowanym układem. Próbuję sterować LEDem przy pomocy ATB-BTM-222 i ATmega8.

Wariant 1: Z telefonu komórkowego wysyłam przez BT cyfy 1 lub 2. W zależności od tego co odbierze ATB-BTM-222 uC miga diodą w różny sposób. Całość działa jak należy.
Kod:


Teraz druga wersja, próbuję osiągnąć to samo poprzez wysyłanie znaków (a, b, c itd). I o dziwo tutaj nie działa jak należy.
Kod:


Pytanie brzmi o co tu chodzi? Kiedy wysyłam znaki '1', '2' wszystko działa, ale kiedy zamienię je na litery 'a', 'b' cały kod zachowuje się dziwnie. Mianowicie niezależnie od tego czy wyślę cały czas wykonuje się warunek else. Zauważyłem, że układ reaguje na warunki if(d==62) i if(d==63), tj. wykonują się przy wysłaniu znaku 'a' ('b' nadal nic). Początkowo myślałem, że to problem z prędkościami transmisji, ale wtedy zapewne nie działałoby w obu wypadkach.
Sprawdzałem w terminalu, czy aby wysyłam dobre znaki - ATB-BTM-222 odbiera dobre znaki, więc to chyba jednak nie kłopot z prędkością (wszystkie ustawione na 19200, zarówno w ATB-BTM-222 jak i w ATmega8).

Pozdrawiam.

Sytuacja doprawdy dziwna, ale liczba 62 nie odpowiada znakowi 'a' (97 dec, 61 hex). Znak 'b' (98 dec, 62 hex) to również nie jest 63...

Oczekiwanie pętlą while na ustawienie flagi RXC jest zupełnie pozbawione sensu - przecież to działanie realizuje przerwanie
Dodatkowo mała uwaga: skoro zmienna "d" nie jest używana poza procedurą przerwania to nie warto ją umieszczać w obszarze zmiennych globalnych, a dodatkowo ze specyfikatorem volatile. Wystarczy ograniczyć jej zasięg do procedury przerwaniowej.

Może jest to prozaiczny błąd i aplikacja na telefon reaguje na wielkie litery, albo ma odmienne kodowanie znaków

proponowałbym autorowi wątku jak najszybciej obejrzeć to:

http://mirekk36.blogspot.com/2014/06/ja ... ascii.html

wiele się rozjaśni .... bo te if( d==62 czy 63 w odniesieniu do opisu ma się jak pięść do oka - co pokazuje zresztą wyżej słusznie kolega atmel.

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

@atmel
No właśnie w tym cały sęk, z komórki wysyłam powiedzmy to nieszczęsne 'a', czyli dec 97, a uC reaguje na warunek typu if(d==63). Aplikacja na telefon na 100% wysyła dobrze, co z resztą widać na terminalu. Dla pewności wyświetlałem w telefonie kod ASCII znaku, który wysyłam, wszystko się zgadza.
Co do kodu: pętla while może rzeczywiście była głupim pomysłem, ale w wielu przykładach w sieci można znaleźć taki kod, próbowałem wszystkich metod. Zmienna d będzie lokalna, zrobiłem ją globalną dla testów na zasadzie "a może tak zadziała" .


@mirekk36
Warunek if(d==63) sprawdza czy dostałem znak o kodzie ASCII 63 (jeśli się mylę to mnie popraw), nie miałem tu zamiaru sprawdzać czy dostałem liczbę 63 . W tym cała "dziwota" sytuacji, z komórki wychodzi znak o kodzie ASCII dec 97, na terminalu wyświetla dec 97, a uC reaguje na warunek dla znaku dec 63...
Co do poradnika to obejrzałem, ale nie znalazłem tam rozwiązania.

Może niefortunnie się wyraziłem - taka pętla może mieć zastosowanie w prostym przypadku pomijania pierwszego bajtu i oczekiwania na drugi, dlatego takie przykłady można znaleźć w internecie, ale jest to zdecydowanie niepoprawny sposób zapisu i może służyć jedynie do początkowych testów. Skoro jest uaktywnione przerwanie to nie widzę sensu na takie bierne oczekiwanie, skoro można takie działanie zrealizować w oparciu o to przerwanie...

Wracając do Twojego problemu, sytuacja wydaje się doprawdy niesamowita, ponieważ z kodu wynika że wszystko powinno być w porządku. Może spróbuj połączyć mikrokontroler z jakąś przejściówką UART<->USB zamiast telefonu, ale skoro piszesz że terminal wyświetla dane prawidłowo to pewnie trochę bezsensu...

Może w drugą stronę tzn. niech procesor wyśle te problematyczne znaki ('a' i 'b') do telefonu, który je wyświetli, wtedy okaże się, czy prędkości transmisji są zgodne.

To oznacza tylko jedno - robisz gdzieś po drodze coś bardzo mega dziwnego .... albo innymi słowami tzw "czeski błąd" ... To może być nawet niedopasowanie prędkości uart, no ale inne maga kwiatki w twoim programie to chociażby pętla oczekująca w przerwaniu ! masakra

Ja bym ci polecił - najpierw pobawić się terminalem w PC i komunikacją z prockiem. Sprawdzałeś taki wariant ?

------------------------ [ Dodano po: 5 minutach ]



Oczywiście że rozumiem że ten warunek sprawdza czy nadlatuje kod znaku 63 co oczywiście jest tożsame ze sprawdzaniem liczby 63

ale mi chodziło o to że nie ma takiej opcji - żebyś wysyłał z telefonu kod znaku 'b' a przy tym otrzymywał do procka kod jakiegoś innego znaku

widać że błądzisz i zamiast dopasowywać sobie na czuja - jakieś inne kody znaków - to zła droga

- sprawdź sobie program na komórce - co on wysyła i przy jakich parametrach

a jeśli w PC w terminalu otrzymujesz właściwy kod znaku na terminalu czyli 'b' to znaczy .... że w procku robisz babola - taki przyjmij algorytm myślenia - zamiast podstawiania do IF() innych dziwnych kodó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 ]

Poszedłem za radą kolegi atmel i sprawdziłem w drugą stronę, tj. co odbiera telefon kiedy uC próbuje coś nadać. Próbując wysłać znak 'x' odbieram na telefonie jakiś krzak. Rozumiem, że to wina niedopasowania prędkości, tylko gdzie w takim razie tkwi błąd? Prędkość transmisji uC, ATB-BTM-222 i ustawienia portu COM dla terminala są takie same (wszędzie 19200, 8bitów, brak bitu parzystości i jeden bit stopu). I dlaczego w takim razie wysyłanie '1', '2' itp przebiega poprawnie, a 'a', 'b' już nie (czyżby przy niższych kodach ASCII dla cyfr komunikacja nie zdążyła się rozjechać)?

@mirekk36
Podpiąłem uC pod terminal przy ustawionych (teoretycznie) tych samych prędkościach transmisji. Działa dla '1', '2', nie działa dla znaków ('a', 'b'), próbując wysłać cokolwiek z uC na terminal dostaję krzaki. Tylko nie mam bladego pojęcia gdzie popełniłem błąd, prędkości ustawiam takie same, format wysyłanych danych również jest taki sam . Sprawdzałem dla różnych typowych prędkości (19200, 9600) i w żadnym wypadku nie działało poprawnie.

Przede wszystkim zapoznaj się z tym: http://mirekk36.blogspot.com/2013/01/rs232-ubrr-jak-prawidowo-obliczac-trick.html

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Zapoznałem się, próbowałem już stosować inne wzory do obliczania UBRR, próbowałem też podstawiać na sztywno wartości z tabeli z datasheet ATmega8 (w moim wypadku chyba dec 25 o ile mnie pamięć nie myli). Niestety bez rezultatów.

Dokonałem pewnych zmian w ustawieniach USART, mianowicie ustawiam tylko rejestry:



Podpiąłem się terminalem pod uC na krzyż (Rx do Tx i na odwrót), a w przerwaniu odpowiadającym za odbiór danych nadaję to co dostałem z terminala/komórki. Co ciekawe dla znaków 'a', 'b' program zwraca wszystko poprawnie (otrzymuję to samo co dostałem), problem natomiast występuje teraz z cyframi, przy wysyłaniu '1', '2' dostaję w terminalu krzaki... Dodatkowo pomimo tego, że uC otrzymuje (i zwraca) znaki 'a' i 'b' to warunek if(d=='a') nie wykonuje się. Zaczynam już powoli kombinować na chybił trafił, nic sensownego nie przychodzi mi już do głowy .

Dodatkowo wychodzi na to, że niezależnie od tego którą literę alfabetu wyślę (dużą czy małą) nadal wykrywa ją jako znak o kodzie 63.

@EDIT:
Problem rozwiązany, tkwił w złych ustawieniach rejestrów. Gdyby ktoś miał kiedyś podobny problem powinno to wyglądać tak:



Tym oto sposobem otrzymamy USART pracujący dla 8bitów danych, 1 bitu stopu i zeru bitów parzystości. Prędkość 19200 dla taktowania 8MHz.

Dziękuję za udzieloną pomoc, pozdrawiam.

widzisz - wystarczyło rzucić okiem do książki ....

http://atnel.pl/mikrokontrolery-avr-jezyk-c.html

przeczytać rozdział o UART i nie miałbyś tych problemó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 ]