Consider you have an SPI bus with only a single chip select.
Is there a chip such that I can connect 8 or more devices to that SPI bus?
To simplify things, you may assume that all devices agree on the SPI mode (data needs to be valid on a rising edge). Also, all devices are of the time, where chip selects stays low for the whole transfer, and is not toggled after each word.
The SPI multiplexer could have 4 inputs:
MISO, MOSI, input clock, master chip select
and 9 outputs:
output clock, 8 slave chip selects
MISO and MOSI are connected directly to the slaves. The slaves have their SPI clock connected to the output clock and their chips selects are connected to one of the 8 slave chip selects.
The SPI multiplexer would take the two bytes of each SPI transfer as its own input. The first byte could indicate which slave is to be selected. For configuration of the multiplexer, a ninth address could be allowed.
If one of the 8 slaves is selected, the multiplexer would then activate the slave's chip select after the first byte (or even after the first few bits of the first byte). The output clock would activate with the start of the second byte and it would be synchronous to the input clock. Leaving the clock inactive during the first byte makes sure that the slaves never take notice of the first byte.
Such a chip does not seem to exist. I found solutions with two chip selects, but that's not an option to upgrade old hardware designs with just a single chip select.
Does such a thing exist?
It does not exist because there is no need for it. Often CS is only controlled from software as a regular gpio before initiating an SPI transfer, then you could just wire the different slaves to different GPIO and use them as CS. If the CS is generated and needed by the hardware block you gate this signal with the external chip select to choose the wanted slave.
Your proposed one byte to select bus would also break all software which relay on writing from and reading to the same buffer, and it would be decrease the available bandwidth with control signals.
As a side note with recent development with secure enclaves and Trustzone the trend is not to share spi buses but rather hard wire them so only code running in the trusted part of the SoC will be able to access the connected slave.
Related
There are many links on the web describing the SPI timing/clock modes. E.g., the following picture from here indicates 4 combinations of CPOL/CPHA determines when to sampling/transmitting data wrt clock rising/failing edges:
And for SPI to work correctly, it's required that both the controller(or master) and the device (or slave) should work in the same clock mode.
Few days ago, I encounter a datasheet which describes a QSPI controller, saying that it only supports mode 1 (CPOL=0, CPHA=1). It also containing a AC timing requirement for the SPI interface, as below:
The timing diagram confirms that the controller works in mode 1: sclk at low when idle, and data sampled at falling edge of sclk. So far so good.
What puzzled me is another statement in the user guide: "The SPI only supports SPI mode 1. but, if the SPI device follows the Soc AC timing, it is usable regardless of the mode." How it's possible? Apparently it violates the "same mode" rule. For example, how it works when the controller is in mode 1 (sampling on falling edge) and the device is in mode 0 or 3 (sampling on the rising edge)?
Btw, a working system shows that the controller actually works with a QSPI flash devices whose datasheet tells that it only support mode 0 and 3. This implies that I must miss some points in understanding the SPI clock modes...
Any explanation is appreciated.
Your "mode 1" qspi controller is not behaving like a normal mode 1 spi controller.
Look at the timing diagram: It outputs new data on MOSI on the falling edge of CLK, AND it samples MISO on the falling edge of CLK. That is not equivalent of any of the four SPI modes.
It is done to allow much higher performance.
(Q)SPI flash memories sample MOSI on the rising edge of CLK, and output new data on MISO on the falling edge of CLK.
Regular SPI controllers will sample MISO on the rising edge of CLK. This means the entire round-trip of CLK from controller to flash, flash access, and MISO back to the controller, must happen in just half a clock cycle.
This will typically limit you to 25MHz or less.
By having the controller sample MISO on the falling edge, the round-trip gets a whole clock period worth of time, which means you can reach 50MHz or more.
In general:
In SPI there is only one clock edge that matters to the receiver. In modes 0 and 3 it is the rising edge, in modes 1 and 2 it is the falling edge.
The receiver requires the data that it is going to read to be valid for some short period immediately before the edge that matters (called the "setup time") and requires that it remains valid for some short period after the edge that matters (called the "hold time").
Outside this small window (the setup time plus the hold time) the value of the data lines does not matter at all. The receiver does not do anything at the other clock edge to that the one where it samples the data, and the line may have any value then, including an intermediate voltage which is between high and low.
The only responsibility of each transmitter is to meet the requirements of the receiver. That is, the master must control MOSI in such a way that that it meets the requirements of the slave, and the slave must control MISO so that it meets the requirements of the master.
At slow speeds the easiest way for each transmitter to meet the requirements of the other device is to change the data at the moment of the opposite clock edge to the one the receiver cares about. This is the implies using the same clock mode at both ends as shown in the diagrams in your question.
At higher speeds this is not always ideal and the timing method described in your datasheet extract is widespread and perfectly normal.
For your particular device:
Your slave device samples MOSI on the falling edge of CLK. It requires the master to have driven MOSI to the correct level at least tIS (input sample time) before this and to hold it for at least tIH (input hold time) after this.
In the other direction, your slave device holds the previous MISO value for at least tCLQX (clock low output hold time) after the edge where it assumes the master would have sampled it.
Your slave device outputs the next MISO value no later than tCLQV (clock low to output valid time) after the same falling edge.
In the case of the naive timing diagrams in your question, you would assume that tCLQX would have the same value as tCLQV and would also coincide with the next rising edge of the clock, but the datasheet is saying that this does not have to be the case.
I am using a STM32F031K6, clocked at 40MHz, and I want to design a program which acts as a looping shift register - an external trigger is used to clock it, the values in the shift register left shift every time a rising/falling edge is received. the output is one pin either high or low.
I need to make the time between the clocking edge and the output less than 0.5uS, or failing that as quick as possible. The values of the shift register can be changed and the length can also be changed, but for now I'm just starting with a byte like 11000010 .
I initially thought to implement this with an external interrupt but it was suggested there may be a better way to implement it
any help much appreciated
You might use the SPI peripheral of the STM32F0 for your task. When configured in slave mode, each time an external clock edge is detected on the SCK signal, the MISO will be set to the next bit of a value loaded into an internal shift register via the SPI data register.
Check out the chapter on the Serial peripheral interface (SPI) in STM32F0 reference manual.
Especially have a look at the sections addressing the following keywords:
General description: SPI block diagram
Slave Mode (Master selection: Slave configuration)
Simplex communication: Transmit-only mode (RXONLY=0)
Slave select (NSS) pin management: Software NSS management (SSM = 1)
Data frame format (data size can be set from 4-bit up to 16-bit length)
Configuration of SPI
The SPI unit is highly configurable, e.g. regarding the polarity of clock signal. Since it is an independent hardware unit, it should be able to handle your 0.5us reaction time requirement. The MCU firmware needs to set up the SPI unit and then provide new data to the SPI unit, each time the Tx buffer empty flag (TXE) is set. This can also be done by interrupt (TXEIE) or even using a DMA channel (TXDMAEN) with a circular buffer. In the latter case the "shift register functionality" runs completely independent of the MCU core (after setup).
I know basic SPI protocol and its master to slave operations. I want to know that is it possible to broadcast data on multiple slave? If it is possible then how it works.
I've heard that after writing to any SPI slave you have to read from slave even if you are not going to use read data. How is this possible in case broadcast if broadcast is possible?
No, it's not possible. Since SPI is 4- wire interface. The SS line is used for slave selection.One SPI master can have multiple slaves but it cannot select all the slaves at once since it is either using some bit or SS signal to select the slave(and cannot select multiple slave at a single time).
SPI works in full duplex mode(most of time and cases), and is implemented using shift registers. Hence while writing the data on MOSI(assumption: master is writing),we are getting the data in MISO line too (inserting data in master shift register does shift the data in slave shift register). Hence we get data on both of the TX and RX lines.
It is possible if you have multiple SPI controllers. I have four SPI controllers connected to four different chips of the same type. I control the SS in software because the the SPI controller can't control it in a useful way. My driver has read, write, and broadcast methods. Read and write act on one SPI controller instance while the broadcast method (write-only of course) takes an array of SPI controller instances.
The broadcast method then takes the common address buffer of size bytes and the common data buffer of size bytes and sends them to all four SPI controllers sequentially (but close in time) to effect a broadcast from the caller's perspective. It isn't a hardware based broadcast but it does allow higher level software to think it is broadcasting common commands and setup data to all four chips at once.
It is also overall more time-efficient than sequentially sending the same thing to all four chips since efficiencies are to be had by having the lower layer SPI controller do the work.
If you use simplex SPI with one master and many slaves, you can create an interface of 1 to many. Assuming DMA, you posit the size of the transaction and a data buffer. The physical interface is 2 wire plus ground - CLK and MOSI. NSS is software selected not hardware. In theory you DMA from the master and the slaves get the data. This is a one way channel. I have been playing around with these sorts of configurations and this one seems to be working. Hardware is STM32f0/g0 architecture. I am also looking into ring topologies.. which were fun it the 90s, and may still be fun..
You cannot broadcast data to multiple slaves at the same time.
I have been working on a PIC18F45k20 running at 16 MHz and using it as an SPI slave. I find that no matter the SPI clock rate (SCK) from the master I always have to add a significant delay (~64 us) between SPI bytes to avoid SPI collisions or receive overflow. Without the delay and at very slow SPI clock rates, 95% of the SPI packets will get through without collision or overflow.
Online posts lend me to think that this may be a "feature" of this, and other, PIC18 processors.
Have others observed this same slave “feature”?
If this is a “feature”, is it found in all PIC18 processors?
I tested the PIC18 without an interrupt with the following:
if (SSPSTATbits.BF)
{
DataIn = SSPBUF;
SSPBUF = DataOut;
}
Also tested using an interrupt and saw the same challenge.
Makes me wonder if it doesn’t truly detect the SPI clock properly.
If you have an oscilloscope check to make sure that the chip select is not being released prior to the PIC clocking out the last SPI data byte. You need to wait on the SPI busy bit before releasing the chip select line.
As I know PIC18 is a 8bit microcontroller, although you can easily find that it's integer variable is mapped into 16bit. However SPI works with 8bit data. It means if your master send for this microcontroller more than 8bit, such as 16 bit, overflow happens in SPI module and cann't response to master clock anymore. So In Slave mode, make sure data from master have 8bit structure. But if pic18 was Master in SPI connection, even though its slave send 16bit data, pic18 hold clock data after first 8bit and wait until its buffer read and empty for next 8bit.
I've also come across this issue and it seems like what one should take into account is that supported SPI simple tells how fast MCU can receive one byte into SSPBUF.
Reading this byte from SSPBUF and storing it in a buffer will require some work like incrementing a pointer etc., which will take some time. This is what reduces actual SPI bandwidth for multi-byte SPI.
I have a microprocessor with the card's chip select (CS) line tied to a 'frame' signal automatically driven by the SPI (SSP) circuit. This causes CS to go high between each byte.
The MMC/SD specs require that CS be held low in order to enter SPI mode. Does it need to be held low the entire time, or only when transmitting each byte of CMD0?
At the sdcard.org site, I found various PDF specifications for SDIO. None of these seem to have an explicit timing statement which clarifies this. However, this statement does occur:
(1) SD Bus mode is selected by CMD0 (Keep Pin 1 to high during CMD0 execution).
from page 88 of SD Host Controller Simplified Specification Version 2.00. ("Pin 1" is Chip Select (CS))
Given that sentence, an SD card manufacturer would be justified in requiring that you assert CS through the entire D0..D15 bits being sent. In other words, I think you cannot use the SPI frame signal and will need a GPIO pin or similar.