Re: Reliable RS232 at 115200 baud

Steve,

spforeman@googlemail.com schrieb:


That depends. What UART are you using, what type of PC? I have had mixed results
depending on the UART used. The standard UARTs from the CPU board's chipsets
usually work quite nice but I have seen bugs in the design (FIFO hickups). In
many modern PCs with UARTS they do not have UARTS in the chipset but have
connected USB UART chips. With USB UART chips you depend on a very well written
UART driver from the manufacturer which can be a problem. We had the best
results with PCI 2x or 4x UART boards with a receive fifo size of 128 bytes.

The FIFO size can not be configured, however you can usually configure the FIFO
interrupt threshold using the control panel. On custom UART boards there is
usually anadditional tab for these settings in the device manager. It is
important to set the fifo threshold not too high because this leaves the PC with
less time between the receive interrupt and the receive overrun. If your PC has
receive fifo overruns then make the threshold smaller (max 8 or even 4 bytes
threshold, never set it to 14).


Comm breaks is strange because as far as I remember a COM break means more than
9 bits of "low" level on the serial line which can never happen when a device is
consantly sending data; it indicates either a broken hardware or a wrong baudrate.

There are actually two different overrun errors:
(also see http://msdn.microsoft.com/en-us/library/ms810467.aspx)

CE_OVERRUN means the UART chip RX buffer has overrun and could indicate that the
receive fifo threshold is set too high or that the PC has disabled interrupts
for too long (PC was busy with other low level hardware handling).

CE_RXOVER indicates that the UART driver's software receive buffer has overrun.
It means that your application can not cope with the amout of data, or that you
set the receive buffer too small to read and process it with the usual windows
time slice. How did you set the buffers, and what error do you actually get? See
SetupComm functions for details.


There is another problem that you might get when you start your windows
application after the device: When sending serial data back-to-back (without any
pause) you have a synchronization problem: depending on the data you might never
be able to synchonize on the start bit, the receiving UART might recognize other
high-low transitions as start bit, hence receiving garbage. Try to start your
application, set the correct baud rate, start receiving and then reset your
device. If everything is ok now, you have a sync problem.
The only reliable way to resync is when the sender stops sending for a least one
character time or when inserting 0x00 or 0xff bytes into the data stream. There
is also some woodoo involved here.

Norbert