Desynchronizacja w komunikacji UART Atmega8 przy odbiorze pakietów 64-bajtowych

Sun Dec 30, 2012 9:02 pm   

Witam,

Taki oto problem się urodził:
Atmega8, taktowana kwarcem 8MHz, wykorzystany sprzętowy uart do
komunikacji z innym urządzeniem, również z komputerem przez rs232.
Transmisja 115200, 8, N, 1. Wszystko działa gdy wysyłam/odbieram kilka
(około 6- bajtów, przy większych ilościach (np. mam do odebrania przez
atmegę ciąg 64-bajtowy) pojawiają się bzdury - jakieś 20-30 pierwszych
bajtów jest poprawne, potem pojawiają się przekłamania, a kolejne takie
"pakiety" są tylko coraz gorsze.
Wygląda to tak, jakby w trakcie transmisji następowała jakaś
desynchronizacja, tylko nie wiem co zrobić z tym fantem. Linie tx/rx
skrócone do minimum (teraz to są przewody na płytce prototypowej o dł.
2cm każdy). Gdy miałem przez chwilę oscyloskop podglądałem przebiegi -
wygląda bardzo ładnie, bez żadnych zakłóceń, czasy prawidłowe, ładne
"ostre" prostokąty. Kombinować z rejestrem OSCCAL?

--
Pozdrawiam
Jakub Rakus

Sun Dec 30, 2012 9:12 pm   

On 2012-12-30 21:02, Jakub Rakus wrote:

8.5% / 3.5% błędu przy tej prędkości i kwarcu 8MHz, czyli najwyższy
możliwy jaki się tylko dało przy tej prędkości .

Higher error ratings are acceptable, but the Receiver will have less
noise resistance when
the error ratings are high, especially for large serial frames

Zerknij sobie w tabelki 53 i 54 w pdfie:

http://www.atmel.com/images/doc2486.pdf

Być może powinieneś zacząć od zmiany kwarcu na jakiś uartowy żeby
wyeliminować ten problem.

Sun Dec 30, 2012 9:14 pm   

W dniu 2012-12-30 21:02, Jakub Rakus pisze:


Zamienić 8MHz na 11.059MHz.

Pozdrawiam,
Paweł

Sun Dec 30, 2012 9:24 pm   

W dniu 2012-12-30 21:02, Jakub Rakus pisze:

ustawić prawidłowo timera taktującego uart, tak by w prędkość się
idealnie wstrzelić - błąd jest na tyle spory, że po kilkunastu bajtach
kolejne już nie trafiają w swoje "okna czasowe" i się rozjeżdża treść.

Zmień kwarc lub prędkość transmisji, tu masz ładną ściągę:
http://www.wormfood.net/avrbaudcalc.php

--
| Bartłomiej Kuźniewski
| sibi@drut.org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173

Sun Dec 30, 2012 9:24 pm   

W dniu 30.12.2012 21:12, Sebastian Biały pisze:


Oooo, wstyd, patrzyłem na te tabelki, wydawało mi się że te kilka
procent to nie powinno robić takiego syfu, ale tego zdania o długich
ramkach jakoś nie doczytałem. To może dużo wyjaśniać, jak dorwę jutro
jakiś bardziej odpowiedni kwarc to obadam.

--
Pozdrawiam
Jakub Rakus

Sun Dec 30, 2012 9:30 pm   

Jakub Rakus <szczur01@op.pl> napisał(a):

Pamiętaj, że pod względem wielkości błędu lepszy kwarc to nie kwarc szybszy,
tylko ten, którego częstotliwość ładnie dzieli się przez prędkość
transmisji. Dlatego bardzo lubię kwarce 3686400 Hz.


--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 1 day, 8 hours, 39 minutes and 24 seconds

Mon Dec 31, 2012 2:11 pm   

On Sun, 30 Dec 2012 21:12:55 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

Nigdy z atmega nic nie robilem, tylko PIC, ale nie da się w atmedze
używać usarta z wew. oscylatorem? To ma być jakieś zegarek, że kwarc
wymagany?
Dla niektórych to co teraz powiem to herezja, ale ja z picami nigdy
kwarca nie używałem, a większość urządzeń jakie robilem komunikuja
się że sobą przez usart (inny mcu, PC, moduly gsm, mcu z usb na wew.
osc.) i nigdy żadnych problemow (przekłamań) komunikacyjnych nie
miałem. Ba, nawet kiedys popełniłem moduł komfortu na CANie do
samochodu kolegi, zaprojektowany owszem z kwarcem, ale rok temu
potajemnie koledze wyłączylem kwarc w module przełączając mcu na wew.
oscylator, tak z ciekawości czy będzie coś się działo. I nic, rok już
jeździ z tym modulem i żadnych problemow nie zauważył (i zima przy
-20 i latem przy 30) więc, po co komu kwarc?
Nie wierzę, że ten problem z usartem związany jest z kwarcem, no
chyba ze wlasnie problem w tym, że zostal użyty;).

