Toggling between SPI slaves with nrf_spi_mngr_perform (as opposed to nrf_spi_mngr_schedule)

[ejg2putt]

We've got two SPI slaves that we need to talk to with the 52840 (PCA10056 dev kit for now) using SPI Manager.  In the initialization of these devices, I'd like to use nrf_spi_mngr_perform to set all the initial registers values, read them back, and verify them.  Works great for one SPI slave, but I can't figure out how to manage the CS for both devices (with nrf_spi_mngr_perform).

I understand how to use the pre and post callbacks to manage GPIO's to do the CS via nrf_spi_mngr_schedule, but I believe this is only possible with nrf_spi_mngr_schedule (by setting 

NRF_SPI_PIN_NOT_CONNECTED in the nrf_drv_spi_config_t structure).

Is this possible with nrf_spi_mngr_perform? We prefer to use nrf_spi_mngr_perform for immediate validation of the setup, and simpler code during initialization. We will use nrf_spi_mngr_schedule for the data updates, so we'll use the callbacks to manage the GPIO/CS pins.

Closest I found was this link, is this a valid supported solution?:

https://devzone.nordicsemi.com/f/nordic-q-a/5478/spi-with-multiple-chip-selects

Any way to set a callback after nrf_spi_mngr_perform?

What is the recommended SPI Manager sequence for multiple SPI slaves? Use nrf_spi_mngr_schedule even for code that does not need to be scheduled?

We're running SDK 15.0.

Thanks
Ed

[Jørgen Holmefjord]

Hi,

I'm not sure I understand what you are asking. Do you want to perform multiple transfers using nrf_spi_mngr_perform, and these transfers should have different CS pins? 

nrf_spi_mngr_perform use nrf_spi_mngr_schedule to execute the operations, it just have a blocking while loop at the end to prevent the function from returning before the operations are complete. The functionality should be the same as using nrf_spi_mngr_schedule directly.

Best regards,
Jørgen

[ejg2putt]

That is correct, I want to perform multiple transfers to initialize and verify the two SPI devices - requiring that I can switch CS/GPIO as various points.    The advantage of using _perform is that I could simply setup the multiple transfers and fire off the sequence of init commands.  Essentially issue all the command synchronously instead of asynchronously.  

So without a callback mechanism or some way to intervene between the transfers, the best way to do this is setup a series of individual commands and manage the CS/GPIO that way?

I guess I could setup the same blocking loop in my code for _schedule that _perform implements, either using my own "transaction_in_progess" flag or the cb_data.transaction_in_progress if that's available.

Easy enough to implement, it would be nice to have a "synchronous" way to handle multiple commands to multiple devices.

Thanks

Ed

[Jørgen Holmefjord]

Yes, I think implementing this yourself would be the best solution. I have not seen other customers requesting this use-case of doing blocking transfers to different devices using this library.