I am using an nRF reference board. Say e104-bt5010a-tb. Now I want to change the SPI pins (I know that I can have two devices connected at the same time as SPI is a bus and the pins on the slave should go to high impedance) using the muxing on the silicon.
What I do now is change the device (actually add another device in boards/common/e104-bt50xxa-tb/include/periph_conf.h) with the same .dev = NRF_SPIM0, but different pins.
Is there another way to do this using the current interface? Seems that spi_config is hardcoded or am I missing something?
You would just edit spi_config in periph_conf.h.
On nRF you can use the same NRF_SPIM0 in multiple instances (see #18478).
I have done that already. But is there any other way?
I’m not sure what you mean - this is the only place where SPI busses are configured.
Are you looking for something like Device Tree?
I think what @terry.wrist is trying to do is use a single SPI peripheral to talk to two SPI devices, but each device is connected to different pins of the MCU. Presumably, the SPI peripheral can be mapped to either set of pins, as is pretty common.
If I’m right, I’d suggest just placing both devices on the same set of pins and use chip select to select between the two devices. Or, chain them together and use a gpio to drive their strobe/latch inputs if they have those.
There may be ways to do what I think you are asking, but they may not be as portable or strait forward in the code.
Actually, the nRF5x can just share the backing hardware peripheral to provide multiple SPI buses (and even I2C buses).
This previously has been a common source of misconfigurations, as I2C0 and SPI0 were sharing the same hardware; but our tests are specialized apps that do not enable both SPI and I2C at the same time, so that issues only surfaced when complex applications were flashed. In addition, the Bangle.js2 has more I2C buses than hardware is available. This lead adapting the I2C and SPI driver so that they can share the hardware. Any SPI/I2C block can provide any number of I2C buses, any number of SPI buses, or any number of both I2C and SPI buses. However, while one bus is busy the others are blocked until the busy bus is done. So you don’t want to have a notorious I2C clock stretcher backed by the same hardware as a fast SPI connected network device.
The microbit-v2 is one example board that makes use of periph sharing that is already upstream. The NRF_TWIM0 and the NRF_SPIM0 refers to the same hardware, still both SPI and I2C can be used in the same app.
And we could totally also add this for the Atmel Microchip MCUs. There SERCOMs are also shared between SPI and I2C and the amount of SERCOMs has been an issue when designing complex hardware, so it would certainly be a win.