SPI slave receives bit per bit (mosi) every clk and when a byte is completed (process A), this byte of data will be sent to the next process B (FlipFlop). If process B detects byte, process A starts a new filling with bits (mosi).

Process C, which is followed process B, should be a "bridge" between SPI slave and ARM, for example.

How to describe process C? Is it FIFO or ring buffer or inout? How do you, guys, implement it?

  • 2
    \$\begingroup\$ Can be anything. An interrupt to the CPU, a DMA to transfer it to the memory, FIFO, ring buffer. Whatever is good for your application. \$\endgroup\$ – Eugene Sh. Jun 7 at 13:53
  • \$\begingroup\$ @EugeneSh. I have found I can us a resistor single access. I have never heard about "resistor with single access"...What is it? \$\endgroup\$ – LeeLeeYa Jun 10 at 6:50
  • \$\begingroup\$ Maybe a "register", not "resistor"? I would think it is referring to a single register buffering the most recently received byte. \$\endgroup\$ – Eugene Sh. Jun 10 at 13:23
  • \$\begingroup\$ @EugeneSh., single access register, FIFO read, Dual port RAM, DMA Transfer and so one... all of them use to buffer some data between two interfaces, in my case SPI slave and other device, right? How to choose which one is best choice for my application? \$\endgroup\$ – LeeLeeYa Jun 11 at 8:27
  • \$\begingroup\$ Depends on your application. If your processor is busy with other stuff and might miss some transmissions, then you should consider FIFO of a sufficient depth or DMA, that will help storing the data till the processor has time to process it. If it is free to process the data as it comes, a single register might suffice. \$\endgroup\$ – Eugene Sh. Jun 11 at 13:57

SPI receive flow is continuous: additional bits keep coming in regardless of what you do with them. That is, SPI has no mechanism for backpressure to limit the input data rate (unlike I2C, which can slow down the bus by using clock stretching).

You can divide the SPI receive process as follows:

  • accumulate (deserialize) a data word
  • notify the receiving host of a completed word (handshake)
  • receiving host transfers completed word to storage

In theory, if the host is fast enough (or SPI is slow enough), the receiving host could just count the clocks, then grab the deserializer register state when the right number of clocks has occurred. At the extreme case this could be done entirely in software using 'bit-bang' techniques, by polling the clock and data pins.

In practice, SPI is so fast that usually the receiving host has some form of buffering to allow time to capture and store the incoming data word. The faster the data (or slower the host), the more buffering is needed to cover the host's response latency. Further, SPI bit reception is handled by dedicated deserializer hardware with well-controlled low-level timing.

  • \$\begingroup\$ Thats all correct, but I dont think the OP has any use of it. \$\endgroup\$ – Vinzent Jun 7 at 21:06
  • \$\begingroup\$ Other people might though! \$\endgroup\$ – mrbean Jun 7 at 23:12
  • \$\begingroup\$ Could SPI be used as slave and I2C as a master protocol? Does it make sense? \$\endgroup\$ – LeeLeeYa Jun 8 at 9:14
  • \$\begingroup\$ @Vinzent OP, did you mean operation system? \$\endgroup\$ – LeeLeeYa Jun 8 at 9:18
  • \$\begingroup\$ @LeeLeeYa No I mean OP, Original Poster. \$\endgroup\$ – Vinzent Jun 8 at 10:40

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