W dniu 04.03.2010 00:44, Adam Dybkowski pisze:
>
> W sterowniku dla Windows jest okienko ustawień zaawansowanych, gdzie
> można m.in. zmniejszyć czas oczekiwania przed wysłaniem danych (gdy
> bufor nie jest zapełniony, standardowo 16ms a minimalnie 1ms). Może masz
> gdzieś też upchnięte podobne ustawienia w Linuxie, albo można jest
> ustawić niestandardowym ioctl'em? Wtedy nie problem dodać to nawet w
> źródłach avrdude.

Choroba, pod Linuxem w ogóle jakoś dziwnie działa obsługa portów
szeregowych. Nawet na RS-ie czysto sprzętowym (normalny COM1 wbudowany w
płytę) ma taki dziwny efekt przy wysyłaniu krótkich paczek po kilka
bajtów. Przykładowo kawałek kodu w C.

int handle = 0;
handle = open("/dev/ttyS0", O_RDWR);
for(int i = 1000; i; i--) {
write(handle, "abcd", 4);
tcdrain(handle); // czeka na opróżnienie bufora nadajnika
}
close(handle);

daje mi taki efekt, że wysyłane są paczki po cztery bajty, a między nimi
jest 20ms przerwy !!! Poszperałem na góglu, ale znalazłem tylko ludzi
mających podobny problem (choć ta zwłoka nie była aż tak duża).
Pierwszy raz robię obsługę RS-a pod linuxem i trochę mnie to zmartwiło.
Znają Koledzy może jakiś parametr (coś w stylu timeouta), który
zmniejszałby tę zwłokę? Dziwne to trochę, bo o ile rozumiem zwłokę w
wysyłaniu w przypadku gdy FIFO nie jest jeszcze zapełnione (choć
nadajnik powinien rozpocząć nadawanie z chwilą pojawienia się pierwszego
bajtu w buforze), to w przypadku wymuszenia nadawania trochę to bez sensu.

Pozdrawiam
Grzegorz

do góry

On Mar 5, 8:51 am, Grzegorz Kurczyk
<g...@c...slupsk.pl> wrote:
>
> Choroba, pod Linuxem w og le jako dziwnie dzia a obs uga port w
> szeregowych. Nawet na RS-ie czysto sprz towym (normalny COM1 wbudowany w
> p yt ) ma taki dziwny efekt przy wysy aniu kr tkich paczek po kilka
> bajt w. Przyk adowo kawa ek kodu w C.
>
> int handle = 0;
> handle = open("/dev/ttyS0", O_RDWR);
> for(int i = 1000; i; i--) {
>         write(handle, "abcd", 4);
>         tcdrain(handle); // czeka na opr nienie bufora nadajnika}
>
> close(handle);
>
> daje mi taki efekt, e wysy ane s paczki po cztery bajty, a mi dzy nimi
> jest 20ms przerwy !!!

Uzywasz kernela 2.4? W 2.6 "tick" jest 10x krotszy (10ms->1ms). Nie
znam implementacji tcdrain ale prawdopodobnie nie czeka ona na
zakonczenie transmisji w petli, a oddaje CPU schedulerowi.

Zamiast tcdrain sprobuj uzyc (nie sprawdzalem w praktyce):

do {
ioctl(handle, TIOCSERGETLSR, &lsr);
} while (lsr & TIOCSER_TEMT);

-hob

do góry

W dniu 05.03.2010 07:29, hobgoblin pisze:
> Uzywasz kernela 2.4? W 2.6 "tick" jest 10x krotszy (10ms->1ms). Nie
> znam implementacji tcdrain ale prawdopodobnie nie czeka ona na
> zakonczenie transmisji w petli, a oddaje CPU schedulerowi.

Jajko z serii 2.6.

>
> Zamiast tcdrain sprobuj uzyc (nie sprawdzalem w praktyce):
>
> do {
> ioctl(handle, TIOCSERGETLSR,&lsr);
> } while (lsr& TIOCSER_TEMT);
>

Właśnie coś w tym stylu kombinowałem, ale podpowiedź Kolegi bardzo dużo
mi pomogła. Działa, z drobną poprawką. Odwrotny warunek przy while.
Potrzebne mi to jest m.inn. do wysyłania danych przez bufor RS485
sterowany sygnałem RTS. W efekcie końcowym wyszło coś takiego:

ioctl(handle, TIOCMGET, &status);
status &= ~TIOCM_RTS;
ioctl(handle, TIOCMSET, &status);

write(handle, Out_data, strlen(Out_data));
do {
ioctl(handle, TIOCSERGETLSR, &lsr);
} while(!(lsr & TIOCSER_TEMT));

ioctl(handle, TIOCMGET, &status);
status |= TIOCM_RTS;
ioctl(handle, TIOCMSET, &status);

Wygląda niby dobrze, ale na oscyloskopie widzę niekiedy taką sytuację,
że RTS przeszło na moment w stan aktywny (ok 20..30us), a nie poszedł
żaden bajt. Po południu sprawdzę czy ta "ramka" jest gubiona czy
faktycznie wychodzi z następnym aktywnym RTS.

Dzięki za podpowiedź.
Pozdrawiam
Grzegorz

do góry

W dniu 05.03.2010 09:32, Grzegorz Kurczyk pisze:
> Wygląda niby dobrze, ale na oscyloskopie widzę niekiedy taką sytuację,
> że RTS przeszło na moment w stan aktywny (ok 20..30us), a nie poszedł
> żaden bajt. Po południu sprawdzę czy ta "ramka" jest gubiona czy
> faktycznie wychodzi z następnym aktywnym RTS.

P.S. Coś mi się wydaje, że to co obserwowałem, może wynikać ze
"złośliwego przypadku" wyzwalania oscyloskopu analogowego. Wieczorkiem
podepnę to pod cyfrówkę z długim rekordem, albo do drugiego komputera i
zobaczę co wyłazi z drugiej strony :-)

Pozdrawiam
Grzegorz

do góry

On Mar 5, 5:32 pm, Grzegorz Kurczyk
<g...@c...slupsk.pl> wrote:
>
> Jajko z serii 2.6.

Dziwne. Nie bede sie na ten temat wypowiadal bo juz dawno w tym nie
grzebalem.

> Potrzebne mi to jest m.inn. do wysyłania danych przez bufor RS485
> sterowany sygnałem RTS.

Moze da sie to zrobic sprzetowo? (man stty)

> W efekcie końcowym wyszło coś takiego:
[...]
> Wygląda niby dobrze, ale na oscyloskopie widzę niekiedy taką sytuację,
> że RTS przeszło na moment w stan aktywny (ok 20..30us), a nie poszedł
> żaden bajt. Po południu sprawdzę czy ta "ramka" jest gubiona czy
> faktycznie wychodzi z następnym aktywnym RTS.

Nie wiem. Na wszelki wypadek dorzuc sprawdzanie wyniku ioctl'a. Moze
petla konczy sie zbyt wczesnie?

Wez tez pod uwage, ze ten kod moze w kazdej chwili byc wywlaszczony.
Miedzy RTS i ramka (i na odwrot) moga trafic sie duze opoznienia.

Pozdrawiam,
-hob

do góry