baloney … another selfish attempt…
Robin’s code for flushing does exactly what it says it does, : it empties the Serial input buffer. There was no other promise done.
If you interpret things, You don’t flush correctly either, you have a canned 1s timeout and you have no clue what’s sending the information on the other side. You could still have incoming data that has not been emitted yet or a noisy line… So any bet is as good as any other. Blindly flushing the input is also a risk of getting rid of one meaningful input.
The way to deal with input is to have a documented protocol that lets you get in sync with the sender and reject malformed input. The parser should deal with this. For example You read until the end marker and you look for coherence (use a CRC, assess if all the fields are there, are of meaningful values, check length, etc…) or If you have both a start and end marker then use also that to get in sync.
The knowledge of the case at hand and understanding of how the buffering works is what developers need to have. That’s exactly what Robin’s tutorial conveys. At the end of the day the A in UART , stands for Asynchronous (Universal Asynchronous Receiver Transmitter), trying to second guess a timing for something asynchronous is a recipe for failure, you need to add a way to get in sync + verify input coherence depending on your application.
In my. Opinion That’s why there is no input flushing method to the Serial class, there is nothing generic that can guarantee to work in all possible scenarios.