FIFO buffer value in USART receive block

[broderic]

Hello.
I'm practicing USART with the compiler, and I can't understand how and where the compiler puts the 2 values of the 2 byte buffer in some registers (for instance I saw that these values appears in 00C9 and 00CA location of internal model data when simulating an USART reception with Proteus).

I also look at the related Positron assembler listing, but I didn't find any assignment to some register of these 2 deep buffer values; nevertheless I saw them in Proteus simulation at the locations above...

Thank you for any clarification.
Regards

[John Drew]

Which device Broderick?
John

[broderic]

Hello John, thank you.

For instance, this small code, sending data via Virtual terminal (I don't need for the moment to use Hserin, I only look at the content of the receive RGREG):

Device 16F876A               
Declare Xtal = 10            '10MHz crystal
Declare Hserial_Baud = 38400 'Set Baud rate to 38400 for HSerin and HSerout
Declare Create_Coff = On
Dim i      As      Byte=0                    ;counter
Main:
   For i = 0 To 255   Step i     
   Next
 GoTo Main

Sorry for the code not in code style, but I don't know why I can't see the advanced editing...:-)

Thanks

[top204]

You cannot access the USART buffer directly, it is a hardware buffer, so reading the RCREG twice will produce the 2 bytes received, if 2 bytes were received.

The variable that RCREG is loaded into is where they will be stored. If multiple bytes are to be received, receive them into a byte array.

[trastikata]

Main:
   For i = 0 To 255   Step i     
   Next
 GoTo Main

Interesting way of creating an infinite loop 

[broderic]

First of all, thank you Les, trastikata, for your kind explanation and attention.

I know that FIFO buffer values are internal and not directly accessible, but my concern was to understand how and where the compiler put them in some address of Proteus debug Internal model data.
For instance, when I simulate with Proteus this code, with 123<CR>input in PIC RX:

Code Select Expand

'Code 9-2A from MBASIC Jack R.Smith pag175 ,adapted to Positron compiler.
'Numbers from 0 to 9 are typed, echoed and stored in array variable.
'Simulation can be done in Proteus sample MCP9800 Thermal sensor PICtail.pdsprj
'loading the .cof file. Debug is visible if starting simulation with pause is done.
'Application can be done in Easypic V7 connected to PC via USB UART.
Device 16F876A                   
Declare Xtal = 10            '10MHz crystal
Declare Hserial_Baud = 38400 'Set Baud rate to 38400 for HSerin and HSerout
Declare Create_Coff = On
TRISB.0=0
;Constants
;-------------
Dim MaxStrSize    As        12          ;string length (it is not a real strig but an array)
;Variables
;------------
Dim i        As        Byte=0                        ;counter
Dim j        As        Byte=0                        ;counter
Dim InStr[MaxStrSize] As Byte
Dim InByte    As    Byte                ;input byte

Main:
    For i = 0 To 255    Step i    ;dummy loop to simulate other activity (monitoring temperature, ...)
        CheckInput()
    Next
 GoTo Main
 
Sub CheckInput
Inserie:
 
 DelayUS 1000                ;2-byte RCREG buffer + RSR byte allows only first 2 byte regular
                            ;reception accumulation(for instance 1<CR>)if in the meantime
                            ;no RCREG reading is performed before the stop bit arrives in RSR.
                            ;Any further number requires delay time reduction so thus RCREG
                            ;is made empty on time for the new incoming bytes from the PC.
 
             
 ;HSerOut [RCREG]          ;Echo back to monitor.   
    InStr[j] = InByte
        j = j+1
    If j = (MaxStrSize-1) Then
        j=0
    EndIf
    PORTB.0=RCSTA.1            ;overflow OERR can be checked by the light up of RB.0
 If InByte = 13 Then
    If j>0 Then
      j=j-1
    EndIf
    GoSub CRReceived
  EndIf
 GoTo Inserie
EndSub

CRReceived:
    HSerOut ["Chars Received: ",Dec j,13]
    If j > 0 Then   
        HSerOut ["Complete Line Received: ",Str InStr\3,13] ;"Instr\variable" not allowed
    Else
        HSerOut ["CR only",13]
    EndIf
    j = 0
 Return
End       

I have the enclosed debug windows, where FIFO[0] and FIFO[1] are 0x31 and 0x32 (that is ASCII 1 and 2), and they appear at location 00C9 and 00CA during debug.
So I suppose that the compiler, somewhere, output them in those locations, but when and where?
Because I should see this in Positron assembly list, but I miss it.
I know that it is not fundamental :-), but just to understand.

Many thanks
Regards

[trastikata]

I have the enclosed debug windows, where FIFO[0] and FIFO[1] are 0x31 and 0x32 (that is ASCII 1 and 2), and they appear at location 00C9 and 00CA during debug.
So I suppose that the compiler, somewhere, output them in those locations, but when and where?

You don't have any USART RX related code in your example, thus the Positron doesn't handle any USART RX related registers.

Besides I wouldn't trust Proteus internal model data, the datasheet says the RCREG FIFO address is 1A and you see changing 00C9 and 00CA?

[broderic]

Hello trastikata.

I guess that you don't need any USART code (like Hserin..) to fill up FIFO during reception in PIC from PC.
I guess it's enough that the compiler tells that the related pins are used for USART (by USART configuration, SPEN and so on).
And you can see that FIFO buffer is filled up as well as RCREG (yes at address 1A), that is the upper byte or the FIFO.
What will happen, if I don't empty the RCREG, is simply an overflow when the stop bit occurs in RSR at third byte transmission.

But, and this is my curiosity, in location C9 and CA  (they seem GPR of bank1)"someone" put the two values of FIFO, as you can see in my screenshot.
Who is this "someone"?
Proteus or Positron?

Thanks

[broderic]

Since I have the same behaviour with a Proteus simulation of an equivalent code in pure Assembly language, I believe that the two values of FIFO buffer are put in Internal Model Data by Proteus itself, together with the log notification (I don't know the purpose, perhaps for the simulation...).

I'm still doubtful, in general, about the contents of Internal Model Data table, visible during debug (what is it for?).

Regards

[top204]

When reading or writing USARTS, the compiler just reads or writes the SFRs. It does not store anything anywhere else. You can see this by the assembler code for the commands:

Code Select Expand

__hrsin1__
    btfss PIR1,PP_RCIF
    bra $ - 2
__hrsin_getbyte__
    movf RCREG,W
    bsf STATUS,0
    return

__hrsout1__
    btfss PIR1,PP_TXIF
    bra $ - 2
    movwf TXREG
    return

Never trust simulators 100%. They can be useful, but they can also give false reading to state "the code will work flawlessly", but in the real world the code fails miserably, and vice-versa.

I have created the compilers assembler code so it is very clear to read and understand.

My dad always had a good statement for that and is how he taught me: "It might look good on paper, but that doesn't mean it will work in the real world, so never trust it until it is tested and proved to work, and proved to work well!". :-)

[broderic]

Many thanks, Les!

That's why I like this compiler, because you can simply see what it does through assembly steps.
I also agree that simulation must not be trusted 100%, but I also like Proteus, because with the debug tool help me to understand my errors.
In this case I was curious to clear up my mind on how the USARt receive FIFO buffer was handled, since it's not directly accessible and visible. How and when the overflow occured and so on.

Thank you very much to you ...and to your wise dad.
There's a saying that goes: " The apple falls not far from the tree".
I'll make treasure of his taught :-).

Regards