This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Handling RTS with an UART that doesn't directly drives the RTS pin
- From: Bernard Fouché <bernard dot fouche at kuantic dot com>
- To: "<ecos-devel at ecos dot sourceware dot org>" <ecos-devel at ecos dot sourceware dot org>
- Date: Tue, 12 Jun 2012 14:34:18 +0200
- Subject: Handling RTS with an UART that doesn't directly drives the RTS pin
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