SPI Slave: inspect data before transfer complete?

[Andrew Kohlsmith]

I'm trying to emulate an nRF24L01+ SPI slave interface with an nRF51822. The nRF24L01+ interprets the first byte in the SPI transfer as a "command", and the data that it will shift out in the same SPI transaction depends on the first byte received from the master.

Looking at the SPIS peripheral in the nRF51 reference manual, it does not appear that I emulate this behaviour. If I set MAXRX to 1, the rest of the SPI transaction will be ignored, and it doesn't look like I can implement a polling method to see when the first byte comes in.

Is there a way that I can emulate an nRF24L01+ SPI implementation with the nRF51822?

edit: Just to be clear: I'm not trying to emulate the whole nRF24L01+; I want to fake out a device that talks to an nRF24L01+ over a 400kHz SPI link just enough to be able to say "I have a new packet, here is the data" and that's about it. The data for the packet would of course come from BLE instead of a proprietary 2.4GHz link.

[Stian Røed Hafskjold]

I don't think there are any easy way to do this. If you are going to use the SPI slave hardware peripheral (SPIS), there are no other events generated from this peripheral than END and ACQUIRED. END tells you when the whole transmission has finished, and ACQUIRED is when the SPIS has been granted access to the RXDPTR and TXDPTR registers. So, there is no event that tells you when only the first byte has been received.

You can try to write your own software SPI slave that does this, but I don't think the nRF51822 is fast enough to do the processing that needs to be done after the first byte has been received, in order to shift out valid data on the next byte. This was done in hardware on the nRF24L01, and hence a lot faster.

[Andrew Kohlsmith]

Yes, I spent a few hours last night with the pin change interrupt and spinning on the received byte to see when it was received. I can detect this and respond quickly enough but as soon as I try to do any data processing (i.e. responding differently to different command bytes) it falls down and my response is sent in the third byte instead of the second.

at 16MHz there just isn't enough time. At 32MHz there may be, but I think that after the BLE soft device has taken its toll in CPU time I'll be back to where I started.

[yd]

The master controls the flow of the communication. You can first send out one byte from master and end the communication by pulling the CSN high. That will generate END event on the SPI slave. Then you can check the byte and fill the SPI buffers on the SPI slave with appropriate data. After you give SPI slave enough time to do its work, you can have the SPI master set the CSN low again to get the data form the SPI slave. Try using timers or delay functions.

[RK]

That's not what the original poster is asking. He's not looking to change the protocol or re-implement how the master works, he's looking to implement a slave for an existing master, he even makes it clear in the original question (by putting it in italics) that the data must go out in the same transaction.

[yd]

I read that. He also said in another post (devzone.nordicsemi.com/.../ that it is not possible to do any data processing between first and second bytes. If the data gets clocked out on the third byte, he will have to change the master anyways. So, I gave him an alternative. Changing the master to set the pin high for a few microseconds is pretty easy and it ensures data integrity instead of possibly running into a race condition trying to set bytes while the SPI communication is active. This is a better way to communicate with SPI slaves. Send a command, wait for the processing and get data.