Problem with COM Port with Windows

Question

5.00/5 (2 votes)

See more:

Hi,

First, sorry, I don't know much software, so please excuse my posting, if this is in the wrong spot. I have a consultant doing a meter program using MS Visual C++ 2010, and he is having trouble fixing a bug, so I thought I would see if anybody has a suggestion.

The application connects to a com port (115200, no handshaking), and displays an angle. The data can come quite fast at times. He occasionally misses the last sets of values (the last value sent is the most important one). He claims it is something to do with Windows.

When I use Hyperterm, it never fails, so I seem to think it shouldn't be a problem.

Any comments/suggestions?

Thanks,

Mark

Posted 2-Jul-12 7:28am

Mark Laughery

Add a Solution

Comments

SoMad 3-Jul-12 2:21am

Is it possible for you to go to a lower baud rate (obviously on both sides) to see if that works without missing any values?

Soren Madsen

5 solutions

Solution 2

Obviously it cannot be to do with Windows if Hyperterminal never misses the values (as you've suggested, Mark).

"Something to do with Windows" is the old classic excuse for bugs in app software.

Posted 2-Jul-12 19:27pm

michaelmel

Updated 2-Jul-12 19:41pm

v2

Solution 1

Hi Mark,
If your consultant is using unmanaged code, make sure he's using overlapped I/O. This helped me with a similar issue a few years ago.
In any case, have him google 'SERIAL PORT I/O'. The APIs are similar to file APIs, but the devil, as always, hides in the details.

Hope this helps,
Pablo.

Posted 2-Jul-12 7:46am

Pablo Aliskevicius

Comments

[no name] 3-Jul-12 0:14am

Which can be summed up by asking whether the COM port is being polled from the main thread or whether a separate thread is running to monitor the port using overlapped I/O.

Solution 3

How many bytes of data are received from the device in a single message. Perhaps there is more data coming and it's simply not being read.

It's quite common for the com port receive buffer to only hold 16 bytes (16550 FIFO), so anything over that might require two reads.

Good luck.

Posted 3-Jul-12 0:35am

krmed

Solution 5

First, thanks to all for the suggestions. I will run these past him to see if anything helps. Unfortunately, he won't be able to work on if for a week or longer. Is there a way to attach the SerialPort.cpp file here? I have no issues with anybody seeing it.

Thanks again,

Mark

Posted 3-Jul-12 11:54am

Mark Laughery

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

barneyman · Accepted Answer · 2012-07-03T00:58:00

As others have said, I'd suspect that the code is currently polling the receive queue, rather than having a dedicated thread sucking it dry, and pushing it into a buffer somewhere

20 years ago, I was comfortably getting 115k2 out of a 30Mhz DOS machine with a 16550UART, so these days it's not a problem for the hardware - Windows however, is extremely 'lumpy' in terms of performance if you don't talk to hardware effectively - i.e. on a second thread

I'd wager there's a single thread reading the com port, writing to disk - the latency in disk IO is delaying the poller sufficiently for the UART buffer to get swamped