ATNEL tech-forum

Re: Atmega169A USART

2018-01-27T17:33:08+01:00

kiniol napisał(a):

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

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

--
Pozdrawiam,
Robert

Statystyki: Napisane przez rskup — 27 sty 2018, o 17:33

Re: Atmega169A USART

2018-01-25T16:57:58+01:00

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

Statystyki: Napisane przez Marhef — 25 sty 2018, o 16:57

Re: Atmega169A USART

2018-01-24T22:20:54+01:00

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

Statystyki: Napisane przez micky — 24 sty 2018, o 22:20

Re: Atmega169A USART

2018-01-24T19:40:10+01:00

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.

Statystyki: Napisane przez kiniol — 24 sty 2018, o 19:40

Re: Atmega169A USART

2018-01-20T09:29:55+01:00

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.

Statystyki: Napisane przez micky — 20 sty 2018, o 09:29

Re: Atmega169A USART

2018-01-20T09:12:38+01:00

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 ?

Statystyki: Napisane przez kiniol — 20 sty 2018, o 09:12

Re: Atmega169A USART

2018-01-19T15:31:14+01:00

micky napisał(a):

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łowa

kiniol napisał(a):

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

nie sugerują że ma zamiar dalej wyjaśniać. Więc go próbujemy lekko zmobilizować .

--
Pozdrawiam,
Robert

Statystyki: Napisane przez rskup — 19 sty 2018, o 15:31

Re: Atmega169A USART

2018-01-19T15:27:21+01:00

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

Statystyki: Napisane przez micky — 19 sty 2018, o 15:27

Re: Atmega169A USART

2018-01-19T14:01:48+01:00

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

Statystyki: Napisane przez rskup — 19 sty 2018, o 14:01

Re: Atmega169A USART

2018-01-19T11:11:05+01:00

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

Statystyki: Napisane przez micky — 19 sty 2018, o 11:11

Re: Atmega169A USART

2018-01-19T10:02:03+01:00

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.

Statystyki: Napisane przez kiniol — 19 sty 2018, o 10:02

Re: Atmega169A USART

2018-01-06T21:26:50+01:00

xentis napisał(a):

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

Statystyki: Napisane przez kiniol — 6 sty 2018, o 21:26

Re: Atmega169A USART

2018-01-06T13:43:54+01:00

Statystyki: Napisane przez xentis — 6 sty 2018, o 13:43

Atmega169A USART

2018-01-06T11:52:47+01:00

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 :

[syntax=c]void USART_Init( uint16_t baud ) {
/* Ustawienie prędkości */
UBRRH = (uint8_t)(baud>>8);
UBRRL = (uint8_t)baud;
/* Załączenie nadajnika I odbiornika */
UCSRB = ((1</* Ustawienie format ramki: 8bitów danych, 1 bit stopu */
UCSRC = ((1<// jeśli korzystamy z interefejsu RS485
#ifdef UART_DE_PORT
// inicjalizujemy linię sterującą nadajnikiem
UART_DE_DIR |= UART_DE_BIT;
UART_DE_ODBIERANIE;
#endif

// jeśli korzystamy z interefejsu RS485
#ifdef UART_DE_PORT
// jeśli korzystamy z interefejsu RS485 załączamy dodatkowe przerwanie TXCIE
UCSRB |= (1<#else
// jeśli nie korzystamy z interefejsu RS485
UCSRB |= (1<#endif
}[/syntax]

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 ??

Statystyki: Napisane przez kiniol — 6 sty 2018, o 11:52