16550 uart problem

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all,
I have a 16550 uart running at 115200 8N1.
The level at which the UART generates an Interrupt when receiving data is 8.
This means if it has 8 bytes of 16 of it's input fifo filled, it will make
the interrupt.
But I have still data loss if receiving large amounts of data from a PC to
my device.
It seems, that the PC has too long to stop it's transmission. The PC is
running Windows XP.
Is there a definied number of bytes the PC is allowed to send after the
handshake signal tells
it to stop sending?
Thanks in advance

Re: 16550 uart problem
On Fri, 31 Dec 2004 12:52:55 +0100, "David"

Quoted text here. Click to load it

The Windows driver for the 16550 can handle 115.2kBaud, but your
application is probably not taking the data from the operating system
fast enough.  Try raising the system buffer size using the

SetupComm(handle,INQSIZE,OUTQSIZE) function.

Quoted text here. Click to load it

If your application cannot keep up with the data rate, then enable
software or hardware handshaking using the SetCommState() function.  I
don't know how much slack there is in the use of handshaking.

-Robert Scott
 Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply
address is fake.)

Re: 16550 uart problem

Quoted text here. Click to load it

You have the 16550 UART on the embedded system ?
If so, then lower the interrupt threshold to 4 bytes.
Meaning you get the interrupt after 4 bytes, giving
another 12 bytes slack for the timing.
You could also generate the interrup after one byte,
which gives 16 bytes slack in timing.
Important is the interrupt procedure : it has to get all
bytes from the fifo, not jus as many as set in the level.

Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Re: 16550 uart problem

Quoted text here. Click to load it


The 'half-full' point.  Okay.

Quoted text here. Click to load it


I assume here that you are meaning that your device loses some data, in some
fashion as yet unstated or unknown.

Quoted text here. Click to load it

So, by this I take it that you are attempting to use flow control, either
software or else hardware.  By saying 'too long to stop' I infer that you are
trying to 'say stop' and that the PC keeps right on pushing data at you, anyway.

If so, then the reason for your data loss becomes clear.  Your buffers in your
device are overrunning, yes?

Quoted text here. Click to load it

I don't know of one, off-hand.  If you are using hardware handshaking, the low
level driver (no matter the O/S) in the PC should either receive an interrupt
event for a status change or else poll the status soon.  It is possible that the
part of the code that detects this change isn't directly involved in pumping out
more characters, so it merely sends an internal software signal (perhaps via a
Windows message -- I hope not, but possible) to the part of the driver
responsible for stuffing the next characters when its own hardware becomes
available for more.

You *could* run some tests and make an empirical judgment about how many more
characters you are likely to see, once a stop signal is given.  But you'd also
need to get an idea about what the variability of that may be across various
operating systems and machine configurations, as well, if you want some chance
at a robust idea.  You may need to write your own drivers on the PC side or else
make sure you provide simply excessively 'huge' receive buffers in your device.

In serial drivers I've written on the PC (but not under Windows), the detection
of hardware flow control takes place as a status change interrupt event and
impacts the outgoing flow immediately.  In the case of 16550 style devices, this
means you would see at most another 16 characters coming out from the FIFO.  In
the case of extended chipset types, which support 64 or 128 characters in their
FIFOs, it could mean that many, instead.  Since some PCs may actually use these
fancier style serial chips, I'd plan on at least 128 characters more after
trying to stop the flow.  However, these chips also support, I believe, an
internal mechanism to detect the hardware flow control and halt the FIFO output
more directly, so it could be better but that would depend on the exact mode.

But I'm not sure I understood your problem clearly, so I may be wandering here.


Site Timeline