0
\$\begingroup\$

This question is about trying to understand how the communication is implemented on a typical peripheral device such as an accelerometer, or flash chip.

More specifically, I'd like to understand how a peripheral device is able to start shifting out data from the correct address immediately after receiving that same address without any handshaking/clock-stretching required.

For example, this is the SPI-read timing diagram from an FRAM device. It shows the requested data being sent by the peripheral the very next clock after the address is received.

enter image description here

Bonus: What prompted this question is wanting to emulate this behavior for comms between two MCUs. For example, the main MCU would be able to read from the peripheral MCU at different addresses and the peripheral would be able to send data from one of multiple buffers via DMA transfer. The idea behind it is to enable multiple, high-throughput data streams between the devices with minimal overhead of handshaking.

\$\endgroup\$
7
  • \$\begingroup\$ what is in the device datasheet that leads you think that the device is not fast enough to output data on the next clock cycle after the address is received? \$\endgroup\$
    – jsotola
    Mar 19 '21 at 23:10
  • 1
    \$\begingroup\$ Otus, the FRAM devices I've used are I2C, not SPI. Are you more interested in how I2C works? Or are you into some kind of jag where you want to know about all serial protocols and you need a book or something? Oh never mind. I read your bonus comment. That opens up a lot of doors and... a long long response. Do you intend on bit-banging this? Will you have several devices hanging on the same wires? (Looks like it.) Most important question is if you intend bit-banging. \$\endgroup\$
    – jonk
    Mar 19 '21 at 23:44
  • 1
    \$\begingroup\$ Otus, Years ago we needed to validate lots and lots of instruments at once and collect data measurements. There was no way to use the usual hookup (we'd have needed dozens of RS-232 ports -- not going to happen.) Plus, the MCUs in the instruments had only a very few spare I/Os left over. So they had to share, somehow, and send values to a listener. I used an arrangement similar to the APIC bus on the (then) Pentium II CPU. Worked great. But bit-banging means careful attention to detail for speed. Poor attention always means "slow." Sampling uncertainty translates into delays twice as long. \$\endgroup\$
    – jonk
    Mar 19 '21 at 23:56
  • \$\begingroup\$ @jsotola, I have no reason to think it wont be fast enough. I'm coming at this from the perspective of wanting to implement something similar on an MCU, and wanted to better understand how these peripherals achieve this. Is it just that there's special hardware for this? If so, is it possible to emulate this on an MCU using a standard peripherial? Etc. \$\endgroup\$
    – Otus
    Mar 20 '21 at 0:12
  • \$\begingroup\$ @jonk I'm pretty familiar with the protocols so this question really is about how I can achieve high throughput, low overhead communication with multiple payload "types" (ie. read from different memory) \$\endgroup\$
    – Otus
    Mar 20 '21 at 0:14
1
\$\begingroup\$

The simple answer is hardware. The spi flash and peripheral chips have specific hardware that can work bit by bit and utilise the time a spi clock takes to read the data in time for the next clock to send it out.

On a microcontroller you have a generic spi peripheral that usually works at the byte level - you have to wait until the master spi has clocked 8 bits into the slave. The slave then probably interrupts the cpu. You ‘ve then got interrupt latency and other delays until your spi code runs, figures out what it needs to do and prepare the response to reply. If you have a fast microcontroller and a relatively slow spi clock then you may be able to do everything in time for an ‘immediate’ response to the master. This is usually not the case, so you need to use some form of handshake or a difference method of access whereby you send a command and that primes the next response so you can load up the dma controller to respond immediately to the next command. In short, implementing a spi slave on a microcontroller is tricky. Having it emulate a serial flash/ram/fram is even trickier. An fpga comes in handy here.

\$\endgroup\$
4
  • \$\begingroup\$ Thanks, that's kind of what I was thinking was the case, while hoping it wasn't. The problem I'm trying to solve is eliminating that handshaking but it may not be possible after all. I've looked through the MCU datasheet (STM32) and it seems like there is no additional provision for any "hardware channel" type mechanism. I think the best option I have is to as you say send a message to "prime" the next response. If you have any ideas on how to avoid that priming for a "default" message, I'm all ears :) \$\endgroup\$
    – Otus
    Mar 20 '21 at 0:16
  • \$\begingroup\$ Unfortunately there's no magic - it's all about time, time for the isr latency, time for each byte to clock out, time your the slave code to figure out how to respond. If the spi peripheral has a fifo (as in > than a couple of bytes) then you can preload all or some of the message. This gives you a bit more time to respond to the select line falling and your slave spi code doing stuff. \$\endgroup\$
    – Kartman
    Mar 20 '21 at 2:12
  • \$\begingroup\$ A recent technique I used was to preload 0xff's into the fifo and then start the response message with a token, say 0xAA. When the master code sees the token, it knows that is the start of the slave response. The STM32's should allow the use of dma so you can set the dma to take care of loading the spi with the response data. \$\endgroup\$
    – Kartman
    Mar 20 '21 at 2:13
  • \$\begingroup\$ That's an interesting idea. Basically load the data mid-transfer and mark the start of it with some preamble. So the first N bytes are garbage but you don't need multiple transactions in which to handshake. \$\endgroup\$
    – Otus
    Mar 21 '21 at 1:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.