NRF52 as SPI master with Multiple Slaves

RE: NRF52 as SPI master with Multiple Slaves

RixtronixLAB — Wed, 21 Apr 2021 06:46:41 GMT

Which GPIO port do you use for MOSI,MISO and SCK ? I have like this :

MISO = P 0.20

MOSI = P 0.02

SCK = P 0.21

CS = P 1.12

CS_LCD = P 1.11

Is it possible ?

RE: NRF52 as SPI master with Multiple Slaves

YASH — Thu, 13 Jul 2017 08:14:13 GMT

What Should i write in case of nrf51422? in place of mw_spi_instance.drv_inst_idx ? Please help, Thank you in advance.

RE: NRF52 as SPI master with Multiple Slaves

Dave_couling — Fri, 07 Jul 2017 23:09:13 GMT

I did the following to add this capability:

I moved the definition of spi_control_block_t from nrf_drv_spi.c to nrf_drv_spi.h, just above the declaration of nrf_drv_spi_init
Also added #include "nrf_drv_common.h" to the top of nrf_drv_spi.h for compiling
This allows the spi_control_block_t struct to be accessed my any source code that includes "nrf_drv_spi.h". Here is my CS change function:

/*
- Function for changing Chip Selecti pins in the nRF52 */
void spi_switch_chips( uint32_t chip_select ) { volatile spi_control_block_t * my_setup = mw_spi_instance.drv_inst_idx; my_setup->ss_pin = chip_select;
```
 //A Slave select must be set as high before setting it as output,
 //because during connect it to the pin it causes glitches.
 nrf_gpio_pin_set(my_setup->ss_pin);
 nrf_gpio_cfg_output(my_setup->ss_pin);
 nrf_gpio_pin_set(my_setup->ss_pin);
```
}

RE: NRF52 as SPI master with Multiple Slaves

Roger Clark — Tue, 24 Jan 2017 01:37:50 GMT

@SRA

Interesting point about star vs daisy chain (not sure if daisy chain is the correct term in this case, but I know what you mean)

I've only had issues with SPI on quite long wires to external displays when running very high speeds (36Mhz) - and that was just the MCU on one end and the display on the other. I had to shorten the leads to the display, and also separate them, as the capacitance in the ribbon cable was causing crosstalk.

BTW. I don't think anyone has answered @TFETT's last question about the time to reconfigure the SPI to a different speed each time.

I'd suggest that @TFETT look in the driver code for the SPI and see how much code is in the SPI config api call.

I'm not an expert on the nRF51 hardware, but I know that other MCU's etc STM32 have to completely shut down the SPI sub system and re-start it, if you want to change the clock speed.

RE: NRF52 as SPI master with Multiple Slaves

SRA — Tue, 24 Jan 2017 00:35:50 GMT

What everyone else wrote in your comments is good. If you can run mutliple busses, do so because you'll have parallel access and avoid some traps with switching speeds and CS lines. If you absolutely must run multiple devices, that's fine, just plan on not using the hardware CS line imo and come up with a CS_Changer(myDevice) to handle the SPI details. You may need to work around modes and speeds.

On the multiple slaves, be careful of how you share the MOSI/MISO lines. You can get into a termination and reflection issue. I was surprised to find out how complex SPI to multiple devices can be, most people just hook it up and go, but to really do it right, can be a lot of work.

If you can daisy chain is better and solves these termination issues, if you must star, do it as short as possible, consider a 22ohm resistor inline to each device off the MISO line if the total MISO length is long, keep the stubs as short as possible.

Do it right, don't overthink it too much. Plan on testing with a scope when you get a prototype up. Will only be an issue if you're going to push these SPI devices as fast as they go.

RE: NRF52 as SPI master with Multiple Slaves

TFETT — Mon, 23 Jan 2017 18:20:26 GMT

I spoke to may layout person and it looks like 2 SPI buses is an option. It appears all the devices use the same mode, but varying speeds. With this change I will still need to have 2 slaves on a single SPI bus. As such when I transition between the slaves do I need to unint the driver and then reinit the driver? Is the overhead light or heavy between this transfer.

RE: NRF52 as SPI master with Multiple Slaves

Roger Clark — Mon, 23 Jan 2017 02:53:04 GMT

@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)

RE: NRF52 as SPI master with Multiple Slaves

TFETT — Mon, 23 Jan 2017 02:15:08 GMT

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.

RE: NRF52 as SPI master with Multiple Slaves

Roger Clark — Sun, 22 Jan 2017 20:43:30 GMT

@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.

RE: NRF52 as SPI master with Multiple Slaves

SRA — Sun, 22 Jan 2017 16:51:06 GMT

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.

RE: NRF52 as SPI master with Multiple Slaves

Roger Clark — Sat, 21 Jan 2017 06:41:52 GMT

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