🚀 go-pugleaf

Neil P. wrote:

>> Gambit
>> Your use of CheckCommStatus() to poll the serial port status could be
>> slowing the code down.  If you get rid of it entirely and just let the

>I don't use CheckCommStatus() anywhere in my snippet?

       ClearCommError, same usage problem?

>it sometimes takes more than 3 tries, sometimes more than 10 tries, before
>the unit comes out of the loop.
>The question is why?  The information should be there almost instantly.
>This is my calculations,
>
>9600 baud = 104.16 us per bit, if I am recieving just one byte coming back,
>104.16 uS x 8bits = 833.28 uS

Read my other reply.
At 9600 baud, one character time is  .001042 sec or 1042 uS
You forgot the start and stop bits, 10 total bits per character
(unless you also have parity (+1 bit) or 1.5 or 2 stop bits).

Also, you start reading almost immediately after sending, so the
character you sent hasn't even reached the unit yet.
It should take around 2 ms before you could even begin to expect to
see a return value.

>in my code snippet, I use GetTickCount to start a timer of the number of
>bytes expected and I go ahead and multiply it by 2, so at to give it even
>more time.  So if I am doing things correctly, I should have 833.28uS x 2
>1.66Sec approximately double the time it would take for that byte to
>actually get Windows to pick up the byte and have it ready for me to read
>it?

Again, read my other reply.
Your timing is way off.
If you think you are waiting a full 2ms, think again. On average, your
wait time is 1.5 ms because TickCount has a granularity of 1 ms. So
you could be waiting anywhere from 1.00000001 ms to 1.9999999 ms.
which is still too short as you probably need at least 2.084 ms


>I go a step further and give the application an extra three times to try and
>it still fails?
>
>I don't understand why? Everything tells me the byte should be there and
>maybe it is, but definetly I am doing something terribly wrong in my Read
>snippet, because I am not getting that byte????
>
>Can you guys look at my snippet and see what I am doing wrong, I have no
>idea, I have tried everything I know?

But you haven't tried what we told you.

Also, in reworking this, I noticed you only break out of the while()
on timeout, not on receiving your data.  Also, it might be that your
tight loops didn't leave time for the OS to process the data, hence
the long delay. The Wait function is very efficient in that reguard.

Try this (untested)

void __fastcall Comm::Read(unsigned int iExpected)
{
 iCollectBytes = 0;
 dwActualBytesRead = 0;
 bStop_Read = false;

 OVERLAPPED	o ={0};
 HANDLE	ehRead;
 o.hEvent = ehRead = CreateEvent(NULL,FALSE,FALSE,NULL);
/* add code to check ehRead is valid */

/* I would actually place ehRead in the Comm:: object and
CreateEvent() and CloseHandle() it there. 
 Also a seperate hEvent and OVERLAPPED for writting. */


 // Do we have the handle ?
 if (hComm &&( iExpected <= BUFFSIZE) )
  {
	memset(  bCommData, 0, BUFSIZE*sizeof(bCommData[0] );
	memset(  cTransBuff, 0, BUFSIZE*sizeof(cTransBuff[0] );

          if ( ! ReadFile (hComm,
                         bCommData,
                         iExpected,
                         &dwBytesTransferred,
                         &o))
           {
             // Check if error is Overlapped I/O pending
             if (!(GetLastError() == ERROR_IO_PENDING))
	             ReportError();
           } else {
	if(  WAIT_OBJECT_0 ==
		 WaitForSingleObject( ehRead, 
			5/*at least 3*/+(iExpected*2) ) )
	{
	             GetOverlappedResult(hComm, &o,
	                                 &dwActualBytesRead, FALSE);

	             if (dwActualBytesRead != 0)
	              {
		memcpy( &cTransBuff[iCollectBytes], bCommData,
		      iCollectBytes+dwActualBytesRead <= iExpected?
			 dwActualBytesRead: iExpected-iCollectBytes );
	              };
	}else{
		/* timed out */
	};
        } // End if Read
    } // End if Comm Handle

	CloseHandle( ehRead); /*should be in Comm::destructor*/
}