Re: Handling RTS with an UART that doesn't directly drives the RTS pin

[Bernard Fouché <bernard dot fouche at kuantic dot com>]

Le 12/06/2012 15:15, Nick Garnett a écrit :
> On 12/06/12 13:34, Bernard Fouché wrote:
>
> > I'm about to :
> >
> > - add definitions for CYGNUM_SERIAL_STATUS_THROTTLE_RX and
> > CYGNUM_SERIAL_STATUS_RESTART_RX
> > - add a cdl option to have the line status callback function, which is
> > user defined, to be called with the corresponding value if
> > throttle_rx()/restart_rx() are called within serial.c .
> > - hence the user defined callback can handle RTS (or any other flow
> > control pin) the way it wants
> >
> > Do I break some convention doing this or is it okay?
> I don't think hacking this into the generic code is the right way to do
> this. In the past, when I have had to do the same and use GPIO pins for
> this, I have added it to the underlying serial driver. Of course this
> was for devices that had no other notion of hardware flow control. But
> you could define your own variant of the 16x5x driver that did the right
> thing.
Modifying the 16x5x driver would mean to add a cdl option to specify a 
function name (what function to call to change RTS) since there is no 
GPIO infrastructure in the 'public' eCos version. For the same reason, 
sending to the driver the information related to CTS pin state has to be 
done from application level (but the infrastructure already exists 
thanks to CYG_IO_SET_CONFIG_SERIAL_FLOW_CONTROL_FORCE, which is used by 
TERMIO btw). But if such a change is made into ser_16x5x.c, anyone 
having the same need with a different hardware driver will have to 
re-invent the wheel.

> However, a better approach is to avoid hacking on either the generic
> code or the 16x5x driver and make use of the driver stacking mechanism.
> Create a serial driver that passes all calls through to the underlying
> driver, except for the throttle and flow config options, which do the
> right things with the GPIO lines. Take a look at the TTY and TERMIO
> drivers for how to set this up.

RTS is the real problem: only serial.c knows when it's time to change 
the pin state because it's related to the use of the RX buffer, which is 
visible only to serial.c (please correct me if I'm wrong!). AFAIK there 
is nothing making the RX throttling information to reach higher levels 
since these higher levels are unaware of the buffering details underneath.

Another solution would be to add config keys to get/set the pointers of 
the low level functions of a serial channel which are exposed by a 
hardware driver and then one could insert any kind of middle level 
driver (like hooks): this would be more comfortable in the long run, it 
could help for debug or statistics. The xxx_serial_channelN definition 
ends in .data so I guess this is possible.
> Note that while RTS is a simple output level, CTS really needs to be
> driven by a GPIO line that can interrupt and which will then call the
> indicate_status() callback in its DSR. That should then drive the
> generic serial transmit engine.
This I already have.

The line_status callback change in serial.c is very simple: only a few 
lines of conditional compilation in throttle_rx() and restart_rx() are 
needed. Adding config keys to get/set the function pointers should be 
not too difficult also.

Le 12/06/2012 15:12, Stanislav Meduna a écrit :
> On 12.06.2012 14:34, Bernard Fouché wrote:
>
> > I think the change is to be done in serial.c, since it's the part of the
> > code that takes the decision to call throttle_rx() or restart_rx()
> Is this the correct place at all? As far as I can tell the
> flow-control here depends on channel buffer watermarks. It does
> not protect you from overflowing the 16x5x FIFO; it does not
> even know how deep it is.
>
> I do not know what UART speeds, UART FIFO sizes and maximum
> guaranteed DSR latency do you have in your system, but in case
> you want to protect against UART FIFO overflow I'm afraid
> the only reliable way is to modify the low level driver's ISR.
I don't have problems with the 16x5x hardware FIFO overflow condition: 
as you write this depends on the whole system characteristics. I 
consider my DSR latency  good enoug to empty the hardware FIFO in time 
(thanks to the patches of bug 1001456 the system does not lose time ;-) 
), and if not, I have to lower the value of 
CYGPKG_IO_SERIAL_GENERIC_16X5X_FIFO_RX_THRESHOLD. With a 16 bytes FIFO 
and a threshold of 8, I have more than 8 characters to have the DSR to 
empty the FIFO. At 115200bps (I don't go faster), that's 694µs: even 
when clocking very slowly there is time for many thousands of instructions.

My problem has never been (yet) the hardware FIFO but serial flow 
control since the consuming threads are less reactive than DSR, and I 
don't know what will do the device connected to the RS232 port.

    Bernard