Subject:
|
linux-lnp: select() vs. SIGIO ( was Re: Call for debugging support )
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 20 Dec 1999 02:15:43 GMT
|
Viewed:
|
1870 times
|
| |
|
|
Ben Laurie wrote:
>
> Martin Cornelius wrote:
> > My currently favored approach is to use select() for everything, my
> > tests show it is not affected by the hardware FIFO of the uart.
>
> I doubt that's portable (and I'm a little surprised).
Uuh, there was a little bug in my test program. Once again, i learned i
have to read gcc´s warnings carefully. On linux, select() suffers
exactly the same thing as SIGIO. If the hardware fifo of the uart is
enabled, and there is a stream of bytes coming in with 2400 baud,
select() reports the desciptor to be readable approximately on every
8´th byte, like SIGIO does. Of course, if bytes come in sporadically,
select() and SIGIO will work correctly and report them. ( i guess there
is a kernel timer checking for this case )
If you set the uart type to 16450 ( this means, disable the fifo), and
bytes poor in continously, the process will be awoken on every timer
tick - 10 msecs, read() will get 2 or 3 bytes.
However, there is a way to achieve better realtime behaviour for tty
reading: If uart is set to 16450, and the ASYNC_LOW_LATENCY flag of the
tty is switched on via ioctl(), select() or SIGIO will wake the process
IMMEDIATELY on every incoming byte. With high baudrates, you can load
your machine substantially by doing this.
I guess the complete scheduling is run in this case on every incoming
byte. -- BTW, this allows to speed up scheduling rate on linux without
patching the kernel -- Just connect 2 serial ports with a null modem
cable, set one of them to ASYNC_LOW_LATENCY, call read() in a loop on
it, and do continous write() to the other one.
Astonishingly, setting ASYNC_LOW_LATENCY only works if the uart is set
to 16450 (no fifo). if uart is set to 16550A (with fifo) the flag seems
to have no effect. ( Bug or feature ? ).
If the process runs with realtime scheduling switched on, this yields
somewhat hard realtime behaviour, wow!
Unfortunately, but i guess intentionally, one can set the
ASYNC_LOW_LATENCY flag without root rights, but changing the uart type
needs them.
Anyways, with this settings my new select() based linux LNP
implementation runs perfectly. No more collisions at all**, even if both
parties involved in communication try to send continously, and
inter-byte-timeout can be set to the original legOS Code value.
**to achieve this, i had to increase the tx_allowed time on the linux
side by 20 msecs.
i´d really like to have more RCX´s and more Towers to test this works
with more than 2 stations on the IR-space. Hopefully i don´t go crazy on
24´th and get another mindstorms kit -- there are rumours toys´r-us has
a special offer.
have a nice day, Martin
|
|
Message is in Reply To:
 | | Re: Call for debugging support
|
| (...) I doubt that's portable (and I'm a little surprised). (...) Only on sockets. (...) Don't be funny! Windows has its own threads, of course. Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! (URL) grandfather once told me that there are two kinds of (...) (25 years ago, 17-Dec-99, to lugnet.robotics.rcx.legos)
|
11 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
