> 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);
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);
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.
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 :-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.