From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Stuart MacDonald <stuartm@connecttech.com>
Cc: "'Samuel Thibault'" <samuel.thibault@ens-lyon.org>,
"'Sébastien Hinderer'" <Sebastien.Hinderer@libertysurf.fr>,
rmk@arm.linux.org.uk,
"'Linux Kernel Mailing List'" <linux-kernel@vger.kernel.org>
Subject: RE: [Patch] new serial flow control
Date: Thu, 07 Oct 2004 14:00:24 +0100 [thread overview]
Message-ID: <1097154020.31614.22.camel@localhost.localdomain> (raw)
In-Reply-To: <043c01c4ac0d$2c8bac80$294b82ce@stuartm>
On Iau, 2004-10-07 at 02:30, Stuart MacDonald wrote:
> RS485 is a driver-transparent electrical interface. Unfortunately the
> half-duplex and master-slave(s) arrangements require some sort of
> token passing to know when they can successfully transmit. This is
> usually handled by the apps in some manner, although it's often wanted
> to be handled by the serial driver. This could be one method of
> signalling, but isn't sufficient to show RS485 operation.
No its one I've seen a lot there and it turns out having dug into docs
and consulted the serial people in pointy hats that it is RS232
half-duplex mode which is one of those bits of the spec nobody ever
uses.
In this mode the DTE end (host normally) asserts RTS to request
transmit access to the link. The DCE asserts CTS to indicate it has
finished sending bits, and the DTE then transmits.
RTS is a direction selector (RTS = 0, DCE transmit) (RTS = 1, DTE
transmit). CTS acts as the handshake to deal with the link turn around.
So that makes this much more useful.
Alan
next prev parent reply other threads:[~2004-10-07 14:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-04 22:54 Samuel Thibault
2004-10-04 22:55 ` Samuel Thibault
2004-10-05 22:51 ` Alan Cox
2004-10-06 7:11 ` Sébastien Hinderer
2004-10-06 7:38 ` Samuel Thibault
2004-10-06 13:29 ` Alan Cox
2004-10-07 1:30 ` Stuart MacDonald
2004-10-07 1:47 ` Paul Fulghum
2004-10-07 7:26 ` Sébastien Hinderer
2004-10-07 13:00 ` Alan Cox [this message]
2004-10-07 14:28 ` Samuel Thibault
2004-10-05 16:46 Chuck Ebbert
2004-10-05 17:25 ` Samuel Thibault
2004-10-07 19:08 ` Alan Cox
2004-10-07 20:27 ` Russell King
2004-10-07 22:08 ` Samuel Thibault
2004-10-07 23:10 ` Russell King
2004-10-07 21:43 ` Samuel Thibault
2004-10-07 22:55 ` Samuel Thibault
2004-10-08 18:59 ` Samuel Thibault
2004-10-07 11:08 Nick Craig-Wood
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=1097154020.31614.22.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=Sebastien.Hinderer@libertysurf.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--cc=samuel.thibault@ens-lyon.org \
--cc=stuartm@connecttech.com \
/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
Powered by JetHome