)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
