dsPIC33 SPI Slave Interupt spi_read() Not Reading

[hammale]

Hello,

I am using two dsPIC33EV256GM104 processors as a master and slave with SPI but am having troubles implementing an interrupt driven slave. I am currently using PCD compiler v5.071c. I am trying to send a one byte command from the master to the slave and have the slave respond with 4 bytes. This is my master code:

spi_master.c

[jeremiah]

Lets try cleaning up some stuff first:

1. You don't need to disable the SPI interrupt while in it. The HW does this for you.

2. You don't need to clear the interrupt flag in the interrupt. CCS does that for you unless you manually turn that off.

3. You are mixing spi_read() with #use spi, which is a no no. It might work or it might not. It is not supported. If you use #use spi, then you need to use spi_xfer() which does both reading and writng. If you really want to use the spi_read() function, then get rid of #use spi and use setup_spi() instead. If so, you'll need to correctly set the mode (there isn't a MODE define for setup_spi(), so you'll have to pick the right options to get it).

[hammale]

[Ttelmah]

A slave, only sends when the data is clocked out by the master.

So when you write in the SPI routine, a byte is loaded 'waiting to send', and this won't actually be sent, till the master sends you a byte.

You only need to load another, once the master sends you another byte (so the spi receive interrupt triggers again). When this happens, you need to read the incoming byte, then send the next byte.

Now outside the interrupt you can send the four bytes, but each slave send then waits for the master to send another byte.

Look at ex_spi_slave.c
You will see that this reads the byte received each time. Then if it needs to send data, it uses 'spi_prewrite', to load this into the output buffer (which is then sent on the next transmission from the master).

[hammale]

[Ttelmah]

The interrupt must _always_ read the data.
The interrupt is saying 'there is a character needing to be read'.
You are ignoring this if PIN_C4 is high. This will mean that the peripheral won't interrupt again, since it'll say "he is ignoring me"...

Then the syntax will be:

data = spi_xfer_in(SPI_PORT1);

and

spi_prewrite(SPI_PORT1, make8(bigData, 0));

[hammale]

[Ttelmah]

I must admit I always specify the transfer length, but usually leave the setup in the #USE for length at the default (32 bits)....
It is meant to automatically handle the reduced length, it you specify bits=8 as you show, so slightly surprised it needs to have the length specified. However the PIC24/33 are very different in several areas here, since the default word length is 16bits for may things.

Glad it is working now.

[hammale]

Ran into another issue with this code today. My system has 8 of these processors daisy chained together. While the previous code works perfectly with only one master and slave, when I connect a second slave the master only reads 0. My slave ISR is still firing correctly and as soon as I unplug the second slave things return to normal. I tried adding an output_float() with the MISO line at the end of the slave ISR but that had no effect. Any ideas?

[Ttelmah]

For SPI to have multiple devices, with common lines, there has to be a slave select.
That's the point of the slave select option in the SSP setup. This must use the hardware pin. Then the slave will only enable it's output transceivers when selected.

If the device is supporting multiple slaves without a select, or proper daisy chaining, then it isn't actually normal SPI. Instead it's another form of synchronous bus....
Daisy chaining with SPI, has the data fed sequentially on from device to device. Not the wires all connected together (which seems to be what you are talking about....).

When you load a byte, it is in the SPI registers and only sends when the master clocks it out. The release would need to happen after this has occurred. Problem is that to release the bus, you would have to disable the SPI peripheral. However if you do this it won't then receive....
The only way it can receive is if it has been left enabled but deselected (with the slave select).

Look at the module block diagram for the SPI "SPIx MODULE BLOCK DIAGRAM". You will see that the SPI directly drives the output line, with the buffer controlled by the SS line.

You can disable the peripheral (look at the 'NOINIT' option, and the spi_init command), but this then disables the receiver as well.

One way would be to enable the SS option, and connect the pin to a non used I/O pin. Then when the command is seen enable this line (so the buffer gets turned on - set the pin low), then send you four bytes, and the interrupt _after_ this, turn off the line (set it high).

The other way multiple devices are done, is daisy chaining. Here the MOSI/MISO lines daisy chain from device to device, and the first device responds to the first command, and then 'hands on' the bytes as they overflow to the next device. The last slave has it's output line fed back to the master's input.

If you want to send to multiple devices, then consider switching to a multi device bus. I2C. Slower yes, but designed to support multiple devices without the complexity of sequential daisy chaining, or device select lines for every unit...

[temtronic]

Perhaps you should consider RS-485 for the communications ? Daisy chaining SPI isn't the 'best' solution,as Mr.T points out due to timing though we don't know what speed or throughput you need. Also SPI isn't a 'long distance' bus unlike RS485( or others). It's fine for several devices on one PCB...2-3 inches NOT 2-3 feet or meters !
Even 'RS-232' might be an option,only 2 pins needed,reduced code to access the remotes.

options, always think of options before committing to the PCB !

Jay

[hammale]

Thanks for the awesome feedback it really helps. Unfortunately I am stuck with my current hardware so I will have to find a way to "make it work". I have 4 SPI slaves connected in series (not proper daisy chaining" as mentioned above) with 4 separate chip select lines all wired back to the master. The problem I am facing now is how to use these SS lines with the #use_spi directive. Using the hardware SPI1 any pin I define to be chip select on the slave returns a compilation error ("invaid SS"). If I use the "FORCE SW" directive my spi_xfer_in and spi_prewrite commands no longer work. Is there a way to still use the hardware SPI1 but define my own chip select line?

EDIT: Just noticed Ttelmah's comment about "faking out" the hardware SS pin, I think I'm going to give that a try.

[hammale]

So I enabled the SS pin in my slave #USE SPI directive (pin B0 on my chip) and modified the ISR to be the following:

[Ttelmah]

If you have slave select lines, then there is no problem....

To use select with the #use spi, you need to have done a PIN SELECT first for the select pin. However you may find it better if you are doing the multi byte transmissions, to cheat a little and not use this. The standard select is a 'per byte' select option.

1) Setup the #USE with the 'noinit' option. This leaves the SPI 'off'.
So (for example):
#USE SPI (SPI1, SLAVE, MODE=0, NOINIT, FORCE_HW, STREAM=SPIIN)

2) Connect the slave select to an input on the slave PIC that can generate an interrupt (on a falling edge).
3) Have this interrupt contain the line 'spi_init(TRUE);' that will enable the slave, and then disable this interrupt.
4) Then at the master. Drop the select. wait a short period (enough time for the slave to have got into the 'enable' interrupt), and do your SPI transaction.
5) Once the last transaction is done, raise the select line.
6) In the slave, after the last transaction, have the command 'spi_init(FALSE)', and then make sure the select has gone high, and when it does clear, and re-enable the input interrupt.

This way the SPI on each slave will be 'off' till the select line drops, and then be disabled again after the transaction.

[hammale]