NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Desynchronizacja w komunikacji UART Atmega8 przy odbiorze pakietów 64-bajtowych
identyfikator: 20040501
Guest
Guest
Tue Jan 01, 2013 1:53 pm
no to spróbuj wstawić generator zamiast kwarcu i sprawdź...
BartekK
Guest
Guest
Tue Jan 01, 2013 6:27 pm
W dniu 2012-12-31 18:49, Marek pisze:
Quote:
On Mon, 31 Dec 2012 18:13:58 +0100, BartekK <sibi@drut.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
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ę.
Quote:
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
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
| sibi@drut.org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173
Jakub Rakus
Guest
Guest
Tue Jan 01, 2013 6:48 pm
W dniu 01.01.2013 13:43, Sebastian Biały pisze:
Quote:
a) nie zapomniales o masie ?
Nie. Masy są połączone.
Quote:
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
Sebastian BiaĹy
Guest
Guest
Tue Jan 01, 2013 7:02 pm
On 2013-01-01 18:48, Jakub Rakus wrote:
Quote:
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).
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.
Marek
Guest
Guest
Thu Jan 03, 2013 9:32 am
On Tue, 01 Jan 2013 18:27:15 +0100, BartekK <sibi@drut.org> wrote:
Quote:
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ę.
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
BartekK
Guest
Guest
Thu Jan 03, 2013 11:46 am
W dniu 2013-01-03 09:32, Marek pisze:
Quote:
On Tue, 01 Jan 2013 18:27:15 +0100, BartekK <sibi@drut.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.
Też nie rozumiem upartego stosowania np 8MHz, skoro 7.3728 da niewiele
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.
Też nie rozumiem upartego stosowania np 8MHz, skoro 7.3728 da niewiele
wolniejszego procka, i zero problemów z komunikacjami.
--
| 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
Mario
Guest
Guest
Thu Jan 03, 2013 1:33 pm
W dniu 2013-01-03 11:46, BartekK pisze:
Quote:
W dniu 2013-01-03 09:32, Marek pisze:
On Tue, 01 Jan 2013 18:27:15 +0100, BartekK <sibi@drut.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.
Też nie rozumiem upartego stosowania np 8MHz, skoro 7.3728 da niewiele
wolniejszego procka, i zero problemów z komunikacjami.
On Tue, 01 Jan 2013 18:27:15 +0100, BartekK <sibi@drut.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.
Też nie rozumiem upartego stosowania np 8MHz, skoro 7.3728 da niewiele
wolniejszego procka, i zero problemów z komunikacjami.
Może potrzebuje jakiejś okrągłej wartości przy przerwaniu z timera.
--
pozdrawiam
MD
Marek
Guest
Guest
Fri Jan 04, 2013 6:39 pm
On Thu, 03 Jan 2013 11:46:19 +0100, BartekK <sibi@drut.org> wrote:
Quote:
Też nie rozumiem upartego stosowania np 8MHz, skoro 7.3728 da
niewiele
wolniejszego procka, i zero problemów z komunikacjami.
niewiele
wolniejszego procka, i zero problemów z komunikacjami.
A kto broni użyć takiego kwarca? BTW ja nigdy nie miałem żadnych
problemow z usartem przy osc. wew 8Mhz w pickach (fosc 32/4), o
tabeli % stopy błędów w dokumentacji producenta przypomniałem sobie
podczas tej dyskusji, nigdy na to nie zwracałem uwagi, pewnie
dlatego, ze uznałem to za jedynie ciekawostkę przyrodnicza :-)
--
Marek
Grzegorz Niemirowski
Guest
Guest
Fri Jan 04, 2013 6:43 pm
Marek <fake@fakeemail.com> napisał(a):
Quote:
A kto broni użyć takiego kwarca? BTW ja nigdy nie miałem żadnych
problemow z usartem przy osc. wew 8Mhz w pickach (fosc 32/4), o tabeli %
stopy błędów w dokumentacji producenta przypomniałem sobie podczas tej
dyskusji, nigdy na to nie zwracałem uwagi, pewnie dlatego, ze uznałem to
za jedynie ciekawostkę przyrodnicza
problemow z usartem przy osc. wew 8Mhz w pickach (fosc 32/4), o tabeli %
stopy błędów w dokumentacji producenta przypomniałem sobie podczas tej
dyskusji, nigdy na to nie zwracałem uwagi, pewnie dlatego, ze uznałem to
za jedynie ciekawostkę przyrodnicza
Przy niższych prędkościach jest spoko, od 57600 bps pojawiają się schody.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 7 hours, 21 minutes and 49 seconds
Grzegorz Niemirowski
Guest
Guest
Fri Jan 04, 2013 6:46 pm
BartekK <sibi@drut.org> napisał(a):
Quote:
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...
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...
Uściślę tylko, że w np. ATmega8 dla szybkich kwarców i niskich prędkości
potrzebne są wartości powyżej 255 i wtedy oprócz rejestru UBRRL używa się
też UBRRH (tworzące razem 16-bitowy UBRR).
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 7 hours, 23 minutes and 15 seconds
Marek
Guest
Guest
Fri Jan 04, 2013 7:37 pm
On Fri, 4 Jan 2013 18:43:42 +0100, "Grzegorz Niemirowski"
<gnthexfiles@poczta.onet.pl> wrote:
Quote:
Przy niższych prędkościach jest spoko, od 57600 bps pojawiają się
schody.
schody.
Używam tylko 57600 (zadko) i 115200.
--
Marek
Grzegorz Niemirowski
Guest
Guest
Fri Jan 04, 2013 7:48 pm
Marek <fake@fakeemail.com> napisał(a):
Quote:
Używam tylko 57600 (zadko) i 115200.
Ja też, ale nie na kwarcu 8 MHz.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 8 hours, 26 minutes and 14 seconds
elektroda NewsGroups Forum Index - Elektronika Polska - Desynchronizacja w komunikacji UART Atmega8 przy odbiorze pakietów 64-bajtowych