> ----------
> From: Glynn Clements[SMTP:[EMAIL PROTECTED]]
> Reply To: Glynn Clements
> Sent: 27. juni 1998 18:11
> To: Rildo Pragana
> Cc: [EMAIL PROTECTED]
> Subject: Re: Q:serial programming line turnaround?
>
>
> 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]>
>
When a process looses its time slice (=processor time; which in a OS
like Linux may happend at any time, and in particular when calling read
for a serial device in blocking mode), it will be rescheduled for
execution by the scheduler process ("the OS"), _when_this_runs_ (and
considers scheduling blocked processes with pending IO), which seems to
occur only at the timer interrupts (which in standard kernels are each
10 ms). This will typically induce a delay for a process attempting line
turnaround, even if said process runs at a sky high priority and in real
time mode.
One could, at least theoretically, program such a process not to give up
the processor, but busy-wait polling the serial device (which should be
nonblocking, thus), until the anticipated answer has arrived. This will
only work if the process is given (real time) priority above everything
else. This is however a BAD thing, as the entire system will hang, if
the process loops.
One could also recompile the kernel with another setting of the HZ macro
in a header named something like /usr/include/linux/sys/param.h. I've
tried this with a RedHat 3.something distribution with a 1.2.13 kernel
(low number at least); it actually worked (with HZ set to 256). I dont
know how the 2.x kernels will react; at least one should expect trouble
with a number of programs, which refer to HZ, these need to be rebuild
(one has to grep a lot of source to see which programs..).
I had a similar problem a month ago, as I needed to communicate with a
piece of electronics using an RS-485 multidrop half-duplex protocol. My
problem was that I had to toggle the RTS line immediately after the last
byte of a request command had left the UART; I did this by monitoring
what I sent (RS485 is a "bus", it uses the same wire for transmit and
receive) by simply receiving it (think it over, it turns into the same
problem).
What I did was this: I gave up. I wouldnt compromise system safety by
either of the above methods, and as I have the luxury of having office
next door to the electronics guy, I had him change the protocol to a
to-wire, full duplex one, thus eliminating the line turn around problem.
(I dont know whether this is much help, though, but anyway) hi,
Niels HP
[EMAIL PROTECTED]
