Buffers in Oshonsoft

rjenkinsgb said:

A lot of it is internal and hidden from program access, or irrelevant for normal use.

The UART has a small FIFO (first-in, first-out) buffer, probably from two to four characters depending on the device.

All you need to see from the program is that it has data available; if so, read the data and check again within one character time.

The FIFO behind that just means that the new character check timing is less critical, so occasionally being a bit late does not mean a character lost or overrun, as long as you usually check in less that the character-to-character time at whatever baud rate is in use.

[Think of it as a bucket line - an unbuffered UART has one bucket man; you have to take it before the next character is received and passed to him.

With the FIFO, there are 1, 2, 3 or whatever additional bucket men, but you only deal with the last.
As long as the line does not fill up, you can eg. miss one time then take two the next.]

Click to expand...

rjenkinsgb said:

The internal register arrangement is shown in the PIC datasheet, but the FIFO part is pretty much a buried feature. The simulation is pretty good!

Click to expand...

camerart said:

sometimes I notice B is missed out, I assume it's just how the FIFO acts?

Click to expand...

rjenkinsgb said:

Yes, if there is more than one empty position in the FIFO, a new character will pass straight through to the last available space.

Click to expand...

tumbleweed said:

On all the 8-bit PICs there's a two-byte input buffer/FIFO (shown there as RxBuffer 1 and RxBuffer 2).

RX data bits come into the RX Shift Register, and as soon as a complete byte comes in it's immediately transferred to the input buffer. If both RxBuffer1 and RxBuffer2 are full when that third byte completes you get an overrun error (OERR), and reception stops until you clear the overrun.

The RX Shift Register is internal... you can't access it (but since it's a simulator it shows up).

Click to expand...

tumbleweed said:

Once an OERR happens the UART quits accepting chars, so you don't have much choice but to throw out any partial message you already have and start again since you don't know what has been dropped.

Framing errors (FERR) aren't that bad... the UART continues to work as normal so you don't have to reset the UART. You get FERR when the receiver goes to look for a STOP bit and it sees a '0' instead of a '1'. It's typically an indication of a baudrate or protocol setting mismatch (number of bits, parity, etc).
Even though it doesn't stop the UART "working", in the end you probably want to do the same thing as an OERR since there's likely a basic communications problem

Click to expand...