Complex SPI transactions with PPI compatible with Zephyr?

[Kyrre Aalerud]

I have been trying to understand how we can use the PPI system to bypass extra callback handlers and threads in Zephyr to retrieve data from external SPI device based on external pin trigger.

So far my understanding of the PPI system is it can hold a configured xfer and trigger it upon even input. This input can come from a gpio pin event output.
This way only works as long as the transfer from the SPI unit is a direct read or write event with no additional transaction data or buffers.

A normal SPI transceive via the normal zephyr drivers and API works by using a transaction manager that keeps the state of the device intact and updates a ctx structure with a set of tx and rx buffers and counts. It then works it's way through these allowing it to send, for example, an address to the external device from the first tx buffer in the set, while ignoring the reception, having a NULL rx buffer before going on to the second set of buffers where the tx buffer is NULL and rx buffer is now valid and a count tells it to receive a set of data values.

It does not look like this is easily translated into the PPI required system and the EasyDMA system that could be used in place of this to potentially reconfigure is not implemented.
From what I understand it would have to use the PPI system by first setting up the transfer complete event in spim to prepare for changing the buffers of the spim, Then set up a spim transfer that is held, expecting a input trigger. The trigger would then cause the initial address transfer to take place, followed by the finish event that causes a reconfiguring of spim to retrieve the data. However, I do not see how this can also reconfigure PPI to not transfer the new config again for the end event. This even event must also be changed to create a callback for transfer done, and set up the initial address transfer again.

Am I missing something here?
Are there really no library or examples already doing this in Zephyr?
This seems like an obvious thing the PPI system was meant for, and it would offload a lot of cpu activity and interrupts.

[Vidar Berg]

Hello,

For the scenario you outline you will likely need to work work with the nrfx driver APIs directly. There you have the nrfx_spim_xfer() function which lets you set up repeated TXRX transfers with auto increment of the RX and TX pointer (easyDMA list feature) and optionally with the END interrupt disabled (NRFX_SPIM_FLAG_NO_XFER_EVT_HANDLER).

Note that when using the NRFX_SPIM_FLAG_NO_XFER_EVT_HANDLER flag, you can connect the END event via PPI to a TIMER in counter mode to keep track how many transfers have been completed.

The Zephyr nrfx use example demonstrates how you can use nrfx drivers in the SDK.

Best regards,

Vidar

[Kyrre Aalerud]

This is exactly what I am describing, but it handles a single transfer only. The complex function of multiple tx and rx buffers and events to handle a potential setup or address in external unit is handled by the spi library and interrupt handler and as such is incapable of handling this via ppi and not involving the cpu.

[Vidar Berg]

an address to the external device from the first tx buffer in the set, while ignoring the reception, having a NULL rx buffer before going on to the second set of buffers where the tx buffer is NULL and rx buffer is now valid and a count tells it to receive a set of data values.

What is the reason you can't set this up as a single transfer? Is it because you don't want to waste RX and TX buffers, or is it because you need to de-assert the CS line between these 2 transactions?

[Kyrre Aalerud]

You are correct, this can be done in a single operation with 1 dummy byte in receive buffer and 1 byte length set in tx_length. It was a mistake on my part assuming the CS needed deasserting between the transfers. This is true for the memory chip but not the sensor that we are using and where we want to optimize. It is thus possible with a single transaction.

[Vidar Berg]

That is good news. Thank you for the update.