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