C / C++ / MFC

10-Dec-08 20:19

Hai !
I have a device connected to a COM port, i send a command to the device, the device responds, this response is stored in the buffer of COM port.
I read part of the response from buffer, and send the next command, now if i read response from buffer, i get the old remaining response plus the new response.
so i want to clear the buffer before i send a new command!
so how to clear the buffer of a COM port !
thanks !

VC++Maniac10-Dec-08 20:27

VC++Maniac

10-Dec-08 20:27

How do you read and write to the Buffer?

kapardhi10-Dec-08 21:15

10-Dec-08 21:15

Using the handle of Port along with ReadFile () and WriteFile ()

Roger Stoltz10-Dec-08 23:24

10-Dec-08 23:24

When communicating directly with the serial driver through the ::WriteFile() and ::ReadFile() API, you cannot "flush" the read buffer.
The file API contains the ::FlushFileBuffers() function, but it only flushes the transmit buffer if the handle refers to a communications device such as a COM port.

You have to read the entire response from your first request before issuing a new request to the device.
Why does this present a problem for you? Is it due to the lack of transmission protocol that you don't know how much data to expect from your device?
Some way you have to know when you've received the complete response from your device, either by protocol or by a timeout.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

VC++Maniac10-Dec-08 23:30

VC++Maniac

10-Dec-08 23:30

Are you specifying the FILE_FLAG_OVERLAPPED flag in CreateFile()..?

Roger Stoltz10-Dec-08 23:40

10-Dec-08 23:40

Ummm, I guess you replied to the wrong guy... Wink | ;)

However, specifying the flag for overlapped mode doesn't make a difference regarding "flushing" the receive buffer in the serial driver.
On the other hand, overlapped mode should be used in any case.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

kapardhi11-Dec-08 1:17

11-Dec-08 1:17

To be more specific :

The context where i want to clear buffer is somewhat as follows :
The device which is attached to the COM port is sujected to a specific Baudrate, parity, databit and stopbit, whose values i do not know beforehand. so i send the command for all combinations of baudrate, parity, databit stopbits.
During the process i receive junk/unnecessary response for a wrong combination, and i get correct/ expected response only for correct combination of baudrate, parity, databibit and stopbit.
so i want only to read the correct response and ignore others !
I know correct value starts with a specific value, so when ever there is a response starting with the specific value, I read it else I ignore it.
Now for the responses which I get for wrong combination donot start with a specific value so I ignore them hence they get accumulated in the buffer, now when the correct combination is reached and I try to read the response it starts with previous junk values as this response doesnot start with my specific value so it gets ignored in way I lose my correct response also, so I want to clear the buffer befor I send my command.

Thanks !

Roger Stoltz11-Dec-08 2:09

11-Dec-08 2:09

kapardhi wrote:
The device which is attached to the COM port is sujected to a specific Baudrate, parity, databit and stopbit, whose values i do not know beforehand. so i send the command for all combinations of baudrate, parity, databit stopbits.

You actually mean that you have no idea, and cannot predict, what settings the device uses on start up? I find that very hard to believe, because it means that the device is uninitialized and hence should not be able to communicate at all.

Usually a device that supports multiple communication settings starts off with a known configuration; e.g 300 baud, 1 stop bit, no parity. Then the host negotiates with the device about a new configuration through a known protocol.

If you don't know anything about this device, you would be better off using an oscilloscope to find out what configuration is used.
But even if you find out what configuration is being used, you still have to know the protocol, which I suspect can be found at the same place as where the communication settings are documented.
The alternative is to set a timeout using ::SetCommTimeouts() to let the timeout of the read operation expire when the hardware hasn't received a new byte within e.g. ten byte times. Then it's reasonable to assume that you've received all data the device wants to send and you can continue and try another configuration.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

kapardhi11-Dec-08 2:25

11-Dec-08 2:25

Sorry u are misunderstanding me !
Actually in my application i have an option to change the baudrate, parity, stopbit, databit of the device connected as well as to change the baudrate, parity, stopbit, databit of the COM port.

now lets assume one of the user have changed the device baud rate to 115200, with even parity, 6 databits 2 stopbits.

now i donot know the configuration of the connected device, so i have to change my COM port settings and send command for all combinations of baudrate, parity etc in order to communicate with the device.

when i get the correct/expected response i can conclude that this is the combination of the device!
i am also using CommTimeOuts !

Thanks !

Roger Stoltz11-Dec-08 3:01

11-Dec-08 3:01

kapardhi wrote:
Actually in my application i have an option to change the baudrate, parity, stopbit, databit of the device connected as well as to change the baudrate, parity, stopbit, databit of the COM port.

Why is this option offered to the user?
Is it because the application communicates with different kind of devices with different communication settings?

IF the application connects to different devices, doesn't one particular device start up with the same settings as the last time, i.e. is it not predictable?
If it is predictable, why not let the user choose from a list of device types that corresponds to the communication settings instead of giving him the possibility to change all settings and thus create this problem for you, the application, the device and himself?

My point is that the settings in the device should be the same every time it starts. If the user knows what kind of device it is, the application should know what configuration to use in order to communicate with that kind of device. It's your responsability as developer to make this mapping and if you don't think it is, then the user could use HyperTerminal, PuTTY or similar.

kapardhi wrote:
i am also using CommTimeOuts !

But probably the wrong way, or with the read timeout too short, since you clearly have not received the complete answer. Otherwise you would not have posted this thread in the first place.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Iain Clarke, Warrior Programmer

Iain Clarke, Warrior Programmer11-Dec-08 0:13

11-Dec-08 0:13

I can see this being very fragile [*]

What if you see the first part of the response, act on that, clear the buffer, but the rest of the response is still coming in?
You could clear the buffer too early. What do you do with the junk data?
If you wait for it to be quiet, you will add long delays.
If you wait till the right amount of data has come in, you don't need to flush.

I really struggle to see you needing to do this, unless your protocol is broken. If it's designed by someone else, then it's probably fine and you need to change your code. If it's designed by you, then you may need to go back and change the protocol *then* your code.

I've had similar issues with Pipes and sockets with varying data-lump-sizes, and solved it by having a header value specifying how many further bytes are in this lump of data. Simple but works well. Whether you pay attention to the whole data-lump or not, it's wise to read it all in. Feel free to throw it away.

Good luck,

Iain.

[*] A euphemism meaning it will fail within 2 minutes of someone else using it.

kapardhi11-Dec-08 1:18

11-Dec-08 1:18

To be more specific :
The context where i want to clear buffer is somewhat as follows :
The device which is attached to the COM port is sujected to a specific Baudrate, parity, databit and stopbit, whose values i do not know beforehand. so i send the command for all combinations of baudrate, parity, databit stopbits.
During the process i receive junk/unnecessary response for a wrong combination, and i get correct/ expected response only for correct combination of baudrate, parity, databibit and stopbit.
so i want only to read the correct response and ignore others !
I know correct value starts with a specific value, so when ever there is a response starting with the specific value, I read it else I ignore it.
Now for the responses which I get for wrong combination donot start with a specific value so I ignore them hence they get accumulated in the buffer, now when the correct combination is reached and I try to read the response it starts with previous junk values as this response doesnot start with my specific value so it gets ignored in way I lose my correct response also, so I want to clear the buffer befor I send my command.
Thanks !