Serial device hell

[Aaron_Hunt]

@455386:@Mark Carlton

as Derk has stated, this is not a buffering issue, the DataAvailable event fires at some point the OS decides and presents the information currently in the buffer to you at that time, this does not mean the data being sent is not still there, just that the event fired while it was coming in, if you ReadAll at that point then you are most unlikely to get valid complete data, as you are seemingly expecting … it is not possible to expect the serial port to know exactly what data you wish to be available in the format you want, it is not psychic.

Gosh, I thought the serial port was psychic. That must be the root of all my problems here. Thanks for clearing that up, I really appreciate that.

So it’s not a “buffering” issue, so what? It’s still an issue. The missing bytes aren’t there. They aren’t available in the DataAvailable event, and they aren’t listed in BytesAvailable property. The DataAvailable event fires, I use this code at the start of it:

dim x as string 
while me.BytesAvailable > 0
  x = x + me.ReadAll
  me.Poll
wend
// now work with x

So where are the missing bytes?

[quote=455386:@Mark Carlton]in my serial system I use LookAhead to search for the END OF FILE character my protocol uses, and then ReadAll the data out.

… the DataAvailable event is an OS event which has absolutely nothing to do with the data you send as such, its an event that fires when anything is in the buffer at the OS time to set that event happens, I suppose something like ‘its time to fire the serial event, is there anything in the buffer YES>fire event, NO>do nothing’

this is the logic I use to deal with my long standing and perfectly operating serial port based module that is used in every one of my serial port device based applications which are across all the available platforms.
[/quote]

I’m glad your code is successful. You and others here seem to have missed what I said earlier, namely that I am reading raw bytes from FLASH memory, and there is no signal byte to let me know where the end of the response is, since there doesn’t need to be an end byte – I know how many bytes I have requested to read, and I should get that many bytes back. I’ve said, it doesn’t work reliably for more than 32 bytes at a time, although it is supposed to work with up to 256 bytes at a time, and it did just that before with the FTDI driver, although that driver sometimes caused a bizarre duplicated port, screwing the whole system.

I send a request to read bytes, the request is acknowledged, I send an address, the address is acknowledged, I send a length to read, the length is acknowledged, and then the bytes are supposed to be sent back to me. The chip sends the bytes, but they don’t always all appear in the DataAvailable event.

So I’d like to know how I’m supposed to get the missing bytes when they don’t appear in the DataAvailable event.