A couple hints about successful master-slave PIC SPI

[Dan Mullin]

I am currently running two PIC16C77's in master-slave mode.

This may be obvious to everybody but it wasn't to me. When running two PIC's in master-slave SPI mode do NOT use spi_write's on the slave PIC. It appears you must use spi_reads, even if the incoming data is garbage. Unlike the master, an unloaded slave will trigger the SSPOV flag and will no longer vector to interrupts.

I have also found the use of an "acknowledge" lead from slave back to master to be VERY helpful if transferring multiple bytes in a packet. Initialize the lead as low. Have the master send the first SPI packet to the slave (in my case a command number to identify the following data) then sit in a loop waiting for the slave to vector. Once the slave gets to the SPI routine pull the ACK line high to signal we are ready for transfers. Transfer the data between the two. Have the master then wait for the ACK line to drop low again. Let the slave finish its processing, then drop the ACK line. This releases the master. It may seem a waste of cycles but, if the slave interrupt code is pretty lean, its pretty quick. This also assures the master won't hit the slave with another SPI packet before the first has been processed, a very quick way to get out of sync.

I have also read a few articles about the need to transition the SS line with every byte transferred to the slave. Some say it is required, some say it is not. The only luck I have had with reliable transfer has been by transitioning the SS line with every byte transferred, i.e.

** Master **
output_low( PIC_SS ); // trigger SS
in1 = spi_read( out1 ); // pass a byte
output_high( PIC_SS ); // clear SS
output_low( PIC_SS ); // trigger SS
in2 = spi_read( out2 ); // pass a byte
output_high( PIC_SS ); // clear SS

If sharing the SPI with other devices I have also found it good practice to pull the master SDI line low with a 10K. Though the spec's for the 16C77 show the slave SDO will return to float pretty quickly after releasing the SS line it simply doesn't seem to be quick enough for the EEPROM and ADC I am using. I saw some "legacy" transitioning going on on the SDI line when the slave was released. I don't see this type of problem on other designs that only use the EEPROM and the ADC without a slave connected so it does appear to be the slave PIC's problem.

Watch the timing spec's for the slave PIC. Running with a 19.6608 MHz clock I have NOT found that the slave can consistantly receive data with a DIV_16 SCK from the master though it should be in spec. Dropping to a DIV_64 made it much more reliable. It may be a latency issue on the SS low to slave SDO active.

Just some thoughts...
___________________________
This message was ported from CCS's old forum
Original Post ID: 2273

[Charlie U]

Dan,

How are you setting up your spi interfaces? I'm not using the SS pin and I found that I needed to use low to high transistions for successful operation. Both master and slave are running a 4MHz with spi clock set to divide by 16. The compiler allows high to low with the SS disabled which according to a note in the F87x data sheet is a no no. There's no explanation or warning other than don't do it.

Here's my set up:
Master: setup_spi (spi_master | spi_l_to_h | spi_clk_div_16 );
Slave: setup_spi(spi_slave | spi_l_to_h | spi_ss_disabled );

I'm not using your acknowledge scheme, but rather a request to send and clear to send. In my project the slave is synchronous with the AC line, and can only receive data during a specific window of time. The master may be busy with other functions during that window so I use the RTS from the master, as a signal to the slave that the master is ready to send data. The slave asserts CTS and the master starts sending data. If there is no RTS the slave skips the spi routine and continues until the next cycle.

In my case, if the slave doesn't respond to the master, the whole thing is broken anyway so it doesn't matter.

Thanks
Charlie
___________________________
This message was ported from CCS's old forum
Original Post ID: 2277

[Dan Mullin]

:=Dan,
:=
:=How are you setting up your spi interfaces? I'm not using the SS pin and I found that I needed to use low to high transistions for successful operation. Both master and slave are running a 4MHz with spi clock set to divide by 16. The compiler allows high to low with the SS disabled which according to a note in the F87x data sheet is a no no. There's no explanation or warning other than don't do it.
:=
:=Here's my set up:
:=Master: setup_spi (spi_master | spi_l_to_h | spi_clk_div_16 );
:=Slave: setup_spi(spi_slave | spi_l_to_h | spi_ss_disabled );
:=
:=I'm not using your acknowledge scheme, but rather a request to send and clear to send. In my project the slave is synchronous with the AC line, and can only receive data during a specific window of time. The master may be busy with other functions during that window so I use the RTS from the master, as a signal to the slave that the master is ready to send data. The slave asserts CTS and the master starts sending data. If there is no RTS the slave skips the spi routine and continues until the next cycle.
:=
:=In my case, if the slave doesn't respond to the master, the whole thing is broken anyway so it doesn't matter.
:=
:=Thanks
:=Charlie

