Rildo Pragana wrote:
> I have tried to make a user-level driver for a home-grown device,
> interfaced with a serial port. Unfortunately, I couldn't make it answer
> fast, even if the line is set to 38400 bps. I use termios structures with
> O_NOBLOCK and select() to get the answer received, but there is a delay of
> 20ms after the character available on the serial port (as I could measure
> in an oscilloscope).
>
> There is a simple way to program a tiny protocol for doing half-duplex
> comunication with a faster response than this? I'm aware of RTlinux
> (real-time), but I'm looking for a simpler way. It seems that the problem
> is a task-switch when I try to read back the result.
>
> Perhaps another line discipline could do the job, if I make the protocol
> in the device driver.
> Any pointers to such drivers? Other suggestions?
If you need the round-trip-time between receiving data and sending a
response to be less than 20ms, you'll probably need to either build
the code into the serial driver, or use a real-time OS.
I'm not sure that RT-Linux would be sufficient. IIRC, there is an
inherent 10ms lag in the serial driver, regardless of any process
scheduling issues.
--
Glynn Clements <[EMAIL PROTECTED]>
