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 David
16550 uart problem
Started by ●December 31, 2004
Reply by ●December 31, 20042004-12-31
On Fri, 31 Dec 2004 12:52:55 +0100, "David" <vonarburg.nospam@omnisec.ch> wrote:>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.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.>Is there a definied number of bytes the PC is allowed to send after the >handshake signal tells >it to stop sending?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.)
Reply by ●December 31, 20042004-12-31
David wrote:> 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?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. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Reply by ●December 31, 20042004-12-31
On Fri, 31 Dec 2004 12:52:55 +0100, "David" <vonarburg.nospam@omnisec.ch> wrote:>I have a 16550 uart running at 115200 8N1.Understood.>The level at which the UART generates an Interrupt when receiving data is 8.The 'half-full' point. Okay.>This means if it has 8 bytes of 16 of it's input fifo filled, it will make >the interrupt.Yes.>But I have still data loss if receiving large amounts of data from a PC to >my device.I assume here that you are meaning that your device loses some data, in some fashion as yet unstated or unknown.>It seems, that the PC has too long to stop it's transmission. The PC is >running Windows XP.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?>Is there a definied number of bytes the PC is allowed to send after the >handshake signal tells it to stop sending?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. Jon