Charlie,

This system is setup with a LOT of executable code in the master (16C77 with 86\%)and little in the slave. Since I share the SPI bus with the EEPROM and the ADC I need to use SS to keep the slave off the SDI line until I want to talk to it.

In my case every transfer from master to slave must be done correctly the first time with no skips as I don't have code room or time left for retry code. That's why I use the single ACK line and, as you said, if the slave doesn't ACK its broken anyway. Since you're running 4 MHz with DIV_16 you can see why I'm running DIV_64 with nearly 20 MHz.

I actually set my master up as:
setup_spi(SPI_MASTER|SPI_L_TO_H|SPI_SAMPLE_AT_END|SPI_XMIT_L_TO_H|SPI_CLK_DIV_64);


I redefined my 16C77 device file for:

//#define SPI_SS_DISABLED 1
#define SPI_SLAVE_SS_DISABLED 0x25
#define SPI_SLAVE_SS_ENABLED 0x24
#define SPI_SAMPLE_AT_END 0x8000
#define SPI_XMIT_L_TO_H 0x4000

because the bits were not being set up properly from the original device file. Seems they left out the last couple directives for sample_at_end and xmit_l_to_h.

Make sense?
___________________________
This message was ported from CCS's old forum
Original Post ID: 2284

[Charlie U]

:=
:=Charlie,
:=
:=This system is setup with a LOT of executable code in the master (16C77 with 86\%)and little in the slave. Since I share the SPI bus with the EEPROM and the ADC I need to use SS to keep the slave off the SDI line until I want to talk to it.
:=
:=In my case every transfer from master to slave must be done correctly the first time with no skips as I don't have code room or time left for retry code. That's why I use the single ACK line and, as you said, if the slave doesn't ACK its broken anyway. Since you're running 4 MHz with DIV_16 you can see why I'm running DIV_64 with nearly 20 MHz.
:=
:=I actually set my master up as:
:=setup_spi(SPI_MASTER|SPI_L_TO_H|SPI_SAMPLE_AT_END|SPI_XMIT_L_TO_H|SPI_CLK_DIV_64);
:=
:=
:=I redefined my 16C77 device file for:
:=
:=//#define SPI_SS_DISABLED 1
:=#define SPI_SLAVE_SS_DISABLED 0x25
:=#define SPI_SLAVE_SS_ENABLED 0x24
:=#define SPI_SAMPLE_AT_END 0x8000
:=#define SPI_XMIT_L_TO_H 0x4000
:=
:=because the bits were not being set up properly from the original device file. Seems they left out the last couple directives for sample_at_end and xmit_l_to_h.
:=
:=Make sense?

Sure does. I'll look into the extra bits and see if I can clean things up a bit with them.

And thanks again,
Charlie
___________________________
This message was ported from CCS's old forum
Original Post ID: 2285

[Hans Wedemeyer]

Interesting post. A search will show I had problem with SPI Master Slave. the main problem was not speed, it was only transmitting 7 bit data ! All that's fixed.

My setup :

PIC18C452 at 10MHz using 4XPLL running internals clock at 40MHz.
SPI set for Div 4 i.e. 10MHz

Slave PIC16F876 runing at 18.432MHz.

I have a handshaking scheme very much the same as you described.
The slave is using SPI interrupt, and the master is in charge of
the transaction. Master sends a command byte to the slave, the slave responds by raising the Ack line and depending upon the command puts the first data byte into the SPI tx reg. I do this directly and not using CCS at all.

The 7 bit only problem was becasue I was trying to us !SS and once I got rid ot that and setup using the following setting for Master Slave it works real good and has a 100\% transmission of data, there are no errors, I have tested for 36 hours sending known streaming data with and compared received files ( connect to PC by USB link) to the orginal and there are no errors. I'm not saying there never will be, but the error rate is going to be extremly small...

The PIC16F876 has no problem following the PIC18C452. The other SPI device is a LTC1448 and it is happy as a pig in mud running at 10MHz SCK. The LTC1448 just works no matter what SPI configuration I used... wish all SPI chips were as good.

////////////////////////////////////////////////////////////////// PIC18C452 10MHz usinf 4X PLL internal clk 40MHz
// this works full 8 bit with the blewoed mention slave setup, // this is NOT using !SS pin it is disabled This is the CCS ONLY // SPI call I use and could be replace with normal direct calls.
// SMP and CKE and CKP are setup as bit macros...

