NRF52 as SPI master with Multiple Slaves

[TFETT]

Hello, my project has 3 different devices (2 sensor and flash memory) on the same SPI bus all with their own CS. I ran across the following question, which has a response for a workaround for the NRF51. Upon jumping into the NRF52 SDK 12.2 documentation and it looks like the SPI structure has slightly changed.

Is the given solution in the previous post still applicable and if so what changes need to be made to make it work with the SDK 12.2.

If not what is the best route I need to implement 3 slaves on SPI. (GPIOTE and handle each CS individually?)

Thanks in advance

[Roger Clark]

You may also want to consider putting at least 2 of them on different SPI pins. Because SPI is asynchronous, you could transfer to 2 devices at once, which would reduce the amount of time your processor has to be awake.

I know the nRF51 does Not have hardware Chip select, so you are better off setting it to Not Connected in the SPI config struct and then controlling it via GPIO yourself.

I did attend the nRF52 seminar and I recall the Chip Select question being asked (possibly my me), but I cant recall the answer with any certainty, I think it may still not be hardware CS on the 52, but you better wait fo a more definitive answer

[SRA]

I have a project like that on an STM32 and it was much easier to just use software control of the CS pin with a struct that stored all the pin and port info than it was to try and use the hardware CS pin moving around.

Ill give another vote for using parallel SPINbusses if you can swing it. Esp of not all your SPI devices are the same speed and settings. My project I also change modes and bitrates all stored in that same struct, it works great but it was annoying to write. In my case I littersally didn't have a single extra pin free though.

[Roger Clark]

@SRA

Good point about the differnt bus speeds whch may be needed. Also some devices need differnt SPI "mode" ( clock edge to data valid) but most peripherals seem to use the default mode.

[TFETT]

Thanks for the feedback @SRA & @Roger Clark. I'll do an analysis of each device to better understand speeds and modes for each one. In general my design is very space constrained, thus the fewer buses means a simpler design. I will try to follow up with my layout resource and get her thoughts on the possible implications of adding another SPI bus. All the same this will still result in two slaves on one SPI bus.

[Roger Clark]

@TFETT

You may find having 2 busses actually saves space, or saves via's, so its best to speak to your layout person.

But you'd still need a CS line for each device, so there is no saving there

(Well most devices need a CS as part of their data comm's for synchronisation of start of a new command)