Jak zwiększyć prędkość transmisji danych po RS232 z Atmega16 do 38400 baud?

Wed May 23, 2007 11:46 am   

Witam!

Stworzyłem rejestrator napięć na Atmega16 taktowanym zewnętrznym kwarcem
16MHz. Szybkość transmisji ustawiłem na 38400 baud, z względu na minimalny
błąd BAUD error w listingu pokompilacyjnym programu Bascom AVR.

Tak na oko 19200 baud to w przybliżeniu 1500 znaków na sekundę. Ponieważ za
jednym razem przesyłane są 32 znaki, więc taki ciąg dałoby się przesłać
spokojnie nawet 50 razy w ciągu sekundy. A ja mam prędkość nawet 38400 baud!

Tymczasem w praktyce maksymalny osiąg to... 5 razy w ciągu sekundy.


Aplikacja PC wysyła rozkaz TX do urządzenia, urządzenie odsyła zmierzone
wartości w postaci ciągu:

dana1:dana2:dana3:dana4:dana5:dana6:dana7:dana8

za pomocą Bascomowej instrukcji Print.

Maksymalna szybkość jaką udaje mi się osiągnąć przy Atega16 i kwarcu 16MHz
to około 5Hz. Aplikacja posiada suwak, którą mogę ustawić szybkość
pobierania danych z urządzenia. Urządzenie wysyła komendę TX w interwale
jaki ustawiam za pomocą suwaka, a następnie szybko odczytuje bufor RS232 i
przekazuje dane do zmiennych.

W aplikacji zrobiłem okienko logowania dzięki któremu mogę obserwować cały
odbierany string (dana1:dana2:dana3:dana4:dana5:dana6:dana7:dana8)

I widzę, że przy zwiększaniu szybkości powyżej 5Hz string urywa się po 4 czy
piątej danej.
Można to zobaczyć na filmie (ostatnie sekundy - w okienku logowania)

Film można pobrać spod adresu:
http://rapidshare.com/files/32895888/clip0010.avi.html

Widać - urządzenie nie zdążyło jeszcze wysłać wszystkich danych.

To jest przykładowy string wysłany od urządzenia do PC:

514:512:512:512:514:515:512:516

łącznie 32 znaki, wysłane za pomocą komendy print a dokładniej kodu:

Print Zmienna1 ;
Print ":" ;
Print Zmienna2 ;
Print ":" ;
Print Zmienna3 ;
Print ":" ;
Print Zmienna4 ;
Print ":" ;
Print Zmienna5 ;
Print ":" ;
Print Zmienna6 ;
Print ":" ;
Print Zmienna7 ;
Print ":" ;
Print Zmienna8 ;


Ot cały skomplikowany algorytm.

Najpierw urządzenie czeka na komendę (Input Komenda) a po odebraniu
właściwej komendy (słowa TX) wysyła printami 8 danych.

Dlaczego maksymalny osiąg do 5Hz, skoro z moich wstępnych obliczeń wynika,
że powinno być z 10 razy tyle?

Wed May 23, 2007 11:53 am   

Mariusz napisał(a):

Wiesz ze wysylasz co chwila do instrukcji print zmienna w postaci 16bit
(z tego co widac) i ona przez dzielenie przez 10tys, 1tys, 100, 10 robi
z tego string ascii ? Wiesz ze avr nie ma sprzetowego dzielenia i robi
to procedura dzielenia softowego, ktora w bascomie niewiadomojaka jest
(i troche wolna)?
Jesli mozesz - wysylaj nie binarnie tylko hex, konwersja jest duzo
szybsza i bez dzielenia.

--
| Bartlomiej Kuzniewski
| sibi@drut.org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173

Wed May 23, 2007 11:54 am   

On May 23, 12:46 pm, "Mariusz" <mariusz.ciszew...@student.pwr.wroc.pl>
wrote:


bo bascomowa komenda print nie wykonuje się w jednym cyklu.
ani prawdopodobnie w setce cykli.

--
Marek Lewandowski
ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl
my gallery: http://www.pbase.com/mareklew
my kind-of-a-blog: http://lockaphoto.stufftoread.com

Wed May 23, 2007 12:16 pm   

Użytkownik "Mariusz" <mariusz.ciszewski@student.pwr.wroc.pl> napisał w
wiadomości news:f31644$msb$1@atlantis.news.tpi.pl...

Czołem!
Wysyłasz ciągi ascii ("515") a chcesz jakieś binarki.
te dane jakiego sa typu ? word?, integer?

Zapakuj sobie dane do tablicy (te dwukropki też) i wysyłaj
_pojedyncze_bajty_ za pomocą Printbin.
Poskaldasz to sobie w komputerze Bedzie szybciej.


JJJK

Wed May 23, 2007 12:18 pm   

