read_packet needs to check for leftover data in self._buffer

[kevinjwalters]

I've noticed a strange buffering phenomena documented in https://forums.adafruit.com/viewtopic.php?f=60&t=144694

I've had a quick glance at the code but my first guess is this is because read_packet() returns None if there's no data coming back from a presumably non-blocking self.uart_rx(). I think the lack of checking for data leftover in self._buffer from a previous call to read_packet() is the problem. That previous call could have picked up two (or more) commands and read_packet() only returns first by design. I've not executed/single-stepped the code here, i'm just guessing from inspection but it seems to match observed behaviour.

[jerryneedell]

FYI - I have reproduced this using the IOS app as well.
This buffering issue does not appear to occur when using the "rugged echo" example https://github.com/adafruit/Adafruit_CircuitPython_BluefruitSPI/blob/master/examples/bluefruitspi_ruggedechotest.py since that code reads the entire receive buffer where the "muny.py" code from the forum post reads one "packet" but there may be multiple packets in the buffer.
I think the issue is with the "muny.py" example and not with the basic module. The example appears to only be anticipating for single color picker requests, not rapid fire button presses.

[kevinjwalters]

I'm not sure on that. I think any code which deals with a fairly fast or bursty producer and uses read_packet() in a loop will experience this. More so if other things are done in the loop or there are delays meaning that read_packet() isn't hammered away at.

[jerryneedell]

yes, I was just about to correct my post after more testing and thinking about this. It does appear the read_packet is not handling the buffered packets correctly.