public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jlarmour@redhat.com>
To: Ling Su <lingsu@palmmicro.com>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Serial Port Question.(Help needed!)
Date: Sun, 21 Jan 2001 10:24:00 -0000	[thread overview]
Message-ID: <3A6B295E.8E9613BB@redhat.com> (raw)
In-Reply-To: <001301c08319$2913abf0$0201a8c0@raccoon>

Ling Su wrote:
> 
> Recently I have met some problem with the serial port driver on NEC VRC4373.
> I use serial 0 for GDB debugging, and serial port 1 for communication with
> PC. In the testing stage, it works well. When I do some intensive work, the
> serial port 1 will easily got stucked. I found it is due to the PC writes to
> this port while the applicaiton on board trying to send something back.
> Looks like some conflicts happened. Is this a reasonable guess?
> 
> I check the vrc4373 board document, I found the RTS/CTS signals are not
> connected, so hardware flow control is not allowed. I wonder if software
> flow control can solve this problem, since it is not caused by buffer
> overflow.
> 
> Based on above assumption, I thought if I can switch serial port 0 and
> serial port 1, and turn on hardware flow control for serial port 0, it could
> be working. But I am not sure if GDB stub can work on a serial port 1 which
> has no hardware flow control, anybody can kindly shed me some light on this?
> 
> Since when I run the eCosconfig windows tools, I found the hardware flow
> control for serial port is greyed, I wonder if the hardware flow control can
> be turned on without modifying the serial driver for Z85c30. Can I forced to
> enable the hardware flow control directly?

Hardware flow control is only ever available for the "real" serial driver,
and hasn't yet been included in the z85c30 serial driver. But even if it
was, it wouldn't help because the GDB stub doesn't use the serial driver..
it just uses the "hal diag" support.

You may want to check that all flow control is off on the PC side. We
haven't ever seen the problems you describe.

If your PC is too slow to work at 38400bps, then perhaps you could try a
slower speed.

> (BTW, I have sent two emails regarding to vrc4373 and vrc4375, unfortunately
> got no reply till now, anyone has this experience, please let me know. Right
> now I am working on a platform which is obselete, I don't know if I should
> transfter to another platform. Of course, I will try to port eCos on vrc4375
> in current stage. Any helpful inputs can speeds up this work, I guess. :))

We have no experience of the vc4375 here.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

      reply	other threads:[~2001-01-21 10:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-20 11:42 Ling Su
2001-01-21 10:24 ` Jonathan Larmour [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=3A6B295E.8E9613BB@redhat.com \
    --to=jlarmour@redhat.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=lingsu@palmmicro.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).