2

I need to implement SPI Slave (@10 MHz clock) on a microcontroller (a sensor with Cortex M33 core) in software. The problem is software is not fast enough to prepare data just after the command. (also discussed here: how-to-code-spi-slaves)

I have SPI drivers with SPI-Slave mode. So, communication is okay. The question is about protocol.

Luckily, I also code the master (Cortex-M0+), so I am free to define the protocol. What are the options I have? Some ideas I have so far:

Option 1, Send response with a fixed delay

MOSI: command 0xFF 0xFF 0xFF 0xFF 0xFF ...

MISO: 0xFF dummy dummy dummy data0 data1 ...

So, master clocks for command length + response length + fixed delay. I guess it would be hard to count number of dummy bytes sent while processing and then copy data just before correct position.

Option 2, Send response with a variable delay

Similar to Option 1 but not fixed. Add a token as first byte to show where it starts.

MOSI: command 0xFF 0xFF 0xFF 0xFF 0xFF ...

MISO: 0xFF dummy dummy token data0 data1 ...

Problem is master should clock for command length + response length + max delay. This will slow-down communication depending on max delay.

Option 3, Request and response after interrupt

Essentially, half duplex. Just send command first and end communication. Wait for interrupt, then start communication again.

MOSI: command [wait for interrupt] 0xFF 0xFF 0xFF ...

MISO: 0xFF [process ] data0 data1 data2 ...

Master needs to handle timeout and it should keep track of what was sent. I guess this is the most reasonable option.

Null
  • 7,603
  • 17
  • 36
  • 48
uffu
  • 21
  • 2
  • 2
    Your MCU should have SPI peripheral with integrated transmit and receive buffers. It is unusual to implement software-based SPI on MCU, ie by using only MCU core - that is a job for FPGA instead. Can you disclose serial number of your MCU? – Marko Gulin Aug 31 '20 at 08:09
  • It is actually a sensor with Cortex-M33, unfortunately, not an FPGA which would be too expensive. It does some time-taking measurements and reports the results. – uffu Aug 31 '20 at 08:32
  • Check in the datasheet does it have some kind of a serial interface (eg Flexcomm or something similar). – Marko Gulin Aug 31 '20 at 08:38
  • Oh, it has SPI drivers for slave mode. I have the communication up and running for fixed length request-response similar to option-3. My question is for protocol. What is the best practice for this, so that I dont re-invent the wheel. – uffu Aug 31 '20 at 08:51
  • @MarkoGulin, "that is a job for FPGA instead" - why an FPGA instead of the MCU? – TonyM Aug 31 '20 at 08:56
  • I thought that the OP wants to implement bit banging SPI at 10 MHz on MCU. I have never tried it myself, but sounds far-fetched. – Marko Gulin Aug 31 '20 at 08:58
  • 2
    The question doesn't say bit-banging. – user253751 Aug 31 '20 at 09:37
  • 3
    It's not possible to prepare the data for the commands beforehand? Like have the most recent data available for immediate fetch and do the measurement on a second buffer, as soon as it's available do a switch of the buffers and so on? – Arsenal Aug 31 '20 at 11:09
  • What @Arsenal said. If you need more than one dummy byte, you're doing it wrong. – Dave Tweed Aug 31 '20 at 11:15
  • 2
    Should be feasible with a hardware SPI peripheral and DMA. As for "The problem is software is not fast enough to prepare data just after the command." that's normally dealt with by having the data ready before you receive the command. – Lundin Aug 31 '20 at 11:26

0 Answers0