Multiple devices on the same SPI bus but with different SPI configs

[jean_prieur]

Posted on June 17, 2013 at 10:37

Hello,

I use the STM32F407 and I have to link 3 different slave devices on the same SPI bus (an accelerometer, a touchpad controller and a screen). I have no other solutions. Each device is activated with chip select pin (CS).The problem is, devices have not the same SPI configuration, for example the accelerometer is driven by a clock at high level by default and the touchpad controller is driven by a clock at low level.Does anyone has already used SPI with different configurations ? Can I change the SPI config each time I want to drive a device ?Thanks for your advice !Jean

[frankmeyer9]

Posted on June 17, 2013 at 11:30

Can I change the SPI config each time I want to drive a device ?

Of course you can. But that doesn't sound like a good solution. Assuming 20...100Hz update rate for the accelerometer and the touch controller, and even higher bandwidth requirements for the LCD screen, you are going to spend a significant amount of time reconfiguring the SPI peripheral. The F407 has three SPI interfaces. Can't you use at least two of them ? And if possible, you can group two compatible devices on one interface.

[jean_prieur]

Posted on June 17, 2013 at 11:49

Unfortunatly I can't... The SPI1 pins are used by the internal DAC and the SPI3 pins are used by the SD card.

If I only reconfigure the SPI clock level, does it will take a great amount of time ? Is it possible to estimate ?

[John F.]

Posted on June 17, 2013 at 11:55

Note from the Reference Manual - you must disable the SPI prior to changing the CPOL/CPHA bits.

Note: Prior to changing the CPOL/CPHA bits the SPI must be disabled by resetting the SPE bit.

Master and slave must be programmed with the same timing mode. The idle state of SCK must correspond to the polarity selected in the SPI_CR1 register (by pulling up SCK if CPOL=1 or pulling down SCK if CPOL=0). The Data Frame Format (8- or 16-bit) is selected through the DFF bit in SPI_CR1 register, and determines the data length during transmission/reception.

[frankmeyer9]

Posted on June 17, 2013 at 12:43

If I only reconfigure the SPI clock level, does it will take a great amount of time ? Is it possible to estimate ?

I never tried that, but as it is a configurable divider, I do not expect a delay (as with the clock setup & PLL). But consider John's comment above. Perhaps you can mate one of the devices with  the SD card ? It uses a CS, too, and can thus be separated logically. Doesn't have any of these chips other interface options, like I2C ? Or can't you use alternatives ? Albeit feasable, I expect a performance problem with your solution.

[jean_prieur]

Posted on June 17, 2013 at 13:02

Maybe it's not a problem if the clock level is at level high or low by default ? I mean, this is  lock edges that are important... If the device see falling edges and rising edges it will understand ?

The SD card use SDIO protocol (not the SPI) but SDIO is on the same pins that SPI3 :( and I2C is not possible...

[John F.]

Posted on June 17, 2013 at 14:06

It's a hardware problem you have to solve. It depends on your specific devices. Some ignore the clock and data lines while not selected and some don't and will get ''confused''. For those, you can sometimes use external gating. Have you considered if you can invert the clock and / or data with hardware inverters to get all your devices to use the same SPI setup?

[raptorhal2]

Posted on June 17, 2013 at 16:16

There is a different solution. It is not very elegant and requires careful consideration of life cycle maintenance.

Instead of using SPI, you can bit bang the interface and thereby generate custom signals based on which peripheral is selected. Cheers, Hal

[John F.]

Posted on June 17, 2013 at 17:45

Hal - problems may arise if a deselected device does not ignore the SPI clock and data lines even with ''bit-banging''. I think we've over-cooked this. The hardware has to be considered in detail. Also, if the SPI needs re-configuring, it really doesn't take very long and could be faster if the library functions are examined and just the relevant register writes extracted.

[frankmeyer9]

Posted on June 18, 2013 at 11:57

Hal - problems may arise if a deselected device does not ignore the SPI clock and data lines even with ''bit-banging''.

And the other, bigger downside of bit-banging is the waste of core performance. It might be o.k. for polling a sensor each dozen of milliseconds. But as I understand this application, it is heavily based on SPI throughput and timing. And I sense an incompatibility here between the application requirements and the solution intended by the OP.