RE: SPI Slave Chip select as an Interrupt

raju — Sat, 02 Aug 2014 10:08:21 GMT

Hi Vince, Thank you very much for your reply. here there are 2 types of communications possible.

when every nRF SPI Slave is ready with the data, sends an interrupt to Microcontroller ( By making INTERRUPT2CONTROLLER high) as a response Master initiates SPI transfer. ( can say SPI Master read operation )
Master itself want to send the data nRF ( Master SPI Write Operation)

second scenario can occur at any time.( Slave should be ready always to receive the data) in this case how can I manage. is it possible that SPI slave CS pin can be used as CS and Interrupt at the same time? Thanking you very much. Regards, Rama Raju

RE: SPI Slave Chip select as an Interrupt

Vince — Thu, 31 Jul 2014 18:18:53 GMT

Hi Raju,

IMHO the answer is yes, it is possible, but not at the same time. The easiest way is probably to use an external pull-up resistor on the INTERRUPT2CONTROLLER line and drive it both side as open-drain. If your master uC doesn't provide this functionality, you can drive it low when you want it low and configure the pin as high-Z input when you want it high; the pull-up resistor will do the rest. Just take care never to drive that line high, as it could result in high current flow and even IO driver destruction.

So, the following (untested) code should configure the pin as an active-high interrupt signal output, and drive it low (provided CS_PIN is properly defined):

// disable SPI
NRF_SPIS1->ENABLE &= ~(SPIS_ENABLE_ENABLE_Enabled << SPIS_ENABLE_ENABLE_Pos);

// set CS_PIN as low-driven output
nrf_gpio_pin_clear(CS_PIN);
nrf_gpio_cfg_output(CS_PIN);

When your nFR device is ready to transmit, a call to spi_slave_init should cleanly restart the SPI port and configure CS_PIN back to input, making the line go high again.

[edit (answering Raju's comment)]

According to nRF51 reference manual chapters 13 (GPIO) and 26 (SPIS), enabling SPIS will override GPIO pins configuration, denying the use of CS as general purpose output. Anyway, you wanted the slave to hold the line low as long as there is no data to send, isn't it? So here are some workarounds I can think of right now, as I assume using a dedicated IRQ line is not an option:

WA1: accept compromise

Is it really necessary to have an IRQ? Can't you just buffer data on slave side and poll it with the master? And if it is about power consumption, can't you delay master-to-slave transaction until the slave has data to send?

WA2: the dirty way

Only disable the SPIS when you need to draw an IRQ. You will need to make the interrupt active on falling edge. This will most probably result in data collision, but statistics and a good handshake protocol could save you...

WA3: if the nRF is the only slave device on the SPI bus

Use SCK or MOSI to trigger the SPIS reactivation.

WA4: the hairy one

Send an 'illegal' SPI pattern you are sure the master will never send otherwise to trigger the SPIS reactivation, e.g. a pulse burst on MOSI while SCK stands still.

[/edit]

Please comment :)

Best regards,

Vince