nRF5340 peripheral selection w/Engineering A silicon - comments please

RE: nRF5340 peripheral selection w/Engineering A silicon - comments please

navigator — Tue, 31 Mar 2020 23:13:13 GMT

Thanks Einar for pointing me in the right direction 🙂

Regarding my original plan..

I will use SPI sequentially instead of concurrently, with 3 slave CSNs using SPIM4 w/DMA.

I will use 4 pins for I2C, on 2 buses -- separating high speed from low speed devices. Since I have only one peripheral available, I will use TWIM1 and need to init / un-init each time I want to switch between the two buses. I do it this way so when the next rev of silicon comes (and errata 1000kHz gets fixed), I don't have to change my layout, just drop in the new chip, and change the SW to use the new dedicated TWIM2.

Lastly I will use UARTE0, and get rid of the concurrency, but talk to two devices. I will alternate between talking to the devices on different pins using init/un-init, then later when the new silicon arrives, I can use dedicated UARTE3 and keep my layout. It will need a little handshaking to turn off the remote transmit when there is nobody home to receive....

Thanks for help!

RE: nRF5340 peripheral selection w/Engineering A silicon - comments please

Einar Thorsrud — Tue, 31 Mar 2020 07:52:18 GMT

Hi,

The Device Tree approach used in Zephyr does not work with having the same pins for several peripherals, so you need to use the nrfx drivers directly. Then, you basically follow this approach:

Initialize the peripheral when you need it.
Use it
Uninitialized peripheral when done.
Now you can do the same with the other peripheral of the same ID, since the first peripheral is no longer in use. And so on...

Taking SPIM as an example, this means that for step 1 you initialize it with nrfx_spim_init(), use it as described in the API doc and uninitialized it with nrfx_spim_uninit().

You can refer to nRF91 nrfx example to see an example of how to use nrfx drivers directly (there is no example specifically for nRF5340, but the principles are the same).

RE: nRF5340 peripheral selection w/Engineering A silicon - comments please

navigator — Mon, 30 Mar 2020 15:21:47 GMT

Thanks Einar, I understand. Could you be so kind as to point me to a code snippet of the best practice technique to disable/reenable a peripheral as you suggest?

RE: nRF5340 peripheral selection w/Engineering A silicon - comments please

Einar Thorsrud — Mon, 30 Mar 2020 14:34:41 GMT

Hi,

The QSPI peripheral can only be used for QSPI.

Regarding the general issue of not having enough peripherals to use concurrently, I would like to mention that unless you need all enabled simultaneously, you could aways reconfigure the peripheral. For instance, you could use both SPIM0 and TWIM0 in the same product, just that you would have to disable SPIM0 in order to enable TWIM0, and so on.

RE: nRF5340 peripheral selection w/Engineering A silicon - comments please

navigator — Sat, 28 Mar 2020 13:46:58 GMT

Yeah, I'm starting to see this is not going to work at all.

I get to pick one: SPIM0 or TWIM0 or UARTE0
I get to pick one: SPIM1 or TWIM1 or UARTE1
I get to pick one: SPIM4 or TRACEDATA
I get to pick one: SPIM2 or TWIM2 or UARTE2 (but none of these work in Engineering A silicon)
I get to pick one: SPIM3 or TWIM3 or UARTE3 (but none of these work in Engineering A silicon)
QSPI comes without conflict.

So I am going to need to cut back. I knew it was looking too easy. Can I run all three SPI slaves with same QSPI peripheral using different CSN lines....when only one slave supports QSPI, the others are straight SPI ? Does the QSPI peripheral allow me to I mix and match using some config magic, or does it only service QSPI slaves?

Thanks!