Użytkownik "BartekK" <sibi@NOSPAMdrut.org> napisał w wiadomości
news:f316lp$os1$1@atlantis.news.tpi.pl...

Wręcz duża wygoda.
Do wysylania bajtów sluży inne polecenie - printbin.

JJJK

Wed May 23, 2007 12:20 pm   

Użytkownik "Marek Lewandowski" <locust@poczta.onet.pl> napisał w wiadomości
news:1179917665.257745.202730@q75g2000hsh.googlegroups.com...

Podobnie w avr-gcc nie da się wysłać WORD'a w jednym cyklu ;)

JJJK

Wed May 23, 2007 12:40 pm   

On May 23, 1:20 pm, "Janusz" <janusz_ka...@poczta.onet.pl> wrote:


nie mieszaj młodemu w głowie. Jest drobna różnica między pchaniem
ASCII a gołych binarnych.

--
Marek Lewandowski
ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl
my gallery: http://www.pbase.com/mareklew
my kind-of-a-blog: http://lockaphoto.stufftoread.com

Wed May 23, 2007 12:54 pm   

On Wed, 23 May 2007 13:18:52 +0200, Janusz wrote:

Czasem wygoda, czasem podwojny klopot - przy wysylaniu i przy
odbiorze.

Ale rozumiem ze obstawiacie predkosc print w bascomie ?
Moze by to sprawdzic ?

J.

Wed May 23, 2007 3:11 pm   

Tu problemem jest chyba INPUT!!!
Przy tej komendzie cały program staje i czeka na enter lub timeout. Ja
wykorzystywałem uart na 8051 i nie zauważyłem żadnych problemów choć ja
korzystałem z przerwań.

PC

Wed May 23, 2007 3:30 pm   

Mariusz napisał(a):

A program na PC sam pisałeś (windows/linux?). Bo zdaje się "źle"
napisany program (sterownik usarta) dodaje spore opóźnienia na drodze
aplikacja-windows-usart. Dawno temu zrobiłem sobie programator do '51
Atmela i napisałem do niego program w Delphi. Miałem ten sam problem,
koszmarnie długo trwała transmisja. Niestety programista ze mnie kiepski
i nie udało mi się tego przyspieszyć. Pewny jestem jednak, że opóźnienia
były po stronie PC.

--
RobMac

Wed May 23, 2007 9:35 pm   

Użytkownik "BartekK" <sibi@NOSPAMdrut.org> napisał w wiadomości
news:f316lp$os1$1@atlantis.news.tpi.pl...

glupi jest zawsze programista - nigdy narzedzie - co najwyzej jedno moze byc
wydajniejsze od drugiego.

Bascom, atmega8, kwarc 11,051 szybkosc 9600bodow, wyzwalanie jednobajtowa
komenda inicjujca przerwanie z uartu, wysylane przez printbin, ramka 24
bajty, po komendzie odczyt danych (miedzy innymi odczyt 8 8bitowych
rejestrow szeregowych) procedura wyznaczajaca CRC, procedura szyfrujaca
transmisje, umiesczczenie wyniku w tablicy, wysylka przez printbin
Od strony PCta aplikacja w delphi z TComPort, zapytanie wyzwalane po
odczycie poprawnej ramki - odczyt ok 20-30 ramek na sekunde (wiele zalezy od
PCta co w danej chwili robi - dlatego inicjacja po odebraniu ramki a nie co
x czasu).

Kiedys pisalem bardzo duzo dla Z80, potem dla 51 - wszystko zawsze w
asemblerze + wlsny wielozadaniowy system operacyjny.
Niedawno przeskoczylem na avry ale ze glownie pisze teraz soft dla PCtow to
najnormalniej w swiecie zabraklo mi czasu aby uczyc sie nowego asemblera i
srodowiska C. Dlatego z pewna taka niesmialoscia kupilem bascoma. Kiedys
bylem sceptyczny do tego wynalazku teraz jestem
zadowolony.
Jeden projekt przenioslem z 51 na avra w ciagu ........ 48 godzin od zakupu
licencji bascoma na podstawie takiej smiesznej zielonej ksiazki.
I nie jest to program migajacy jednym ledem :)

Tak wiec troche pokory Panowie :)

Porada dla kolegi Mariusza - zmiejsz predkosc transmisji, (szybciej nie
oznacza szybciej ) i przyjrzyj sie dobrze co odebiera twoja delphiana
aplikacja bo moze byc tak ze poprostu nie mozesz ukompletowac ramki bo to co
odczytujesz z uartu PCta to moze byc raz 4 bajty potem 8 potem 2 potem 10 i
jak tego dobrze nie poskaldasz w oczekiwana ramke to dupa blada. Ja zawsze
daje 3 bajty startowe FE AA F0 i dopiero
gdy uzyskam taka kombinacje odebrranych kolejno bajtow zaczynam kompletowac
ramke, na koniec kontrola crc zeby uniknac przypadkowego zestawienia bajtow
danych jako naglowka rozruchowego.

