defragster
Senior Member+
Ah yes, that's a very good point. This probably needs to be done with another level of callback, where the EventResponder calls a function within the HardwareSerial class. Then that function calls serialEvent(), and after the serialEvent() function returns, if there's still data in the receive buffer after the user's serialEvent ran, it would again trigger the EventResponder to repeat this process on the next yield (or on some near-future yield).
...
If I followed that … "have data will callback" … when the user is reading data at some point in queue maintenance will be cases like these where added code could flag - disableSerialEvents ::
>> if (head == tail) return -1;
>> rx_buffer_tail_ = tail;
That would add code to a few places.
Or perhaps the system runs as it does and without extra code or effort the buffer goes empty :: (head == tail)
The next yield test calls - the one after it went empty and the first test split out ::
Code:
int HardwareSerial::available(void)
{
uint32_t head, tail;
head = rx_buffer_head_;
tail = rx_buffer_tail_;
[U][B]if (head == tail) { disableSerialEvents(); return 0; }[/B][/U]
else if (head > tail) return head - tail;
return rx_buffer_total_size_ + head - tail;
}
This would mean just one call after going empty, but on a busy port data may arrive time between yield() checks and this case would not be met and new data would be distributed.