0

I am attempting to simulate the PIC18F458 receiving a byte (i.e., ASCII 'Z', 0x5A) through the RX pin, using a SCL file (see below) in MPLAB X v.5.05.

testbench for "pic18f458" is
begin
    process is
        begin
            loop
                RX <= '0';
                wait for 104 us;
                RX <= '0';
                wait for 104 us;
                RX <= '1';
                wait for 104 us;
                RX <= '0';
                wait for 1042 us;
                RX <= '1';
                wait for 104 us;
                RX <= '1';
                wait for 104 us;
                RX <= '0';
                wait for 104 us;
                RX <= '1';
                wait for 104 us;
                RX <= '0';
                wait for 104 us;
                RX <= '1';
                wait for 104 us;            
            end loop;
        wait;
    end process;
end testbench;

Although, I can see that the data is being injected onto the pin, I do not see it being captured within the RCREG register. (Please see images of RX pin waveform and RCREG output below).

RX Pin Waveform

RX Pin Waveform output

RCREG SFR

RCREG SFR

The code is written so that the bits are transferred at 9600 bps and assumes that XTAL = 10 MHz (see code below).

        ORG     0000H           ; burn into ROM starting at 0

        MOVLW   B'10010000'     ; load wreg with 0x90
        MOVWF   RCSTA           ; enable receive and serial port itself
        MOVLW   D'15'           ; load wreg 0xF
        MOVWF   SPBRG           ; 9600 bps (Fosc / (64 * S[peed) - 1)
        BSF     TRISC, RX       ; make RX pin of PORTC an input pin
        CLRF    TRISB           ; make PORTB an output port
; get a byte from the serial port and place it on PORTB
R1      BTFSS   PIR1, RCIF      ; check for ready
        BRA     R1              ; stay in loop
        MOVFF   RCREG, PORTB    ; send value to PORTB
        BRA     R1              ; keep doing that

        END

Therefore, I was wondering at what intervals should I send the bits within the SCL file, so that it can be recognised as a dataframe of bits transmitted at 9600 bps.

My current assumption is that each bit of the frame consisting of a start bit, 8-bit data and a stop bit, should be transmitted every 104us.

However, this is not providing the desired effect, in terms of the RCREG registering the data on the RX pin.

Therefore, I would appreciate any insight that anyone can provide with regards to the correct value(s) to use, as this is my first time trying to do this.

aLoHa
  • 165
  • 7
  • 1
    Have you performed a sanity check for your receive setup? Did you setup an ordinary UART sending 'Z' characters to verify that your PIC can receive such a continuous stream of character frames? Beware: see https://stackoverflow.com/questions/75348835/why-spc-can-resync-characters-in-asynchronous-serial-output#comment132969205_75348835 BTW your descriptions are sloppy /wrong, e.g. "*each dataframe package should be transmitted every 1.042 ns*", and the timing image doesn't clearly indicate units. – sawdust Feb 10 '23 at 21:56
  • Your captured waveform makes no sense, and your code doesn't match it. The shortest states (of unknown duration) represent a single bit. Data frames of `1010110100` can be descerned, but then there are also bit patterns of `111000`! Where is that from??? – sawdust Feb 10 '23 at 22:50
  • 1
    "* I was wondering at what intervals should I send the bits*" -- The answer is simple: Use the baudrate! "*dataframe package*" should be just "frame". "*neither is having the desired effect.*" -- Negative summation is ambiguous, and doesn't provide accurate description. Did you read the warning I mentioned, and do anything about it? Why does the 2nd waveform look different from the first? Did you try a sanity check as I previously mentioned? – sawdust Feb 11 '23 at 05:37
  • Thanks for your input. I am trying to do exactly what you've outlined, albeit quite terribly by all evidence. However, I have attempted to re-word my question to be a bit more clearer and I have added the waveform of the RX pin by itself, which you'll see has the pattern 1010110100 repeated. This is the data byte 0x5A (B'01011010') transmitted with the MSB first; enclosed by a LOW Start bit & a HIGH Stop bit. – aLoHa Feb 11 '23 at 05:53
  • I appreciate the correction on the correct nomenclature to use, as I am still very new to this and just learning as I go along!! However, I have already made the necessary changes with regards to your other comments. – aLoHa Feb 11 '23 at 05:54
  • "* Use the baudrate! *". My presumption is that it entails just taking the reciprocal of the baudrate and that is how I arrived at my figure of 104 us for sending each individual bit. However, I suspect that there is something else that I am missing! – aLoHa Feb 11 '23 at 05:54
  • So what's the "*baudrate*"? You post mentions both "*9600 bps*" and "*9600 kbps*". "*However, I suspect that there is something else that I am missing!*" -- One more time: did you read the link I posted in the first comment? – sawdust Feb 11 '23 at 05:56
  • No. But, I am going to do so now. And I mean 9600 bps to be clear. Thanks for the link btw. It was a nice reminder to use Realterm, which I have installed. – aLoHa Feb 11 '23 at 05:58

1 Answers1

1

The Microchip MPLAB simulation tool is an incomplete representation of the controller functionality. The available models of functional blocks like the UART do not seem to sample the simulated input pin states as described in the data sheet.

The UART simulation model supports a "register injection" method to change the internal state of the model to receive data on a byte by byte basis.

You could open a support case with Microchip and ask if your approach is even possible.

Dan1138
  • 1,150
  • 8
  • 11
  • 1
    Seems there is still a lot that I have to learn :) I was under the impression that the Register Injection method also require a SCL/SCL-type file. So, that is why I have yet to look into that method. Which I will now do. Thanks for your contribution. – aLoHa Feb 13 '23 at 18:52