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-8) 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

do góry

On 2012-12-30 21:02, Jakub Rakus wrote:
> 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.

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.

do góry

W dniu 2012-12-30 21:02, Jakub Rakus pisze:
> 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-8) 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?


Zamienić 8MHz na 11.059MHz.

Pozdrawiam,
Paweł

do góry

W dniu 2012-12-30 21:02, Jakub Rakus pisze:
> 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-8) 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
Oczywiście. Przy tym kwarcu i tej prędkości - nie jesteś w stanie
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
| s...@d...org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338
173

do góry

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

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

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

do góry

Jakub Rakus <s...@o...pl> napisał(a):
> 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.

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

do góry

On Sun, 30 Dec 2012 21:12:55 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> 8.5% / 3.5% błędu przy tej prędkości i kwarcu 8MHz, czyli najwyższy

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

do góry

W dniu 31.12.2012 14:11, Marek pisze:

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

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

do góry

On Mon, 31 Dec 2012 17:32:05 +0100, Jakub Rakus <s...@o...pl>
wrote:
> 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.

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

do góry

W dniu 30.12.2012 21:30, Grzegorz Niemirowski pisze:

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

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

do góry