Are there SPI multiplexer ICs?

[zapta]

I have a working design with a timer that generates period CS pulses and DMA channel that access the devices synchronized with the timer. Now I want to access a few SPI devices from the same SPI/DMA channel. Are there off the shelf ICs that allows to multiplex SPI, without having to set GPIOs pins to select the devices?

For example,
1. A single multiplexer that sits between the MCU and the SPI devices and the MCU sends first a device number byte, causing the multiplexer to enable the corresponding CS?

2. Each SPI devices has a selector chip before it that looks at the device number sent by the MCU and enables the CS only if the address matches?

If not, how practical/reasonable is to implement it myself, e.g. using a CPLD?

[eleguy]

Maybe I did not get what you are after. Usually devices are selected with their CS. It certainly does consume one GPIO for device and is sometimes a challenge when working in the GPIO limited world. One option to inspect could be ADGS1408 for example. Not the cheapest but has little bit this and that.

[peter-h]

One SPI channel can handle multiple SPI slaves. I do this a lot. They all use the same clock din dout and you just deal with the /cs signals.

However I found that it is highly desirable to use all the slaves in the same SPI mode e.g. 0,0. This should not be needed but in reality it is; for mysterious reasons some devices do seem to care where the clock is parked when /CS goes to 0, or whatever...

Most SPI devices do not have an address byte, do they? That is more an I2C thing, I think.

[Siwastaja]

I think I got what you mean, but am not aware of any. It would be a specialty thing. What is wrong with sharing the bus and using IO pin for each nCS? Another option would be to pick a microcontroller with enough SPI buses, or utilize the built-in connection matrix to share a single peripheral between multiple SPI buses (for example, in STM32, each SPI peripheral can be routed to different pins using Alternative Function configuration; you can change that quickly in software).

[peter-h]

If I was doing this and didn't have enough GPIO for all the /CS signals I would use 3 x GPIO and say a 74HC138 or similar to get 8 x /CS.

Remember that different SPI slaves are very likely to need a different SPI config. Especially if you want to optimise performance you will want to max out the clock speeds, and sometimes you may have a different bit order etc. You have to store the current config and re-config as needed, and then the whole thing is thread-safe, with a mutex. I do this a lot.

[ajb]

If you're already using a timer to trigger the DMA, perhaps it would be possible to use multiple timer compare channels to generate the CS signals?  Lots of different possible solutions depending on the access pattern and capabilities of your particular MCU's peripherals.

You could probably do what you want using a 74x595 or similar and a bit of glue logic.  Use the MCU's CS line to select the '595 directly, and use its parallel outputs to drive the other CS pins.  Use the serial out from the '595 plus some glue logic to latch its outputs and disable its CS on the last bit, and you should be able to send an "address" byte to select the desired CS line before your main payload.  Might take an extra clock cycle or two though.  If you need more than 7-8 CS lines, you could expand with an additional shift register and/or demuxes.

[zapta]

Maybe I did not get what you are after. Usually devices are selected with their CS. It certainly does consume one GPIO for device and is sometimes a challenge when working in the GPIO limited world. One option to inspect could be ADGS1408 for example. Not the cheapest but has little bit this and that.

The access to the SPI devices is done using continuous double buffering DMA, so there is no simple way to switch the next GPS after each SPI transaction.

As for the ADGS1408, what do you have in mind, connecting the MOSI of the devices to the SDO of the ADGS1408 and using the switch to route the CS?

[zapta]

You could probably do what you want using a 74x595 or similar and a bit of glue logic.  Use the MCU's CS line to select the '595 directly, and use its parallel outputs to drive the other CS pins.  Use the serial out from the '595 plus some glue logic to latch its outputs and disable its CS on the last bit, and you should be able to send an "address" byte to select the desired CS line before your main payload.  Might take an extra clock cycle or two though.  If you need more than 7-8 CS lines, you could expand with an additional shift register and/or demuxes.

Even a round robin over let's say 4 devices should be good. If I understand corectly, you suggest to use an external CS counter that will also route the CS to one of 4 outputs. I just need to make sure the firmware/DMA is in sync with the counter.

[PCB.Wiz]

Even a round robin over let's say 4 devices should be good.
If I understand corectly, you suggest to use an external CS counter that will also route the CS to one of 4 outputs. I just need to make sure the firmware/DMA is in sync with the counter.

Yes, if you already have time-slot and DMA working, you can simply advance a counter on the CS edge, and mux the CS, and maybe MISO and MOSI and CLK, if the parts do not allow parallel connect.
You need to either reset the counter to start at a known phase, or read a terminal count to know where the counter is up to.

