views:

177

answers:

2

Hello. I'm facing a particular issue that regards serial communication under win32. I'm communicating with a device can only accept frames when it is not already communicating. So I must find a valid frame and then inmediatelly send my request.

I developed a class named Serial that handles basic operations on serial port (open, close, read, write) and then a Thread calls inside a loop read and write functions.

Thread loop

//Device is an object of class Serial
while( device->isOpen() && !terminate )
{
    unsigned int readed = 0;
    unsigned long error = ERROR_SUCCESS;
    unsigned char* data = device->read( &readed, &error );

    if( error==ERROR_SUCCESS )
    {
        //If data received, deliver to upper level
        if( readed>0 )
        {
            QByteArray output( (const char*)data, (signed int)readed );
            emit dataArrived( output, readed );
        }
    }
    else
    {
         //unrelated stuff
    }

    //Here I manage the writting issue
    //Only when nothing is received, and Upper layer wants to send a frame
    //(Upper layer only will mark as something to send when it detects a valid frame)
    if( readed==0 )
    {
         out_lock.lock();
         //If something to send...
         if( something_to_send > 0 )
         {
            if( device->write( output_buffer, output_size, &error ) )
            { //things...
            }
         }
     }
}

The Thread basically keeps reading, and when nothing is received, sees if somebody has signaled to send a frame (this means that a valid frame is just received). When this happens, it writes the frame through serial port.

Here comes my problem. Inside the Serial::read() function:
I use the overlapped way of reading:

::ClearCommError( handle, &dwErrors, &stat);
if( stat.cbInQue )
{
    //If there's something to read, read it, please note the bytes to read parameter, here 1.
    bool ok = ::ReadFile( handle, buffer_in, 1, &bytes_read, &ov_reader );
    if( !ok )
    {
         DWORD _error = ::GetLastError();
         if( _error == ERROR_IO_PENDING )
         {
             DWORD result = ::WaitForMultipleObjects( 2, waiters, FALSE,INFINITE );
             switch( result )
             {     //Eventshutdown
                   case WAIT_OBJECT_0:  /*code omitted*/break;
                   case WAIT_OBJECT_0+1:   ok = ::GetOverlappedResult( handle, &ov_reader, &bytes_read, true );
                                           //check ok value omitted
                                           break;
             } 
         } 
    }
}

if( bytes_read>0 )
{
   *size = bytes_read;
}

Here starts my problem. When device sends me small frames (around 30 bytes) everything works fine, but when larger frames are sent, the code is not able to find any free time between frames causing the thread to never be able send any frame because readed is never 0.

If I increase the number of bytes to read inside the read() function, lose the ability to detect when the device "listens": bool ok = ::ReadFile(handle, buffer_in, 50, &bytes_read, &ov_reader ); This happens because my app can receive the end of a frame together with the start of the next one. This behaviour is very common.

In the other hand, if I change the INFINITE argument by a valid timeout in the WaitForMultipleObjects function, I lose data.

So my question basically is... what I'm doing wrong? Why when reading 1 byte each time I don't find any free time to send my own frames?

Thank you

+1  A: 

How big are the "larger frames?" When you call ReadFile one byte at a time, it will obviously take a long time to work through the whole frame, probably longer than it takes the send the frame itself due to call-overhead.

Some alternatives:

  1. Does the device send frames whenever it feels like it? If you have the opportunity to design both ends of the protocol, can you switch to a command/response style of communication?

  2. Can you, from the start of the packet, predict the number of characters in the rest of the packet? If so, you could build a state machine into your read function. You could poll one byte at a time, then when you detect the start of the packet read most of the rest of the packet on one call, then switch back to a byte at a time.

  3. Can you use DSR/CTS to control the timing?

In general, it's really hard to read whole packets from within a serial-port read function. The usual procedure is the read a bunch of characters and pass them up to a higher level for protocol parsing. It sounds like you have to have tighter timing control than that method allows though. Good luck...

mtrw
with larger frames I meant around 90 bytes... that's not very big I know...1. The device sends its state at regular intervals2. Second byte contains the length of the frame3. I don't know :( I will investigate it.
clinisbut
+2  A: 

I'm not sure if this will help or not, but since you already have a good idea of how many bytes are in the serial device's input queue (stat.cbInQue) maybe it would help to read in that many bytes instead of just 1 byte or an arbitrary number of bytes (like 50):

bool ok = ::ReadFile( handle, buffer_in, stat.cbInQue, &bytes_read, &ov_reader );

Of course, you'd need to make sure that the buffer_in had the capacity for that number of bytes, so there might be some other logic you'd have to add to make sure there's no buffer overruns.

Also, because the serial driver and ReadFile() APIs depend heavily on buffering for handling received characters, you might be able to get more precise indications of when characters have been received (and not received) using the WaitCommEvent() and SetCommMask() APIs.

Michael Burr
Good idea, I will try this (using the stat.cbInQue)
clinisbut
Ok, I've tried and it seems it works fine. So I will check as a accepter answer, even others have very valuable information.
clinisbut