[sdiy] Many SPI slave devices on the same PIC master BUS..

[Brian Willoughby]

Yes, it might be a long journey of learning.

I have developed SPI firmware for the TMS320 DSP, PIC18F, and TM4C ARM. Each has different abilities and quirks, and of course there is the interaction between the SPI Master and Slave with respect to whether they support the exact variation of SPI needed (there is no standard).

With the TMS320 DSP, the SPI bus runs at 18 MHz with DMA to shuttle each 16-bit ADC value into a circular/ping-pong buffer. Because SPI input happens in parallel with SPI output, this required DMA buffers filled with ADC commands, and that DMA channel was triggered by a Timer clock divider.

With the TM4C ARM, I was able to get 60 MHz SPI running, but it was quite a challenge. The TM4C has a FIFO for the SPI, so a little bit of jitter from the code can be absorbed. Using a 'scope, though, I learned that the overhead of calling a function for each SPI byte was causing a gap between bytes on the SPI bus. I switched from the TivaWare DriverLib functions to macros that directly access the peripheral registers, and then suddenly the ARM chip could handle byte transfers with no gap in the clock periods.

For the PIC, the updates are only happening at 5 kHz, but there was still a problem because the 5 kHz interrupt owned the SPI bus and so other SPI peripherals could not be accessed outside the interrupt. Theoretically, interrupts could have been masked to allow the other SPI peripherals to be accessed, but the 5 kHz period was crucial and therefore the interrupt could not be masked. The solution here was to access other SPI peripherals at the end of the interrupt handler, rather than in the main code execution path.

In each case, it was necessary to prototype some code, push the hardware to its limits, and usually connect a 'scope to see how closely the hardware operated vis-a-vis the desired firmware design.


One thing that can be important to establish is whether each peripheral has a different maximum clock rate. If so, you need to determine how to safely change the SPI clock rate before selecting and communicating with each device. Some processors make it easy to change clock rates. Others end up requiring the SPI peripheral to be reset in order to run at a different speed. And then there are the vendor libraries which may not do the right thing, and so you have to learn how to rewrite the functions in the library to perform at a higher standard.

Brian Willoughby


On Mar 1, 2021, at 18:03, Jean-Pierre Desrochers <jpdesroc at oricom.ca> wrote:
> Hi Brian,
> 
> I'm using a PIC16F1783 on a demo board
> connected to a daughter board (solderless connections proto board)
> for the external SPI devices.
> 
> And yes the MISO pin could be a problem here.
> Maybe a little pullup  (or pull down ) resistor (around 10k) on the MISO
> pin of the master PIC could help..
> So far I use a 23LC512 SPI SRAM with great success.
> reading/writing to it easy on all the 65536 addresses.
> But I'm experiencing kind of 'jitters' on the received bytes
> when I add one or 2 other SPI devices (each have their own CS pulses).
> One MAX11100 ADC and one LTC2641 DAC to name them..
> I run the SCK at 4Mhz (250ns pulse period).
> The jitters could be from my actual code..
> I have to check that.