Serial port: How to know when data has been completely sent

Suppose I have a thread sending bytes out the serial port(COM1: That 9pin D connector). Suppose I have to keep sending something or the other continuously because I cannot keep the medium idle because my wireless system requires that some thing be present all the time...
So I want to continuously send zeroes if any other data is not there. But I cannot just fill the buffer with tons of zeroes because I don't know whether the previous filler zeroes that I tried to send have been sent completely.
Note: I am currently using CreateFile() ReadFile() and WriteFile() functions.

Question:
1) How do I know whether the data I pushed in have been completely sent so that I can fill zeroes/send data if that is available?
2)Is there any way to get the OS to call a callback fn when data previously pushed has been sent so that I can fill new data

What flow control are you using?

gg

Since you don't know when another packet will be available to send, you would have to continuously write fill-pattern whenever you don't have anything to send. As long as your "fill" is short enough (say 16 bytes), it will not put MUCH delay on the transmission of another packet. So every time you have nothing to send and you have returned from the WriteFile() function [or the WaitForXXXEvent function if you use asynchronous completion], you send a "fill" packet.

--
Mats

Well, the COMMTIMEOUTS settings and the flow-control also play a part.

If the write timeouts are 0 (not used) then a write operation "completes" once the driver has the data. Then you would have to poll ClearCommError() until COMSTAT.cbOutQue is 0.

If write timeouts are non-0, then a write operation "completes" once the data is "out the door" (meaning COMSTAT.cbOutQue is 0). If you are also using hardware flow-control, then you know that the other end has received the data at the hardware level. If there is no flow-control, then there is no telling if the data "went" anywhere, or worse, if the other end is being "flooded".

gg

Quote:

---

Originally Posted by Codeplug

What flow control are you using?

gg

---

I don't completely understand. It is one way communication. I'm following some tutorials from some pages and they just say that there are two types of flow control hardware and software.

So basically all I need to do is set COMMINTIMEOUTS to some delay and It will make the WriteFile to blocking mode.
Or
I can make WriteFile non blocking and instead do something like

Code:

---

do{
ClearCommError(hSerial,  &lpError, &COMSTAT)
}while(COMSTAT.cbOutQue is 0);

---

right?
Thanks for the replies...

>> I don't completely understand.
Well, that's one of the things you setup in your DCB structure. Are you setting up your DCB structure and calling SetCommState()? Do you open the port with FILE_FLAG_OVERLAPPED?

>> So basically all I need to do is set COMMINTIMEOUTS to some delay ...
Basically, yes.

>> It will make the WriteFile to blocking mode.
"Blocking" in the sense that it won't return until the UART has transmitted those bytes - yeah. Only if you did not open the port with FILE_FLAG_OVERLAPPED. If you did, then the write isn't complete until the overlapped event is signaled.

>> I can make WriteFile non blocking and instead do something like
Well, setting the write-timeout to 0 may not be exactly the same as non-blocking (WriteFile returns immediately), but it may be.

Spinning on ClearCommError() is the last thing you want to do.

gg

Quote:

---

Originally Posted by arjunajay

I don't completely understand. It is one way communication..

---

You still need some feedback from other side to know if it has space in the incoming buffer to accept the next byte or not. This feedback is provided by the flowcontrol.

If the hardware flowcontrol is enabled on both sides - you application should just check the state of the com-port before sending to know if write is permitted now...

Thanks guys,

Quote:

---

Originally Posted by Codeplug

>> I don't completely understand.
Well, that's one of the things you setup in your DCB structure. Are you setting up your DCB structure and calling SetCommState()? Do you open the port with FILE_FLAG_OVERLAPPED?
>> It will make the WriteFile to blocking mode.
"Blocking" in the sense that it won't return until the UART has transmitted those bytes - yeah. Only if you did not open the port with FILE_FLAG_OVERLAPPED. If you did, then the write isn't complete until the overlapped event is signaled.

---

The tutorial I followed just explained the bare basics. It says to leave other stuff alone. Let me read upon the DCB structure's members and stuff like that.
anyway I don't want Overlapped IO.
edit: Wait If I use overlapped IO+event notifier, I wont need a separate thread for this thing! that would be great!

to vart:
can't take feed back as the rf module with me is one way, and as of now duplex operation is not in scope...

The async IO seems to be a big topic.

>> It says to leave other stuff alone.
That's [very] incorrect information. You should set the timeouts and entire DCB before working with the port.
Serial Communications in Win32

gg