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

[Nick Garnett <nickg@calivar.com>]

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.

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.

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.


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071