Microsoft Windows V24 API & "Realtime"

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

Translate This Thread From English to

Threaded View
Maybe this is a bit OT but I hope to met somebody more experienced here.
I try to connect a uC by V24 to a PC running Windows system. The link
requieres significant throughput (no discussion if V24 or Windows
is right choice for this job)

The Visual Studio C++ Application access V24  by Win API calls
opening the interface in so called "overlapped IO" mode.
That means non blocking calls for the case of no response from the uC.

A simple example is, that PC tx one byte to the uC (anouncement), the
uC gives one byte answer (confirmation) followed by one byte of data
from PC to uC. Becouse given HW is a half duplex circuit (uC has no
UART and uses a single pin for SW implementation up to 115,2 kbaud)
the PC expects 2 characters for one byte request. First character is
the HW echo and second the response from uC. If there is no response,
the overlapped calls allow a timeout to pop up error or quit box
instead using the windows task manager to kill the application.

The response time from a 8 Mhz uC between request und confirmation is
as low as a single stop bit but the smallest time from receiving the
confirmation byte in PC until the data byte appears the PC output is
about 5 mSec. Believe this is the delay while a W32 kernel driver
receives the byte until a event is signaled to the applicaition task.
This delay was meassured at a NT4 system while a XP windows gives up
to 20 mS delay. All the delays together cut down the data throuhgput
to less than 10% of the available bandwith.

To avoid this, I increased the block size to transfer up to 256 bytes
with less direction changes as possible. This improves effective usage
of bandwith to over 50% but I still have many other trouble.

One of them is a W2000 Laptop where I call the API with correct
parameters to tx, but sometimes nothing appears to the V24 output pin.
Other applications work well over hours with that interface but my own
works only sometimes. On other NT4 and XP machines only the debug
version works good and release version has many communication timeouts.

I tried to find out the reason for the timeout and it is not the uC
becouse external protocoll trace analyzer shows correct response.
If I put a breakpoint to the release Version everything is suddenly
working fine. The reason is, if Windows notifies my application by
a event that e.g. 16 expected characters hase been received, only
14 of them are valid in the buffer when memcpy() copies the buffer
immediately after the event. If I dump the rx buffer with the debugger
after breakpoint triggered, it shows correct content of all 16 bytes.

Any experience or hints to that kind of problems?

Re: Microsoft Windows V24 API & "Realtime"
Quoted text here. Click to load it
 > [ snip request for high performance IO ]
Quoted text here. Click to load it

No discussion, a fact.
You better get rid of the idea an PC doing high performance
IO on the serial port. I once came a cross a protocol with
an embedded device changing baudrates on the fly. The command
being 'changebaud', with the reply being 'baudchanged' within
a few ms on the new baudrate of course. Even though it is a
mere overwrite of 2 timing registers, it took the API 1.5
seconds per call. The solution was to have an embedded device
close to the PC doing all this fast stuff.

Ing.Buero R.Tschaggelar -
& commercial newsgroups -

Re: Microsoft Windows V24 API & "Realtime"

BTW: this is the wrong newsgroup. Your problem is Win32 related. or or the corresponding MS groups are

Do you make use of the inter-character timeout (ReadIntervalTimeout)
of the windows driver? Which value?


Quoted text here. Click to load it

14 is the max. RX FIFO setting (if the hardware is 16C550-like).


1. disable the FIFO on your system, reboot (!) and try again.

2. check whether
it's the same problem I discovered recently. Sadly no work-around
other than not using ReadIntervalTimeout.

3. Buy a commercial serial driver package.

Please report about the success.

Oliver Betz, Muenchen

Re: Microsoft Windows V24 API & "Realtime"
Quoted text here. Click to load it

You're aware that longer setting on the FIFO makes the problem
of loosing char's worse.
The fifo is hardwarewise 16 bytes long. So an interrupt after
14 chars leaves 2 bytes to buffer just in case Windows is busy.
Then setting it to 4 bytes leaves 12 bytes buffer when windows
is busy. Therefore enable the fifo, but set its interrupt
to the shorter numbers. Getting more interrupts is the price
to pay.

Ing.Buero R.Tschaggelar -
& commercial newsgroups -

Site Timeline