Buffers in Oshonsoft

[camerart]

Hi,
When reading the RX pin with an incoming STRING of serial text, can someone explain in a little detail, where each CHAR would be in the CODE and Simulator HW UART box, please?
Here's an image with ABC and D.
C.

 

[rjenkinsgb]

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.]

 

[camerart]

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.]

Hi R,
As I rely on the Simulator, while watching the register BITs, I am particualarty interested in the ABCD on the #1 image. I can watch the CHARs arrive at A, then move to B and so on, while others are arriving, and try to analyse how things are working.

If this is all hidden, and nobody other that Vladimir know, then I will leave it there.
Thanks, C.

 

[rjenkinsgb]

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!

 

[camerart]

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!

Hi R,
When simulating, I watch the CHARS going though the image #1 and try to step through, and watch both the program and buffer, sometimes I notice B is missed out, I assume it's just how the FIFO acts?
C

 

[rjenkinsgb]

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

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

 

[camerart]

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

Hi R,
Ok, thanks.
C

 

[tumbleweed]

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).

 

[camerart]

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).

Hi T,
If the OERR is cleared, I assume it has to start again from, in this case '$' ?
C.

 

[tumbleweed]

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

 

[camerart]

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

Hi T,
Ok, noted, thanks.
C