MCP23S17 - Three different approaches - ShiftIn/ShiftOut / MSSP+PBP / MSSP+ASM

[gadelhas]

This is great stuff. I use the MCP23016, but this new IC is much faster.

Can you explain how you came up with the 3us delay in the 3rd approach? I look at your comment and the SPI characteristics in the datasheet and don't know what to use exactly.

Robert

Hi Robert, Thanks for your comment.

Hi came up with 3 uS by trial and error. I tried 2 uS, but it wasn´t enough. The problem is not the MCP23S17, but the SSPUBUF register of the PIC. I think if you run the PIC faster, for instance @20Mhz, you can even reduce that time.

[Demon]

Wouldn't it be the other way around? If you run a PIC faster, it would cycle quicker so you'd need more delay instructions no?

I checked the datasheet again and page 35 table 2-4 has 500ns for Serial Data to Output Valid. Does that mean it takes 500ns for the IC to process a complete output operation?

I would assume reading is quicker...?

Robert

[gadelhas]

Wouldn't it be the other way around? If you run a PIC faster, it would cycle quicker so you'd need more delay instructions no?

I checked the datasheet again and page 35 table 2-4 has 500ns for Serial Data to Output Valid. Does that mean it takes 500ns for the IC to process a complete output operation?

I would assume reading is quicker...?

Robert

The problem is that when you put a byte in the SSPUF of the PIC, it takes some time for the PIC to output that byte( @8Mhz ~3uS ). If you run the PIC faster, the time that it takes to output the byte gets reduced.
At this speed ( 8Mhz ), you put the byte into the SSPUF and you must wait 3us to put another byte in the SSPUF, if you put a byte before the 3us, for instance at 2us, the byte before will be corrupted and the pic will output the new byte and miss the byte before. You can try this in the simulation that is attached.

You are looking at the wrong table ( 2-4 GP and INT TIMMING). You should look table 2-3 (SPI Characteristics ). The MCP23S17 can RUN at a max of 10Mhz ( SPI ).

[HenrikOlsson]

Hi,
Instead of relying on software timing you can check the MSSP interrupt flag:

myByte VAR BYTE
SSPIF VAR PIR1.3

myByte = 123

SSPBUF = myByte                 ' Load byte to shiftregister buffer
SSPIF = 0                             ' Clear interrupt flag
WHILE SSPIF=0 : WEND        ' Wait for transmission to finish

This way you don't have to change any timing if you change the oscillator or if you change the MSSP module clock divisor etc.

Check the datasheet and make sure the SSPIF is at PIR1.3 for your device. (I think they try to keep it consistent but you never know)

/Henrik.

[gadelhas]

Hi,
Instead of relying on software timing you can check the MSSP interrupt flag:

myByte VAR BYTE
SSPIF VAR PIR1.3

myByte = 123

SSPBUF = myByte                 ' Load byte to shiftregister buffer
SSPIF = 0                             ' Clear interrupt flag
WHILE SSPIF=0 : WEND        ' Wait for transmission to finish

This way you don't have to change any timing if you change the oscillator or if you change the MSSP module clock divisor etc.

Check the datasheet and make sure the SSPIF is at PIR1.3 for your device. (I think they try to keep it consistent but you never know)

/Henrik.

Hi Henrik,

You are correct. I did try the PIR1.3 flag, however i forgot to clear it before test it, and because of that it was not working like should be.
One problem with this approach is that it takes more memory.

One more thing, to test if the SSPBUF has received a byte, we should test the SSPSTAT.BF bit, like:

    DataIn = SSPBUF         'Data received from te MCP23S17
    SSPSTAT.0 = 0              
    WHILE SSPSTAT.0 : WEND

Now i need to change the code that i posted before this little improvement, but i can modify my posts!!!!

Thanks!!!

[HenrikOlsson]

Hi,
I initially used the the SSPSTAT.0 bit for both sending and receiving but eventually got into trouble. Darrel then made me aware in this thread of that the purpose of SSPSTAT.0 flag really is when the PIC is operating in slave mode and data is shifted into to PIC by an external clock source, ie when something else is providing the SPI clock. (Thanks Darrel!)

When the PIC is acting as the master, as is the case in all your examples, it works fine with the interrupt flag. For shifting in a byte you simply write a "dummy" value to SPPBUF, the module will then shift that dummy byte out with 8 clockpulses and then you'll have your input byte in SSPBUF.

IF you're going to use the SSPSTAT.0 bit I suspect you want to poll it before reading SSPBUF to see if there's a byte available to be read. The way you have in your latest post you grab whatever is in SSPBUF and then sit there waiting for another byte before continuing. Is that the intentended operation?

/Henrik.

[gadelhas]

Hi,
IF you're going to use the SSPSTAT.0 bit I suspect you want to poll it before reading SSPBUF to see if there's a byte available to be read. The way you have in your latest post you grab whatever is in SSPBUF and then sit there waiting for another byte before continuing. Is that the intentended operation?

/Henrik.

No, i actully take it of in my last version. Since the last thing that the MCP sends is the byte that i want, i just grab it and put it on the PORTB.