A tak ja poważnie, to chętnie bym się przyjrzał dyskusji na temat
zasadnosci stosowania kwarca w projektach
hobistyczno-polprofesjonalnych.
Nawet sam Microchip w serii J np.18f25j50 podpial wew. oscylator do
taktowania USB jako jedna z opcji (poprzednie wersje 2550 wymagały
kwarca, jeśli chciało się użyć usb bo wew. oscylator nie mógł
taktowac usb), więc można. I faktycznie w J działa usb bez problemu
na wew. osc.

--
Marek

Mon Dec 31, 2012 5:32 pm   

W dniu 31.12.2012 14:11, Marek pisze:


Tylko z tego co kojarzę układ "przygotowania" i rozprowadzania sygnału
zegarowego w PICkach jest trochę inny od tego w AVR - IMHO
pewniejszy, dokładniejszy i bardziej "elastyczny" dla użytkownika.

--
Pozdrawiam
Jakub Rakus

Mon Dec 31, 2012 5:57 pm   

On Mon, 31 Dec 2012 17:32:05 +0100, Jakub Rakus <szczur01@op.pl>
wrote:

W datasheetach PICkow w większości przypadków (nie kojarzę w tej
chwili innych wartości) podawane jest dokładność wew. oscylatora 1%.
Ale jestem zdziwiony, że atmega różni się "technologicznie", dotąd i
atmegi i picki traktowałem jako konkurencyjne procesory: oba tak samo
dobre.

--
Marek

Mon Dec 31, 2012 6:00 pm   

W dniu 30.12.2012 21:30, Grzegorz Niemirowski pisze:


Wypróbowałem dzisiaj kwarce 11,0592 i 14,7456. Z tym 11,0592 jest
tragicznie, prawie same błędy. Przy 14,7456 jest tak samo jak było do
tej pory, pierwsze kilkanaście bajtów jest w porządku, potem się
wszystko rozjeżdża.

--
Pozdrawiam
Jakub Rakus

Mon Dec 31, 2012 6:13 pm   

W dniu 2012-12-31 17:57, Marek pisze:

UARTu musisz ustawić dzielnik (a w zasadzie wartość startową licznika).
Ustawić do jego rejestru możesz wszystko z zakresu 0-255, i dla
niektórych ustawień - nijak nie wychodzi równy podział, bo np wpis 4 = o
wiele za szybko, a wpis 5 - już znacznie za wolno...


--
| Bartłomiej Kuźniewski
| sibi@drut.org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173

Mon Dec 31, 2012 6:43 pm   

Jakub Rakus <szczur01@op.pl> napisał(a):

Więc to nie jest wina kwarca. Sprawdź fusebity, czy ta ATmega z tego kwarca
w ogóle korzysta. Pokaż też kod odpowiedzialny a UART. Albo go źle
inicjalizujesz albo źle obsługujesz nadchodzące dane, np. przepełnia Ci się
bufor.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 3 hours, 50 minutes and 59 seconds

Mon Dec 31, 2012 6:49 pm   

On Mon, 31 Dec 2012 18:13:58 +0100, BartekK <sibi@drut.org> wrote:


Ale przecież bgr ze swoimi dzielnikami musi umożliwić prawidłowa
częstotliwość taktowania dla częstotliwości dla jakich mcu został
zaprojektowany lub częstości zalecanych. Czy nie wystarczy użyć
kwarcu na częstotliwość taka dla jakiej znajdziemy odpowiedni
dzielnik dla bgr dla oczekiwanej prędkości usarta?

--
Marek

Tue Jan 01, 2013 11:10 am   

Użytkownik "Jakub Rakus" <szczur01@op.pl> napisał w wiadomości
news:kbq6kf$6nh$1@node2.news.atman.pl...

Oprócz wymiany kwarca na taki, którego częstotliwość dzieli się łatwo przez
115200Hz, spróbuj wysyłać bajty z dwoma bitami stopu zamiast jednym. To
pozwoli odbiornikowi łatwiej złapać synchronizację (odbiornik jak
najbardziej może mieć ustawiony 1 bit stopu dla odbioru). Pamiętaj też o tym
że wybraleś dość szybką transmisję i kolejny bajt pojawia się co około 87us,
więc może procedury "nie wyrabiają".

Tue Jan 01, 2013 1:43 pm   

On 2012-12-31 18:00, Jakub Rakus wrote:

a) nie zapomniales o masie ?

b) wina softu. robisz przerwania czy w petli?