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?