There are decoders like HCS137/ 237 with inbuilt latches, that could allow you to share some pins ?
(I've not seen decoders with counters. The HC4017 has counter to one of 10, but they are active high outputs )

[dobsonr741]

Why not let the MCU operate all the CS lines, directly or by a HC138? Or perhaps you have a different, external to the MCU timer, if I read it right?

[langwadt]

what devices? some SPI devices can be daisy chained

[SiliconWizard]

I'm not completely sure I understand the rationale - from what I got, you're accessing GPS devices? Those do not spit out data at a high rate. You can still use DMA for transfers but pause for a few cycles between each, select the next with GPIOs, and restart the DMA? So not quite sure what you're trying to optimize, although there may be missing info here, so just a thought.

Relying on a strict sequence that always stays in sync is IMO a recipe for unreliability. Or at least provide a means of "resetting" the sequence on a regular basis, but if you can do that, I'm not sure why you couldn't do what I suggest above as well. Again just wondering, maybe stuff we are missing here.

[Scrts]

Use 74HC595 shift register and tie last output bit to the data input bit of your SPI device. Assuming your SPI devices are 8 bit, you'll have to clock out 16 bits.

Although, it should work, but please simulate beforehand 

[zapta]

I'm not completely sure I understand the rationale...

Here is some background information. I have a STM32H7 design that reads an ADS1261 ADC at 2KHZ over SPI, with round robin over 4 ADC inputs. The reading is done in DMA continuous mode (double buffering) with interrupts at the completion of a buffer (which holds a few hundreds of ADC readings).  Timer 12 of the mCU generates the continuous 2KHz CS pulses and the DMA transfers on each CS the next 13 bytes from the TX buffer and saves the next 13 bytes in the RX bytes, among them the next ADC read value. Each group of 13 TX bytes reads the old value, selects next ADC input, and starts the next conversion. All work reliably with minimum load and interrupts on the CPU.

Now, let's say that instead of reading of 4 channels of the same ADS1261, I want to read a single channel from each of 4 ADS1261 devices and using a single SPI channel.  I need to somehow select the next ADS1261 in a round robin fashion and route the CS only to that device.

(ideally I would like to have a general solution of accessing continuously N different heterogeneous SPI devices, making SPI devices addressable, similar to I2C, but I think that the requirement of reading four ADS1261 capture the essence of the technical challenge).

Some links:
1. Setting the burst byte count (13) per CS. https://github.com/zapta/daq/blob/main/controller/platformio/lib/adc_card/adc_card.cpp#L235

2. Populating the continuous DMA TX buffer with the 13 bytes groups that are sent continiously.  https://github.com/zapta/daq/blob/main/controller/platformio/lib/adc_card/adc_card.cpp#L383

[PCB.Wiz]

(ideally I would like to have a general solution of accessing continuously N different heterogeneous SPI devices, making SPI devices addressable, similar to I2C, but I think that the requirement of reading four ADS1261 capture the essence of the technical challenge).

If you wanted to prepend an address, that would need a CPLD to extract and delay the output CS's but it could be done.
If you are ok with some timing rules, you could use a cheaper small MCU to receive the first SPI byte, then drive a select pin low, which can also gate the CLK to that remote.
It would take a handful of MCU cycles to respond to SPIF, and output the byte to a chip selects port.


A useful, simpler logic candidate looks to be the SN74HCS264, an inverting version of the 164.  This does not need a payload overhead.
a low on /CLR sets all Qn pins high, and then you can clock thru a single low to select 8 slaves.
With schmitt pins, you can drive all of that from one pin, using pulse width rules.
a) Wide pulse = /CLR has time to go low and all pin SET HI, trailing  _/= is ignored as /CLR is still low.
b) Medium pulse AB has time to go low and loads /Q0 = Hi.
c) Narrow pulse loads a HI, so /Q0 = Low

Operation would be a) then c) then b),b),b),b),...

[Peabody]

I think the 74HC138 suggestion is a good option.  You would need to allocate up to three GPIO pins to select one of eight outputs.  Then connect the CS line to one of the active-low output-enable strobes, and the selected output will follow the CS line.

[ajb]

You could probably do what you want using a 74x595 or similar and a bit of glue logic.  Use the MCU's CS line to select the '595 directly, and use its parallel outputs to drive the other CS pins.  Use the serial out from the '595 plus some glue logic to latch its outputs and disable its CS on the last bit, and you should be able to send an "address" byte to select the desired CS line before your main payload.  Might take an extra clock cycle or two though.  If you need more than 7-8 CS lines, you could expand with an additional shift register and/or demuxes.

Even a round robin over let's say 4 devices should be good. If I understand corectly, you suggest to use an external CS counter that will also route the CS to one of 4 outputs. I just need to make sure the firmware/DMA is in sync with the counter.

no, but that’s also an interesting idea.  I was suggesting that you put a serial-to-parallel shift register on the bus with its outputs driving the CS lines of the other devices. The MCU’s CS output is used to select the shift register, and some glue logic attached to the SR’s serial output loads the output register to assert the desired CS line automatically after the first byte is loaded. So you’d just need to tack a byte onto the front of the message to select the right device and it’s otherwise completely transparent to the MCU. Admittedly i have not thought through the details, it might take too much external logic to be sensible.

But leveraging multiple compare channels on the timer that triggers the DMA transactions, or another linked timer, could be helpful in a lot of ways.  You could use the compare outputs pins to directly drive different CS pins in sequence or sequence other external logic, trigger another DMA transaction to a GPIO register containing a bunch of CS output pins…

