adrianfreed
commented
2 months ago I am confused. -1 is not a valid value for an unsigned int. Also 255 is a potentially valid character in a slip stream so I can't be used this way.
From: Geoff Evans @.> Sent: Thursday, April 25, 2024 10:35 PM To: CNMAT/OSC @.> Cc: Subscribed @.***> Subject: [CNMAT/OSC] Teensy Large buffer overflow being ignored (Issue #146)
Been working on a project now for a bit and been having issues with commands not being completed until more data flows in.
The project is an ETC EOS encoder board programming is around the softkeys, 12 OSC strings that are sent quickly one after another the data is there it just wont show as available.
I now have finally tracked down the the issue and its with how the Teensy reports the number of bytes available when the buffer has gone beyond one packet.
Which leads me to the fix. Teensy after you have read the first chunk of data available will report a < 0 and as such it cant continue reading data. However calling peek will not report a -1 it will return the next byte of data you can continue to read the bytes this way until a -1 is reported or a 255 and this seems to be the only way to effectively return all the data in these instances as with the current code the next packet sent from the computer will set the buffer size to the value of that packet so data just keeps on backing up and not clearing.
Below is the code I changed to SLIPSerial.
92 uint8_t cnt = serial->available(); changed to uint8_t cnt; uint8_t peek = serial->peek(); if (peek == -1 || peek == 255){ cnt = 0; }else{ cnt = 1; }
77 if(serial->available()) changed to if(serial->peek() >= 0)
I can submit a pull request but want to check first if your happy for this as is or if you would like some defines to make this only work on teensy or another way entirely.
— Reply to this email directly, view it on GitHubhttps://github.com/CNMAT/OSC/issues/146, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAMMDDEQG4CKWZ7DGUH3KRLY7HRT7AVCNFSM6AAAAABG2EKPRSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3DIOJZG44DMMQ. You are receiving this because you are subscribed to this thread.Message ID: @.***>
geocom
Been working on a project now for a bit and been having issues with commands not being completed until more data flows in.
The project is an ETC EOS encoder board programming is around the softkeys, 12 OSC strings that are sent quickly one after another the data is there it just wont show as available.
I now have finally tracked down the the issue and its with how the Teensy reports the number of bytes available when the buffer has gone beyond one packet.
Which leads me to the fix. Teensy after you have read the first chunk of data available will report a < 0 and as such it cant continue reading data. However calling peek will not report a -1 it will return the next byte of data you can continue to read the bytes this way until a -1 is reported or a 255 and this seems to be the only way to effectively return all the data in these instances as with the current code the next packet sent from the computer will set the buffer size to the value of that packet so data just keeps on backing up and not clearing.
Below is the code I changed to SLIPSerial.
92
uint8_t cnt = serial->available();changed touint8_t cnt; uint8_t peek = serial->peek(); if (peek == -1 || peek == 255){ cnt = 0; }else{ cnt = 1; }77
if(serial->available())changed toif(serial->peek() >= 0)I can submit a pull request but want to check first if your happy for this as is or if you would like some defines to make this only work on teensy or another way entirely.