Hi,
- but if you don't read that first byte using HSERIN before receiving a third byte is completed then the second byte will overwrite the first byte in the FIFO receive buffer.
That is not quite correct. When a third "OverRun" byte is received, it (permanently)
locks up the "HSERIN" hardware and is
not saved. However, the two bytes already in the buffer/FIFO can be recovered, but the hardware will still
not receive any more bytes.
Thus there is a useful "trick", that if you are (still) receiving bytes into the buffer, there is no need to check the OverRun flag (so that's something that only needs to be done whilst the program is waiting for a byte to arrive).
The only way to restart reception is to Disable the hardware and then Re-Enable it. Unfortunately, it appears the PICaxe HSERIN firmware does this too enthusiastically (i.e. even when it is not needed), sometimes whilst a subsequent byte is being received. That appears to be the source of the "HSERIN Bug" which often prevents it receiving even a
second byte reliably (see my link in #7). However, reading the buffer directly with a PEEKSFR command is just as efficient as using the HSERIN command, because both methods
must first test that a byte has actually been received, before the buffer (or the returned value) is actually used.
Finally a word of warning, that I've now discovered that the 08M2 runs about 10% faster than the 14M2 when executing this particular type of code. So if the OP is planning to change to a 14M2, it would be wise to check the reliability of your "time-critical" code using that chip (or a 20M2) not an 08M2.
Cheers, Alan.