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

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

Hi,

I'm adding support for RTS/CTS handling for a couple of UART which have 
no hw support for these pins.

Only one UART has real hw flow control handled in silicon in my target 
and I already use this particular UART for another need.

To react to a CTS state change I detect in my GPIO interrupt DSR, I can 
send CYG_IO_SET_CONFIG_SERIAL_FLOW_CONTROL_FORCE using 
CYGNUM_SERIAL_FLOW_{THROTTLE|RESTART}_TX to serial.c . However I don't 
see any way to have serial.c to drive RTS: throttle_rx() and 
restart_rx()  call the underlying hardware driver (generic 16x5xon my 
target) but of course the driver can't do anything interesting in this case.

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() and 
there is no interest in having the underlying driver to be made aware of 
pins external to what it can handle itself (particularly for the generic 
serial driver). Modifying serial.c would also allow any existing 
hardware driver to use this feature since the situation I encounter 
occurs with many MCU having many UART but only one doing real hw flow 
control.

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?

  Bernard