[zapta]

But leveraging multiple compare channels on the timer that triggers the DMA transactions, or another linked timer, could be helpful in a lot of ways.  You could use the compare outputs pins to directly drive different CS pins in sequence or sequence other external logic, trigger another DMA transaction to a GPIO register containing a bunch of CS output pins…

My goal is to have this capability as abstracted as possible to the MCU, without requiring design changes other than prepending an address byte to the SPI transaction.

I asked in the FPGA forum here about small FPGAs and the once below seems to be a good fit.  It is a stand alone IC, reasonably priced, and should support the minimal complexity of this design. If it listen to the first byte (after CS low) on the MOSI line, without forcing any value on the MISO line, and then asserts one of let's say 8 CS outputs, it can then be used either centrally, sitting near the MCU, or distributed, having one near each device, forming an addressable SPI buss. The extra input can also be used to select address range, so a lot of flexibility.

https://www.digikey.com/en/products/detail/lattice-semiconductor-corporation/LCMXO2-256HC-4SG32C/3232671

https://www.eevblog.com/forum/fpga/help-finding-a-small-and-low-cost-programable-logic-ic/new/#new

[Siwastaja]

Sounds like you have come up with arbitrary constraint of "absolute minimization of CPU time" without clear rationale for why, and then overengineered everything around it to suit this premise, to the point of needing to add specialized extra processors or hardware which probably consumes all those resources (energy, transistors) you tried to save; or actually spend orders of magnitude more. Not to talk about design effort.

Microcontrollers have small interrupt latency and simple to configure peripherals by design. There is nothing wrong configuring an SPI transfer 1 MILLION times a second on STM32H7, much less 2000 times.

Instead, just do it normally; for small packets, don't bother with DMA and consider using SPI FIFOs. For longer packets, configure DMA in the ISR. Problem solved; no specialized hardware, no specialized software.

Please help us help you better and explain what exactly is the reason you think about minimization of CPU time and avoidance of frequent interrupts?

[peter-h]

Exactly. No need for DMA at all.

Also think about the future. While it is easy to configure a "CPU" project which can be retrieved in years to come (e.g. set up a VMWARE VM) try doing it with an FPGA. I used to do FPGA/ASIC design consultancy (until about 1999, mostly Xilinx X3K/X4K) the tools were absolute shit, they were licensed with dongles (nowadays online license checking!!), and they changed all the time. Plus, production life? The X3K went for many years but they were "classics" and with not many other players in the market. Today?? It is IMHO really dumb to use an FPGA anywhere unless absolutely necessary and dictated by extreme performance requirements which absolutely cannot be met in software.

[zapta]

Sounds like you have come up with arbitrary constraint of "absolute minimization of CPU time" without clear rationale for why, and then overengineered everything around it to suit this premise, to the point of needing to add specialized extra processors or hardware which probably consumes all those resources (energy, transistors) you tried to save; or actually spend orders of magnitude more. Not to talk about design effort.

The design I am working on is open ended. Basically a card with a STM32H7 whose free pins got to a bus and cards and functionalities that will be added over time. That's why I prefer to not commit CPU resources at an early stage.

As for design effort, my hobby time is free.

[Siwastaja]

The design I am working on is open ended. Basically a card with a STM32H7 whose free pins got to a bus and cards and functionalities that will be added over time. That's why I prefer to not commit CPU resources at an early stage.

Yes but did you calculate the amount of these "CPU resources", in any way, even hand-wave? Why would you buy a high-end CPU and then not want to use 1% of it to do the task you need it to do, and what it's intended to do? I would understand this desire to leave "room" for future processing needs if it was a significant CPU time in question*, but it's not. It's really really hard to completely avoid interrupts even though DMA exists for that purpose. I think your design principle has hit the wall when you need an external co-processor to assist you not use the CPU.

This SPI interrupt does not even need to be of highest possible priority, so it would not mess with the realtime performance of future functionalities.

*) I have felt filthy writing a handler which is triggered to do non-trivial amount of bitshifting and calculations at 500kHz and spends significant part of CPU time, like 20-30%, but even that is something I found desirable over added external hardware

[zapta]

I do use interrupts, e.g. for I2C, which doesn't sit well with continuous DMA.

As for external hardware, this system is full of external hardware, since the cards are self sufficient. For example, this is an ADC card, with support for load cell and temperature sensors.

https://github.com/zapta/daq/blob/main/adc/kicad/adc.pdf

Modularity and open ended were key design goal. Compactness and minimalist designs were not. The design would be very different if it would be a set functionality and a  single board design.

Anyway, the idea of addressable SPI bus using a generic IC that adds the address functionality is very interesting for me.

[zapta]

It is IMHO really dumb to use an FPGA anywhere...

Aren't they cool, and programming them makes the hobby even more exciting?

[Siwastaja]

Well then, it appears you have made up your mind. FPGA would give you most room for flexibility and future feature creep. Once you do that, get rid of the STM32 and just use a softcore on the FPGA. Use the biggest FPGA you can afford so that you don't run out of resources. They are pretty expensive, but very capable.