All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hounschell <markh@compro.net>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: Lee Revell <rlrevell@joe-job.com>,
	Paul Fulghum <paulkf@microgate.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Russell King <rmk+lkml@arm.linux.org.uk>
Subject: Re: Serial issue
Date: Fri, 18 Aug 2006 16:25:01 -0400	[thread overview]
Message-ID: <44E6221D.4040008@compro.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0608181551510.19978@chaos.analogic.com>

linux-os (Dick Johnson) wrote:
> On Fri, 18 Aug 2006, Lee Revell wrote:
> 
>> On Fri, 2006-08-18 at 15:15 -0400, linux-os (Dick Johnson) wrote:
>>> A file-transfer protocol??? Has he got hardware the __required__
>>> hardware flow-control enabled on both ends? One can't spew
>>> high-speed serial data out forever without a hardware handshake.
>>>
>> Interesting you should mention that.  As a matter of fact I have to
>> disable all flow control or the serial console doesn't even work.  I
>> considered this a minor issue and had forgotten about it.
>>
>> But, in polled mode with no flow control I can transfer a 10MB file.
>> There are a lot of retransmits but it works.
>>
>> Lee
>>
> 
> Using RS-232C for file transfer and as a serial console are two
> different things. Many terminals and terminal emulators don't
> even activate RTS/CTS. If you are just getting data from the
> output of a UART to view on a screen, the data usually comes
> in spurts, a line at a time, and a screen at a time. There
> is plenty of time for the receiving terminal to write the
> stuff to the screen.
> 
> However, with file transfers, data streams with no breaks.
> There needs to be time for these buffers of data to be written
> to files, etc., or else you eventually run out of buffers even
> if no interrupts are ever lost. Therefore, you must use hardware
> handshake. In other words, you need to connect your machines
> together with a complete null-modem cable, not just three wires.
> Then both machines need to cooperate, i.e., the receiving machine
> needs to lower CTS before its buffers get full and the sender,
> must look at its RTS bit and wait for it to go false before
> sending anymore data. Failure to do this __will__ result in
> lost data.
> 

Don't mean to but it but:

Take it from someone who actually still uses dumb terminals every day, any thing
over 9600 baud still requires some kind of flow control for reliable consistent
operation. Software (Xon/Xoff) and or hardware (RTS/RTS/DTE) flow control.


Mark


  reply	other threads:[~2006-08-18 20:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-18  0:47 Serial issue Lee Revell
2006-08-18 15:44 ` Paul Fulghum
2006-08-18 16:25   ` Lee Revell
2006-08-18 16:34   ` Lee Revell
2006-08-18 17:55   ` Lee Revell
2006-08-18 18:11     ` Paul Fulghum
2006-08-18 18:17       ` Lee Revell
2006-08-18 18:36         ` Russell King
2006-08-18 18:40           ` Lee Revell
2006-08-18 18:52             ` Russell King
2006-08-18 19:06               ` Paul Fulghum
2006-08-18 19:09                 ` Russell King
2006-08-18 19:15         ` linux-os (Dick Johnson)
2006-08-18 19:21           ` Lee Revell
2006-08-18 20:05             ` linux-os (Dick Johnson)
2006-08-18 20:25               ` Mark Hounschell [this message]
2006-08-18 20:28                 ` Lee Revell
2006-08-18 20:32                   ` Mark Hounschell
2006-08-18 20:36                     ` Russell King
2006-08-18 20:57                       ` Mark Hounschell
2006-08-18 20:34                   ` Russell King
2006-08-18 20:54                     ` Lee Revell
2006-08-18 21:02                       ` Russell King
  -- strict thread matches above, loose matches on Subject: below --
2006-07-26 21:45 Lee Revell
2006-07-26 21:57 ` Wolfgang Denk
2006-07-26 22:00 ` Lee Revell

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=44E6221D.4040008@compro.net \
    --to=markh@compro.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=paulkf@microgate.com \
    --cc=rlrevell@joe-job.com \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.