Matrix user forums

Hello all - Long time no speak (FC7 serving us well )

I haven't filed this under a bug report, though an observation perhaps worthy of consideration...

Using an ECIO40P module, I configure the USB port for USB Serial (VCOM). Serial data originates from a 2D barcode reader, natively at 9.6kbps, sent via PuTTY from the host PC to the PIC.

In a loop I await a string (i.e. 'GetString[80]', with a very generous 200ms timeout declared in the component macro, and 80-char string var length considerably in excess of the expected string. GetString[0] is also forced to '0' (null) immediately before the loop.

Expecting that the Flowcode function will wait up to 200ms to register completion of the received string (i.e. after the last character received, of indeterminate length up to the maximum of 80 chars), I set the loop to exit when... (GetString[0] > 0).

The loop waits for an incoming string sure enough, but inexplicably exits after only the first received character - regardless of string length from the reader. I did however expect that the get-string function would continue to wait inside the loop and not exit before 200ms had elapsed with no further characters received.

Processing and building the incoming string Byte-wise however (i.e. until TempChar = 255, with a timeout of only 50ms) works flawlwessly, confirming absence of excessive pauses between characters causing the foregoing observation with string-based timeout.

Does this therefore suggest an issue with the declared timeout when awaiting an incoming string via USB serial, or is it the intention that the timeout only applies to the wait period before the first character - in which case, what timeout applies to the end of the string if less than max length?

Thanks and best regards,
Brendan

Hi Brendan,

The ReadString for PIC simply calls the Microchip library function to read a string from the USB data buffer. You're right in that there is no additional timeout once we have received something. A USB packet can contain a number of bytes and so we pull the string out of the packet. If your typing data on say a terminal then each character will likely be sent in a separate packet and so the ReadString will only pick up a single byte.

As you say I'm not sure if this is a bug or not, we could do an additional wait for more data but this would likely add more complexity to the code.

Thanks Ben (sorry I've taken a while to reply).

Understood and duly noted.

Certainly no hardship to process incoming data Byte-wise and build a string in the loop, and I like to avoid all unnecessary complications. Understanding the issue better, we'll just stick with that approach for all USB232 Rx data

All the best,
Brendan