W dniu 2012-12-31 17:57, Marek pisze:
> 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.
Tu nie chodzi o dokłądność oscylatora. Chodzi o to, że do taktowania
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
| 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

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

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

do góry

On Mon, 31 Dec 2012 18:13:58 +0100, BartekK <s...@d...org> wrote:
> Tu nie chodzi o dokłądność oscylatora. Chodzi o to, że do
taktowania
> UARTu musisz ustawić dzielnik (a w zasadzie wartość startową
licznika).

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

do góry

Użytkownik "Jakub Rakus" <s...@o...pl> napisał w wiadomości
news:kbq6kf$6nh$1@node2.news.atman.pl...
> 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?

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

do góry

On 2012-12-31 18:00, Jakub Rakus wrote:
> 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.

a) nie zapomniales o masie ?

b) wina softu. robisz przerwania czy w petli?

do góry

no to spróbuj wstawić generator zamiast kwarcu i sprawdź...

do góry

W dniu 2012-12-31 18:49, Marek pisze:
> On Mon, 31 Dec 2012 18:13:58 +0100, BartekK <s...@d...org> wrote:
>> Tu nie chodzi o dokłądność oscylatora. Chodzi o to, że do
> taktowania
>> UARTu musisz ustawić dzielnik (a w zasadzie wartość startową
> licznika).
>
> 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.
Dla dowolnych? Niestety, ale nie. Dowolna to od 0 do np 16MHz, ale
dzielnik (licznik) da się tylko dla niektórych par (prędkość bps,kwarc)
dobrać idealnie, dla niektórych w granicach błędu, a dla niektórych nie
da się.


> Czy nie wystarczy użyć kwarcu na częstotliwość taka dla jakiej
> znajdziemy odpowiedni dzielnik dla bgr dla oczekiwanej prędkości usarta?
Tak, oczywiście, są kwarce które dają prawie całkowite pokrycie
wszystkich prędkości. Popatrz w tabelki na stronie:
http://www.wormfood.net/avrbaudcalc.php
dla 3.6864 Mhz - masz wszystkie prędkości (poza 300 i 600bps) z idealnym
bps (0% odchyłki)
dla 7.3728 Mhz - to samo, ale odpadają najwolniejsze 300,600 i 1200
dla 11.0592 Mhz - to samo, poza 300,600,1200 i 2400bps
itp.
A dla kwarców równych liczbowo, np 8MHz, jak się ktoś uprze je
zastosować, to też może sobie znaleźć taką prędkość usartu, by to
działało prawidłowo (by rozjazd był poniże 1%) - np dla tego naszego z
wątku 8MHZ (oraz 8MHz z wewnętrznego oscylatora, gdy kwarcu nie ma) -
bez problemu chodzi na 2400-19200bps oraz na 38400bps, 28800 i 57600 to
loteria (>2%błędu), a reszta odpada.


--
| 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 01.01.2013 13:43, Sebastian Biały pisze:

> a) nie zapomniales o masie ?

Nie. Masy są połączone.

> b) wina softu. robisz przerwania czy w petli?

Całość mam napisane w Bascomie. Program działa tak, że wysyłam z mcu
jeden bajt (komenda żądania konkretnych danych), a następnie
kilkadziesiąt razy powtarza się sekwencja: wysłanie bajtu o wartości FF
na co urządzenie odpowiada mi kolejnym pojedynczym bajtem danych. Całość
wykonuje się w pętli umieszczonej w pętli głównej programu.
W tzw. międzyczasie mcu obsługuje dwa kanały ADC (obsługa w przerwaniu
timer0) i zespół wyświetlaczy 7seg (obsługa w przerwaniu timer1 - zespół
ma swoją "logikę" i wysyła się mu liczbę do wyświetlenia, numer
wyświetlacza, a potem zatrzaskuje).
Na czas wysyłania uart-em bajtu FF i odbioru bajtu profilaktycznie
wyłączam przerwania, ale zauważyłem że nie ma to wpływu na komunikację.

--
Pozdrawiam
Jakub Rakus

do góry

On 2013-01-01 18:48, Jakub Rakus wrote:
> Całość mam napisane w Bascomie. Program działa tak, że wysyłam z mcu
> jeden bajt (komenda żądania konkretnych danych), a następnie
> kilkadziesiąt razy powtarza się sekwencja: wysłanie bajtu o wartości FF
> na co urządzenie odpowiada mi kolejnym pojedynczym bajtem danych. Całość
> wykonuje się w pętli umieszczonej w pętli głównej programu.
> W tzw. międzyczasie mcu obsługuje dwa kanały ADC (obsługa w przerwaniu
> timer0) i zespół wyświetlaczy 7seg (obsługa w przerwaniu timer1 - zespół
> ma swoją "logikę" i wysyła się mu liczbę do wyświetlenia, numer
> wyświetlacza, a potem zatrzaskuje).

Jak sprawdzasz podczas wyslania, ze wolno już zapisac nowe dane do UDR?
Czekasz na odbiór i wtedy wysylasz ? Morze podziel sie petla komunikacyjna.

Jak na jakosc wplynie wstawienie opoznienia podczas wysylania pomiedzy
znakami?

Podczas odczytu sprawdz bity Frame Error i Data OverRun i wystaw na
jakies ledy w celu upewnienia sie czy to wina hard czy software.

do góry

On Tue, 01 Jan 2013 18:27:15 +0100, BartekK <s...@d...org> wrote:
> Dla dowolnych? Niestety, ale nie. Dowolna to od 0 do np 16MHz, ale
> dzielnik (licznik) da się tylko dla niektórych par (prędkość
bps,kwarc)
> dobrać idealnie, dla niektórych w granicach błędu, a dla niektórych
nie
> da się.

Oczywiście ze nie dla dowolnych, po prostu nie rozumiem czemu po
prostu nie użyć kwarcu dla którego uzyska sie oczekiwana prędkość
usarta z jak najmniejsza stopa błędów.

--
Marek

do góry