public inbox for
 help / color / mirror / Atom feed
From: Nick Garnett <>
To: "Bernard Fouché" <>
Cc: "<>" <>
Subject: Re: Handling RTS with an UART that doesn't directly drives the RTS pin
Date: Tue, 12 Jun 2012 13:16:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 12/06/12 13:34, Bernard Fouché wrote:

> I'm about to :
> - add definitions for CYGNUM_SERIAL_STATUS_THROTTLE_RX and 
> - 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

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      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071

  parent reply	other threads:[~2012-06-12 13:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-12 12:34 Bernard Fouché
2012-06-12 13:12 ` Stanislav Meduna
2012-06-12 13:16 ` Nick Garnett [this message]
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] ` <>
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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).