none
How to tell when serial data is completely sent (out of UART)? RRS feed

  • Question

  • Hi,

    We're porting a proprietary communications protocol over to a WinCE platform.

    The problem we have run into that we just haven't been able to find a reliable answer to is how to tell when serial data has been completely transmitted?

    Hardware UARTs always have a way to tell if the FIFO and transmitter is empty, but we have not been able to find a reliable way to do this in WinCE yet.

    Any help/suggestions would be much appreciated.

    Thanks!

     

    Wednesday, August 4, 2010 11:31 PM

All replies

  • Sounds like you need to modify the driver to read that hardware UART that is able to tell you when it is empty.  Then you may need to add an IOCTL, or just modify XXX_Write to only return when the FIFO is empty.
    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com
    Thursday, August 5, 2010 1:29 PM
    Moderator
  • Sounds like you need to modify the driver to read that hardware UART that is able to tell you when it is empty.  Then you may need to add an IOCTL, or just modify XXX_Write to only return when the FIFO is empty.
    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    Thanks Bruce, I hadn't thought of that.  Makes perfect sense and would probably be the most straight-forward way to solve the problem.

    I'm a bit surprised though that there isn't a way to do this through the "standard" WinCE serial port interfaces.

    Matt

    Thursday, August 5, 2010 2:15 PM
  • Why are you surprised?  Applications don't usually need to even know that there is a FIFO, let alone know when it is empty.
    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com
    Thursday, August 5, 2010 2:30 PM
    Moderator
  • There is a way, although many drivers don't implement it (or don't implement it correctly given the FIFO):

    IOCTL_SERIAL_GET_COMMSTATUS

    Take a look at how the driver implements that in mdd.c.  If you could look at the transmit FIFO status and not return 0 for

    cbOutQue until the FIFO was also empty, you'd have what you want.  Of course, any third-party applications might not expect that.  Total safety is gained by creating your own IOCTL.

    Paul T.

    Friday, August 6, 2010 4:22 PM
  • Why do you want to know?

    If you want to do it to turn off an RS485 transmitter accurately, you can't do it...

     

    Monday, August 9, 2010 6:21 AM
  • When serial data is fully transmitted your XXX_Read(), XXX_Write() shall return with no of bytes read/written.

    The simplest way could be return XXX_Read(), XXX_Write() function with a particular return status based on the status of FIFO read register.

     

    Read the comm status register with every data transmission (read/write) using an ioctal could be another solution to the same. 

     

    Ioctl "IOCTL_SERIAL_GET_COMMSTATUS" is what i know we have for this.

     

    regards,

    Misbah 

    Wednesday, August 11, 2010 9:11 AM
  • As I mentioned, you have to be careful about assumptions.  Most of the serial drivers will simply drop the outgoing data into the transmit *buffer* and return the number added to that buffer.  There could be handshaking in operation and that data might *never* be sent, if the external device has told us not to transmit.  The same can be true of IOCTL_SERIAL_GET_COMMSTATUS which has in the past been quite buggy because the sample driver from MS did it wrong and it does not check for the FIFO actually being empty.  Even if the FIFO is empty, that's not an indication that *all* of the data has been sent, as the transmit register still holds one byte and if we're in a don't-send condition because of handshaking, we might never send that last byte.

    Paul T.

    Wednesday, August 11, 2010 3:46 PM