public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Grant Edwards <grante@visi.com>
To: Gary Thomas <gthomas@cambridge.redhat.com>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] RedBoot gets() problems
Date: Mon, 05 Mar 2001 13:52:00 -0000	[thread overview]
Message-ID: <20010305155658.A5726@visi.com> (raw)
In-Reply-To: <XFMail.20010303062832.gthomas@cambridge.redhat.com>

On Sat, Mar 03, 2001 at 06:28:32AM -0700, Gary Thomas wrote:

> On 02-Mar-2001 Grant Edwards wrote:

> > That cost is already incurred.  If the gap between rx
> > characters is smaller than the time it takes to do a network
> > poll, then initial characters in a command can be lost.  If I
> > send a command line to the board at 57600 baud, I generally
> > loose 2-3 characters due to the fact that rx characters are
> > only processed between network polls.
> 
> This is probably not the problem.  The true problem was that
> the timeouts were not being handled properly if you have
> multiple serial channels and were scanning for a console to
> use.  In this case, the old code would have waited for 10/N ms
> (where N is the number of channels) on each channel before
> deciding that any characters have arrived.  If N is 2, then
> this is 5 ms.  At a baud rate of 57600, 5ms represents as many
> as 15 characters! Thus, a bunch of characters could arrive on
> one channel while the code was waiting for the other.

Ah.  I hadn't spotted that.

> This patch will make it better, by forcing each channel to
> timeout as fast as possible (sorry, but the granularity is only
> 1ms).

The current performace is actually fine for a human typing
commands to RedBoot -- it's only a problem when the stuff sent
to RedBoot is buffered and sent a line at a time.  I can get
GDB to connect to RedBoot via TCP but not via serial port, and
I suspect it's because characters are getting lost when GDB
initiates the connection.

One thing I'm a little fuzzy on is why not set the timeout to
zero?  If there's no character there, don't sit and wait, check
the next port (or the network) right away.  The only issue I
can think of is that the system time no longer gets updated if
nobody is doing any 1ms delays.  Adding a 100us delay in the
main-loop that updates the system time every 10th time could
alleviate that problem.

> I'm still thinking about how [limited] network processing can
> take place between characters.  However, I'm not convinced that
> RedBoot is the place to be doing such processing.  It would
> seem to me that if you need more processing and higher response
> rates, you should really have a real application running, using
> interrupts, etc. ... but that's probably a whole different
> discussion.

The throughput is plenty good enough for what little network
processing I want to do.  Except for the GDB issue I just
mentioned, my only problem is when RedBoot switches exclusively
to a console port due to a noise glitch and ignores the network
completely.

-- 
Grant Edwards
grante@visi.com

      reply	other threads:[~2001-03-05 13:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-02  8:17 Grant Edwards
2001-03-02  8:31 ` Gary Thomas
2001-03-02  8:38   ` Grant Edwards
2001-03-02  8:48     ` Gary Thomas
2001-03-02  9:08       ` Grant Edwards
2001-03-03  5:28         ` Gary Thomas
2001-03-05 13:52           ` Grant Edwards [this message]

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=20010305155658.A5726@visi.com \
    --to=grante@visi.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=gthomas@cambridge.redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).