Rif.: LabWindows ComPort Receiving nulls

[DirkBr]

I am using  a ComPortCallback to read data from a device com port.  The input data contains nulls within a string.  It appears that when I read the input buffer < ComRd(); >, the transfer stops at the first null.  In order to read the rest of the string, I have to read again using ComRd().  Is there a mechanism to read the buffer without terminating on the nulls?

[RobertoBozzolo]

It seems strange to me what you are saying about ComRd command: I am constantly using it to transfer binary data (with embedded NUL characters) without major issues. ComRd read the exact number of bytes you tell to it, except in case of timeout -which does not seem your situation.

May it be happening that after reading from the COM port you are treating the received buffer with string-oriented functions (strlen, strcpy and so on)? In this case please note that  these functions stop handling the buffer at the forst NUL byte.

Can you post some code snippet that shows port reading and following buffer handling?

[DirkBr]

InstallComCallback(comPort, LWRS_RECEIVE, 34, 0, ComPortCallback, 0);

void ComPortCallback(int COMPort, int eventMask, void *callbackData)

{

     unsigned int length, nbytes;

     unsigned char buf[1028];

     unsigned int i, checksum, ch;

    SetComTime(COMPort, 1.0);

     ch = ComRdByte(COMPort);

     if(ch == 0x7e) // Start Delimiter

     {

         length = ComRdByte(COMPort) << 8;

         length |= ComRdByte(COMPort);

         nbytes = ComRd(COMPort, buf, length+1);

         checksum = 0;

         for(i = 0; i < length+1; i++) // Test Checksum

             checksum += buf[i];

         checksum &= 0xff;

         if(checksum == 0xff)

             ProcessAPI(buf);

     }

     else

     { // Thru debug trace, found to be entering the else when null encountered.

         FlushInQ(COMPort); 

         Beep();

     }

}

[menchar]

Well, the way you have it coded, it will go to your   else  block if you ever do receive a NUL 'cause it won't be a 0x7e.

So it seems that the question to ask is why is the sender sending NULs?  If the sender is allowed to do this, then you need to change your code to skip the NUL's and sync up with the start of the message.

Or, it could be the NUL's are sitting in the InQueue, do you flush the InQ before you start? 

A better way to do this might be to have the callback invoked on receipt of your start delimiter - that way you sync up to the start of your incoming message automatically (the serial driver does it for you).  Use   LWRS_RXFLAG.   Is the start delimiter unique in the incoming byte stream?

The checksum logic looks confusing - is the checksum carried in the message itself, or do you somehow know that the checksum is always 0xff?

Reading variable length binary messages can be tough - many serial message schemes use all ASCII for the data, and use a unique message termination character such as a linefeed.