setup_spi(SPI_MASTER|SPI_CLK_DIV_4|SPI_L_TO_H|SPI_SS_DISABLED);
// 10MHz spi works fast! Eat your hearts out I2C users... !

SMP = 0;
CKE = 1;
CKP = 0;

//// PIC16F876 at 8.432MHz
// This works using this setup for Slave
SMP = 0;
CKP = 1;
CKE = 1;

SSPCON = 0;
SSPCON5 = 1; // can be done with a singal write...
SSPCON3 = 0;
SSPCON2 = 1;
SSPCON1 = 0;
SSPCON0 = 1;
___________________________
This message was ported from CCS's old forum
Original Post ID: 2313

[Dan Mullin]

:=Interesting post. A search will show I had problem with SPI Master Slave. the main problem was not speed, it was only transmitting 7 bit data ! All that's fixed.
:=
:=My setup :
:=
:=PIC18C452 at 10MHz using 4XPLL running internals clock at 40MHz.
:=SPI set for Div 4 i.e. 10MHz
:=
:=Slave PIC16F876 runing at 18.432MHz.
:=
:=I have a handshaking scheme very much the same as you described.
:=The slave is using SPI interrupt, and the master is in charge of
:=the transaction. Master sends a command byte to the slave, the slave responds by raising the Ack line and depending upon the command puts the first data byte into the SPI tx reg. I do this directly and not using CCS at all.
:=
:=The 7 bit only problem was becasue I was trying to us !SS and once I got rid ot that and setup using the following setting for Master Slave it works real good and has a 100\% transmission of data, there are no errors, I have tested for 36 hours sending known streaming data with and compared received files ( connect to PC by USB link) to the orginal and there are no errors. I'm not saying there never will be, but the error rate is going to be extremly small...
:=
:=The PIC16F876 has no problem following the PIC18C452. The other SPI device is a LTC1448 and it is happy as a pig in mud running at 10MHz SCK. The LTC1448 just works no matter what SPI configuration I used... wish all SPI chips were as good.
:=
:= ////////////////////////////////////////////////////////////////// PIC18C452 10MHz usinf 4X PLL internal clk 40MHz
:=// this works full 8 bit with the blewoed mention slave setup, // this is NOT using !SS pin it is disabled This is the CCS ONLY // SPI call I use and could be replace with normal direct calls.
:=// SMP and CKE and CKP are setup as bit macros...
:=
:=setup_spi(SPI_MASTER|SPI_CLK_DIV_4|SPI_L_TO_H|SPI_SS_DISABLED);
:=// 10MHz spi works fast! Eat your hearts out I2C users... !
:=
:=SMP = 0;
:=CKE = 1;
:=CKP = 0;
:=
:=//// PIC16F876 at 8.432MHz
:=// This works using this setup for Slave
:=SMP = 0;
:=CKP = 1;
:=CKE = 1;
:=
:=SSPCON = 0;
:=SSPCON5 = 1; // can be done with a singal write...
:=SSPCON3 = 0;
:=SSPCON2 = 1;
:= SSPCON1 = 0;
:= SSPCON0 = 1;
:=
:=
:=
:=

Hans,

I found something similar to your "7-bit" problem with my original setup. I had data conflicts on the SDI line between the three components. I found the slave PIC just wasn't siezing or releasing the line quick enough. However, once it got running it was fine. I was also receiving "partial" transmissions because the other bit or two were lost during the tri-state transition.

If you do want to ever use the SS line you might want to try delaying your transfer a bit after asserting the SS line to allow the slave PIC to stabilize from the float condition. Same on the back end of the transfer. That is why I installed the 10K pull-down resistor. Though actual data transfer is mighty fast, the slave SDO coming out of and going into tri-state is not very quick!

Thanks for your additional comments,

Dan
___________________________
This message was ported from CCS's old forum
Original Post ID: 2320

[Hans Wedemeyer]

Dan,
The solution for my project allowed me to simply not use the !SS and using a separte handshake line is a lot faster anyway... 10MHz spi

This current project is at a stage where I will not mess with !SS don't need it.

I'll remember your suggestions and next time try it see if that makes !SS work.
Thanks
Hans W
___________________________
This message was ported from CCS's old forum
Original Post ID: 2333

[global]

Hello,

do you have some code for writting with the slave and read with the master, please ?

This is my post : http://www.ccsinfo.com/forum/viewtopic.php?p=42600#42600

Thanks a lot !

[Neutone]