Some more info. I'm querying device every 5 seconds for data, and it should always respond with 10 bytes packets: so data should come fairly quickly into serial buffer, and then a few seconds of silence; sometimes however the device can send data on its own, I don't know when, but also as a 10 bytes packets. When I added clearing buffer after 1 or 2 seconds when nothing is read, then I'm sure any leftovers are cleared before next transmission. So after I have 10 bytes packet received I can verify if it has proper data or is somehow corrupted: so if one transmission fails, I should be ok, especially when I can clear the buffer before next data coming in.
The code you posted contains no error-recovery at all. It's a bit off-topic on this site to ask how to implement a new feature error-recovery ; but I'll try. I'll assume it isn't 1. So I'll assume that it's 2. In either case, what's important is:. Setting Read Timeouts looks interesting. It may be your best algorithm: set VMIN to say that you want to receive no more or less than exactly 10 bytes when you read.
However, the timeout only applies to the first character read, so if for some reason the driver misses one character inside the N byte packet then the read call could block forever waiting for additional input characters.
You don't say why you want error-recovery after losing a character: perhaps you sometimes get overruns in the driver, or bit parity errors from the serial port? If you do this then you can be more sure that you will get 10 bytes; but you can only do it if the protocol allows you to recognize an illegal byte value. Whether you can clear the buffer "before the next data arrive" is difficult to say: I don't know when the next data is supposed to arrive.
Depending on how you handle parity errors, maybe bytes are never lost. If bytes are sometimes lost then you may want to implement logic like:. Instead of actually setting a timer, above, perhaps loop doing a blocking-read-with-timeout which either reads the bytes, or expires. As well as handling too few bytes above , you could modify the above to check for receiving more than 10 bytes: after you receive 10 bytes, do another blocking-read-with-small-timeout to verify that there are no more bytes to receive.
If there are extra bytes, then read them all before returning to the 'waiting-for-nextbytes' state otherwise, these extra bytes will mess up your next byte packet.
I think there's an obvious bug in the code. Anonymous not verified. HRG not verified. Suppose while exe is running continuously , when device is switched off comport is closed ,when device is turned on the exe should be able to read data from com port without restarting. Scott Diller not verified. BOOL Status;. Please check the complete source code at our github repo here. George Nicolas I want to thank you very much for the explanation, i spend lot of hours trying to understand windows.
Privacy Policy. All rights reserved. All trademarks and service marks are the properties of their respective owners. Skip to main content. Search form Search. Request new password. Submitted by Rahul. Sreedharan on 22 December - am. Here is the screen shot of the Program writing into serial port of Windows 7 Computer Please note that i have changed the names of the C files in the latest release. Here is the screen shot of the Program writing into serial port of Windows 10Computer Reading from the Serial Port Reading from the serial port is accomplished by the ReadFile function.
Serial Programming. Win32 API. Log in to post comments. Serial Port. Data Received Event Reference Is this page helpful?
Please rate your experience Yes No. Any additional feedback? Namespace: System. Ports Assembly: System. In this article. A straight through cable will not be what you want. Although a wee verbose, this page probably has what you're looking for.
Use GetCommState to get the info on the port, change anything that you need to change, and then SetCommState to apply those changes. What exactly are you trying to talk with? Do you know the protocol involved? Any sufficiently advanced bug is indistinguishable from a feature.
0コメント