pozdrawiam wojtek
www.neuron.com.pl
CMMS Maszyna
Golem OEE

Wed May 23, 2007 10:07 pm   

Aplikacja została napisana w Borland C++ Builder 6.0 Personal, zgodnie ze
sztuką i w oparciu o książkę "RS 232C - praktyczne programowanie. Od Pascala
i C++ do Delphi i Buildera" ( http://helion.pl/ksiazki/rs232c.htm )



Urządzenie (po odebraniu komendy "TX") wysyła do aplikacji za jednym razem
ciąg znaków ASCII, zawierający 8 danych. Po czym czeka (input) na kolejną
komendę TX.

Przykładowy ciąg: 514:512:512:512:514:515:512:516

Dana rozdzielona średnikiem może przyjąć wartość od 0 do 1023 (np. 514).

Dane, które przesyła urządzenie ładowane są do 64 bajtowego bufora RS232 po
stronie aplikacji PC.

Aplikacja:

1. czyści bufor nadawczy i odbiorczy
2. wysyła komendę "TX"
3. czeka tyle ile wynosi interwał (częstotliwość ustawiona za pomocą suwaka)
4. odczytuje bufor odbiorczy
5. wydziela ze stringu 8 danych i ładuje je do zmiennych
6. przekazuje dane do wykresu
7. wraca do punktu 1.

Wed May 23, 2007 10:36 pm   

To jest mało efektywna metoda i mogąca potencjalnie powodować błędy
pominięcia cześci ramki. Moim zdniem zupełnie niepotrzebnie czeksz aż
przyjdzie cała ramka. W tym czasie możesz już zaczać obrabiać początek
ramki. Jeżeli ustawisz za krótki czas to nie odbierasz wszystkich danych,
jeżeli ustawisz za długo to masz niepotrzebne opóźnienia. System w PC jest
obciążony dynamicznie i nigdy nie znajdziesz optymalnego czasu, bo on pływa
w zależności od obciążenia systemu innymi zadaniami.
Spróbuj w ten sposób:
1. wysyłasz polecenie odesłania danych ( u Ciebie "TX")
2. Czekasz na zdarzenie przyjścia danych lub rozpoczynasz sprawdzanie czy
coś przyszło.
3. Na bieżąco analizujesz protokół transmisji (nagłówek, adres, liczba
danych, dane, CRC, itp, itd...). W Twoim przypadku odliczasz kolejne
zestawy: dwukropek i liczba. Jeżli odebrałeś ostatnie element ramki danych,
w Twoim przypadku ostatnią liczbę to kończysz nasłuchiwanie. Sprawdzasz też
timeout operacji. Jeżeli jest większy niz zadany to czyścisz bufory i
zacznasz od punktu 1.
4. przekazujesz dane do dlaszej obróbki

--
Piotrek.
http://www.pitlab.pl

Thu May 24, 2007 8:10 am   

Wed, 23 May 2007 23:36:53 +0200, na pl.misc.elektronika, Piotr "PitLab"
Laskowski napisał(a):


Cześć.

IMHO w tym przypadku Windows to najmniej prawdopodobna przyczyna. Dość
podobne rozwiązanie ( komenda do AVR 18 bajtów, zwrot 12 bajtów danych ,
115200 baud) + aplikacja Delphi pozwoliło zjechać z interwałem stabilnego
odświeżania do ok. 6 ms - przy jednoczesnej prezentacji danych na
kontrolkach graficznych i nie na jakimś ekstra potężnym PC.
Tu gdzieś jest jakaś konkretna programowa przyczyna opóźnień i zanim się
jej nie wyłapie wszelkie dokładniejsze optymalizacje niewiele dadzą.

--
Pozdrowienia
Jurek Szczesiul

Thu May 24, 2007 10:17 am   

Zrobiłem testy siłowe za pomocą kodu

$regfile = "m16def.dat"
$crystal = 16000000
$baud = 38400

Dim Licznik As Integer
Dim Rozkaz As String * 2

Licznik = 0

Do
Incr Licznik
Print Licznik ; " : 1023:1023:1023:1023:1023:1023:1023:1023"

If Licznik > 1000 Then
Do
Input Rozkaz
If Rozkaz = "TX" Then
Licznik = 0
Exit Do
End If
Loop
End If

Loop

End


Efekt jest taki, że 1000 takich stringów jest wysyłany do terminala na PC w
ciągu 12 sekund, co daje maksymalną prędkość około 8 stringów (po ok. 40
znaków) na jedną sekundę. To potwierdza to, co dzieje się w aplikacji -
przeskoczenie z 5Hz na 10Hz sprawia, że aplikacja odczytuje niepełny string,
ponieważ urządzenie nie zdążyło go jeszcze wysłać.