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

This is a discussion on Serial port: How to know when data has been completely sent within the Windows Programming forums, part of the Platform Specific Boards category; Suppose I have a thread sending bytes out the serial port(COM1: That 9pin D connector). Suppose I have to keep ...

  1. #1
    ... arjunajay's Avatar
    Join Date
    May 2005
    Posts
    203

    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

  2. #2
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,671
    What flow control are you using?

    gg

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #4
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,671
    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

  5. #5
    ... arjunajay's Avatar
    Join Date
    May 2005
    Posts
    203
    Quote Originally Posted by Codeplug View Post
    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...

  6. #6
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,671
    >> 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

  7. #7
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    Quote Originally Posted by arjunajay View Post
    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...
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  8. #8
    ... arjunajay's Avatar
    Join Date
    May 2005
    Posts
    203
    Thanks guys,
    Quote Originally Posted by Codeplug View Post
    >> 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.
    Last edited by arjunajay; 03-25-2009 at 07:34 AM. Reason: didn't know what overlapped io was...

  9. #9
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,671
    >> 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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Serial Port Questions
    By valaris in forum Tech Board
    Replies: 2
    Last Post: 05-22-2009, 08:26 AM
  2. Serial Port Issues (again!)
    By HalNineThousand in forum Linux Programming
    Replies: 6
    Last Post: 04-09-2008, 08:26 PM
  3. HELP with storing serial port data into txt file
    By inmaterichard in forum C Programming
    Replies: 2
    Last Post: 04-02-2008, 02:20 AM
  4. brace-enclosed error
    By jdc18 in forum C++ Programming
    Replies: 53
    Last Post: 05-03-2007, 05:49 PM
  5. Warnings, warnings, warnings?
    By spentdome in forum C Programming
    Replies: 25
    Last Post: 05-27-2002, 06:49 PM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21