ppi and softdevice

[pieterg]

I'm evaluating the nRF52840_DK with nRF5_SDK_17.0.2

After doing some tests with ppi to timestamp gpio events, I'm now enabling the softdevice.

This leads to two questions;

1. I'm using nrfx_ppi rather than nrf_ppi, because I like to allocate ppi channels without having to specify hardcoded channel ids

With the softdevice enabled, we should use sd_ppi_channel_enable_clr instead of nrf_ppi_channel_disable.

However, nrfx_ppi_channel_free calls nrf_ppi_channel_disable internally (even if I already disabled the channel myself).

I could switch to nrf_ppi, but that would mean I cannot use the dynamic channel allocation anymore.

(Or I can remove the nrf_ppi_channel_disable call from nrfx_ppi_channel_free and make sure I disabled the channel before free-ing it)

2. There is no sd_ppi_channel_fork_assign. Does this mean we can safely use nrfx_ppi_channel_fork_assign (or nrf_ppi_fork_endpoint_setup) with the softdevice running?

Or does it mean we cannot use fork endpoints while having an active sofdevice?

[ovrebekk]

Hi 

To be honest I always assumed the nrf_drv_ppi driver would use SoftDevice calls under the hood, but I realize now this is not the case. 

That being said, the PPI peripheral is not protected by the SoftDevice, so there is really no reason to avoid using the nrfx_ppi driver together with the SoftDevice. 

The SoftDevice will only use the static PPI channels (channel 20 and up), while all the configurable channels are available to the application. 

In other words I would recommend just using the driver, whether or not the SoftDevice is enabed. 

Best regards
Torbjørn

[pieterg]

Thanks for clearing that up, so there is no reason to use the sd_ppi_channel_* calls?

I'll keep using nrfx_ppi then.

[ovrebekk]

Hi 

The only reason would be to get an error if you try using the higher channels (20 and up), but if you use nrfx_ppi with dynamic channel allocation this shouldn't really happen anyway. 

Best regards
Torbjørn