Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
avr - uart działa, ale nie do końca
79 views
Skip to first unread message
Jakub Rakus
Dec 30, 2012, 3:02:22 PM12/30/12
to
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
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
Sebastian Biały
Dec 30, 2012, 3:12:55 PM12/30/12
to
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
> 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.
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.
Paweł Pawłowicz
Dec 30, 2012, 3:14:20 PM12/30/12
to
W dniu 2012-12-30 21:02, Jakub Rakus pisze:
Zamienić 8MHz na 11.059MHz.
Pozdrawiam,
Paweł
Pozdrawiam,
Paweł
BartekK
Dec 30, 2012, 3:24:34 PM12/30/12
to
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
> 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
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
| si...@drut.org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173
Jakub Rakus
Dec 30, 2012, 3:24:56 PM12/30/12
to
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
> Higher error ratings are acceptable, but the Receiver will have less
> noise resistance when
> the error ratings are high, especially for large serial frames
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
Grzegorz Niemirowski
Dec 30, 2012, 3:30:55 PM12/30/12
to
Jakub Rakus <szcz...@op.pl> napisał(a):
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
> 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,
> 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.
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
Marek
Dec 31, 2012, 8:11:53 AM12/31/12
to
On Sun, 30 Dec 2012 21:12:55 +0100, Sebastian
Biały<he...@poczta.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
Biały<he...@poczta.onet.pl> wrote:
> 8.5% / 3.5% błędu przy tej prędkości i kwarcu 8MHz, czyli najwyższy
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
Jakub Rakus
Dec 31, 2012, 11:32:05 AM12/31/12
to
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
> 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.
>
zegarowego w PICkach ;) jest trochę inny od tego w AVR - IMHO
pewniejszy, dokładniejszy i bardziej "elastyczny" dla użytkownika.
--
Pozdrawiam
Jakub Rakus
Marek
Dec 31, 2012, 11:57:15 AM12/31/12
to
On Mon, 31 Dec 2012 17:32:05 +0100, Jakub Rakus <szcz...@op.pl>
wrote:
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
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
sygnału
> zegarowego w PICkach ;) jest trochę inny od tego w AVR - IMHO
> pewniejszy, dokładniejszy i bardziej "elastyczny" dla użytkownika.
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
Jakub Rakus
Dec 31, 2012, 12:00:42 PM12/31/12
to
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
> 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.
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
BartekK
Dec 31, 2012, 12:13:58 PM12/31/12
to
W dniu 2012-12-31 17:57, Marek pisze:
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...
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...
Grzegorz Niemirowski
Dec 31, 2012, 12:43:27 PM12/31/12
to
Jakub Rakus <szcz...@op.pl> napisał(a):
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
> 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
> 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.
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/
Marek
Dec 31, 2012, 12:49:50 PM12/31/12
to
On Mon, 31 Dec 2012 18:13:58 +0100, BartekK <si...@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
> Tu nie chodzi o dokłądność oscylatora. Chodzi o to, że do
taktowania
> UARTu musisz ustawić dzielnik (a w zasadzie wartość startową
licznika).
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
As
Jan 1, 2013, 5:10:49 AM1/1/13
to
Użytkownik "Jakub Rakus" <szcz...@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ą".
news:kbq6kf$6nh$1...@node2.news.atman.pl...
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ą".
Sebastian Biały
Jan 1, 2013, 7:43:40 AM1/1/13
to
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 ?
> 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.
b) wina softu. robisz przerwania czy w petli?
identyfikator: 20040501
Jan 1, 2013, 7:53:28 AM1/1/13
to
no to spróbuj wstawić generator zamiast kwarcu i sprawdź...
BartekK
Jan 1, 2013, 12:27:15 PM1/1/13
to
W dniu 2012-12-31 18:49, Marek pisze:
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.
> On Mon, 31 Dec 2012 18:13:58 +0100, BartekK <si...@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.
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?
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.
Jakub Rakus
Jan 1, 2013, 12:48:24 PM1/1/13
to
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
> a) nie zapomniales o masie ?
> b) wina softu. robisz przerwania czy w petli?
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
Jan 1, 2013, 1:02:44 PM1/1/13
to
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?
> 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).
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
Jan 3, 2013, 3:32:24 AM1/3/13
to
On Tue, 01 Jan 2013 18:27:15 +0100, BartekK <si...@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
> 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ę.
prostu nie użyć kwarcu dla którego uzyska sie oczekiwana prędkość
usarta z jak najmniejsza stopa błędów.
--
Marek
BartekK
Jan 3, 2013, 5:46:19 AM1/3/13
to
W dniu 2013-01-03 09:32, Marek pisze:
Też nie rozumiem upartego stosowania np 8MHz, skoro 7.3728 da niewiele
wolniejszego procka, i zero problemów z komunikacjami.
wolniejszego procka, i zero problemów z komunikacjami.
Mario
Jan 3, 2013, 7:33:24 AM1/3/13
to
W dniu 2013-01-03 11:46, BartekK pisze:
--
pozdrawiam
MD
> W dniu 2013-01-03 09:32, Marek pisze:
>> On Tue, 01 Jan 2013 18:27:15 +0100, BartekK <si...@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.
>> On Tue, 01 Jan 2013 18:27:15 +0100, BartekK <si...@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.
>
--
pozdrawiam
MD
Marek
Jan 4, 2013, 12:39:41 PM1/4/13
to
On Thu, 03 Jan 2013 11:46:19 +0100, BartekK <si...@drut.org> wrote:
> Też nie rozumiem upartego stosowania np 8MHz, skoro 7.3728 da
niewiele
> wolniejszego procka, i zero problemów z komunikacjami.
A kto broni użyć takiego kwarca? BTW ja nigdy nie miałem żadnych
> Też nie rozumiem upartego stosowania np 8MHz, skoro 7.3728 da
niewiele
> wolniejszego procka, i zero problemów z komunikacjami.
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
Jan 4, 2013, 12:43:42 PM1/4/13
to
Marek <fa...@fakeemail.com> napisał(a):
--
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
> 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 :-)
Przy niższych prędkościach jest spoko, od 57600 bps pojawiają się schody.
> 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 :-)
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Grzegorz Niemirowski
Jan 4, 2013, 12:46:22 PM1/4/13
to
BartekK <si...@drut.org> napisał(a):
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
> 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...
Uściślę tylko, że w np. ATmega8 dla szybkich kwarców i niskich prędkości
> 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...
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/
Marek
Jan 4, 2013, 1:37:01 PM1/4/13
to
On Fri, 4 Jan 2013 18:43:42 +0100, "Grzegorz Niemirowski"
<gnthe...@poczta.onet.pl> wrote:
> Przy niższych prędkościach jest spoko, od 57600 bps pojawiają się
schody.
Używam tylko 57600 (zadko) i 115200.
<gnthe...@poczta.onet.pl> wrote:
> Przy niższych prędkościach jest spoko, od 57600 bps pojawiają się
schody.
--
Marek
Grzegorz Niemirowski
Jan 4, 2013, 1:48:10 PM1/4/13
to
Marek <fa...@fakeemail.com> napisał(a):
--
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
> 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/
0 new messages