Witam serdecznie wszystkich forumowiczów;
Mam pewien problem w komunikacji poprzez USART. Kłopot wygląda następująco:
Napisałem program wykorzystując pliki kolegi Mirka (mkuart.c, mkuart.h, mk_term.c, i mk_therm.h).
Jedyne zmiany jakich dokonałem to modyfikacja funkcji inicjalizacji która wygląda następująco :



Po wgraniu programu do uC przystąpiłem do testów komunikacji.
Test 1:
uC(Atmega169A) podłączony do komputera przez kabel. Dane odebrane na terminalu prawidłowe.

Test 2:
uC(Atmega169A) podłączony do modułu HC-05 sparowanym z telefonem. Dane odbierane przez telefon nieprawidłowe. (krzaczki)

Pomyślałem że może z modułem HC-05 coś nie tak. Więc przeprowadziłem kolejne sprawdzenie.
Test 3:
uC(Atmega32A) podłączony do modułu HC-05 sparowanym z telefonem. Dane odbierane przez telefon prawidłowe.

Wnioski jakie wyciągam z tych testów są następujące :
1.Atmega169A sprawny i zaprogramowany prawidłowo.
2.Moduł HC-05 sprawny.
Powyższe wnioski doprowadzają do paradoksu w którym wszystko jest ok a jednocześnie nic nie działa.

Czy jest ktoś w stanie mi podpowiedzieć co robię nie tak ??

Nie napisałeś nic na jakiej prędkości to testowałeś i czy ustawienie tej prędkości wprowadzałeś również w module HC-05 - mi to wygląda na niezgodność prędkości UART procka i modułu HC-05 (przy testach atmega168 vs HC-05)

Oba procki ustawione na 9600. Więc niezgodność prędkość chyba odpada.

Wysłane z mojego WAS-LX1 przy użyciu Tapatalka

Witam;
Zainteresowanie tym problemem nie jest wielkie . Ale dla tych którzy tu trafią napiszę że problem został zażegnany.
Co prawda doprowadził do tego przypadek ale już wszystko jest ok.
A było to tak:
Nad projektem zostały odprawione najróżniejsze tortury, a ostatnie z nich polegały na ustawianiu w procesorze różnych prędkości transmisji. Wpisywałem wszystkie standardowe wartości i żadne z ustawień nie pomagało więc postanowiłem wrócić do pierwotnego baudrate, czyli 9600. Niestety pomyliłem się przy wpisywaniu i zamiast 9600 wpisałem 9200. Nie widząc tej pomyłki program skompilowałem i zaprogramowałem procek. I dostałem szoku bo komunikacja ruszyła i pracuje bez żadnych komplikacji.

W związku z rozwiązaniem się problemu temat uważam za zamknięty.

Pozdrawiam wszystkich.

Zmierz szerokość najkrotszego impulsu i oblicz prędkość, którą fizycznie masz na porcie komunikacyjnym. Obstawiam, że bedzie 9600 a nie 9200.

Jak działa Ci na innej ustawionej prędkości to masz albo inaczej taktowany procesor niż Ci się wydaje albo masz coś nie tak w ustawianiu rejestrów UBRRH i UBRRL.

--
Pozdrawiam,
Robert

Dajmy koledze samemu rozwiązać problem i dojść do pewnych wniosków. A może bawił się OSCALem? Albo korzysta z generatora RC?

Reakcja moja i micky'ego spowodowana jest tym, że to co według kiniola jest rozwiązaniem, to nie jest to prawidłowe rozwiązanie, tylko jakieś na chybił trafił zmiany byle by teraz zadziałało.
A jego słowanie sugerują że ma zamiar dalej wyjaśniać. Więc go próbujemy lekko zmobilizować .

--
Pozdrawiam,
Robert

Cześć panowie;
Fakt, takie rozwiązanie to nie rozwiązanie...

Procesor korzysta z wewnętrznego oscylatora 8MHz we "fusach" wyłączony podział przez 8 więc taktowanie procka teoretycznie 8Mhz.
I teraz nasuwa mi się pytanie:
Czy wewnętrzny oscylator może być na tyle źle fabrycznie skalibrowany żeby doprowadził do takiej sytuacji ?

Podłącz analizator stanów logicznych i sobie pomierz. Poczytaj w PDFie procka nt generatora RC. Dlatego pisałem o OSCALu. Ogólnie to wewnętrzny generator kiepsko się nadaje do zależnych czasowo procedur lub komunikacji bo to mocno zależy od...

P.s. Mirek na warsztatach z YB omawiał bardzo ciekawy sposób wykorzystania analizatora logicznego.

Cześć panowie;
Poszedłem za radą micky'ego, podłączyłem analizator i wyszło że mimo ustawienia w procku prędkości 9200 to na uarcie jest około 9600.
W związku z powyższym wynikiem skalibrowałem oscylator i teraz jest wszystko ok.

I teraz skoro wszystko już się wyjaśniło to z czystym sumieniem mogę uznać że temat się wyczerpał.


Dziękuję wszystkim za udział w dyskusji i pozdrawiam serdecznie.

A nie mówiłem? Cieszę się, że odrobiłeś zadanie domowe, bo dzięki temu zdobyłeś bardzo pożyteczne doświadczenie.

Ale może na przyszłość warto w takich projektach użyć zewnętrzny kwarc? I to taki, który jest "UART friendly" (czy jak to się nazywa)? Wtedy masz zminimalizowane błędy przesyłu danych

I teraz możemy Ci pogratulować dojścia do poprawnego rozwiązania problemu i pozwolić już zakończyć ten temat

--
Pozdrawiam,
Robert