From: "Bernard Fouché" <bernard.fouche@kuantic.com>
To: "<ecos-devel@ecos.sourceware.org>" <ecos-devel@ecos.sourceware.org>
Subject: Handling RTS with an UART that doesn't directly drives the RTS pin
Date: Tue, 12 Jun 2012 12:34:00 -0000 [thread overview]
Message-ID: <4FD7374A.1090602@kuantic.com> (raw)
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
next reply other threads:[~2012-06-12 12:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-12 12:34 Bernard Fouché [this message]
2012-06-12 13:12 ` Stanislav Meduna
2012-06-12 13:16 ` Nick Garnett
2012-06-12 16:56 ` Bernard Fouché
2012-06-13 10:10 ` Nick Garnett
2012-06-13 16:37 ` Bernard Fouché
2012-06-14 15:33 ` Bernard Fouché
[not found] ` <4FDF355B.2010209@mindspring.com>
2012-06-18 14:34 ` Closing devices Frank Pagliughi
2012-06-19 13:36 ` Bernard Fouché
2012-06-20 13:38 ` Frank Pagliughi
2012-06-20 15:20 ` Bernard Fouché
2012-06-21 18:20 ` Frank Pagliughi
2012-06-22 8:33 ` Bernard Fouché
2012-06-22 14:48 ` Frank Pagliughi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FD7374A.1090602@kuantic.com \
--to=bernard.fouche@kuantic.com \
--cc=ecos-devel@ecos.sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).