twi_hw_master.c assumes PPI channel 0 is available

[Nick Pelis]

Throughout twi_hw_master.c, there are lots of places where the code directly accesses PPI channel #0 and thus assumes it's available, as in:

NRF_PPI->CH[0].TEP = (uint32_t)&NRF_TWI1->TASKS_STOP;

Later on, if I invoke nrf_drv_ppi_channel_alloc() to use one of the PPI channels for something in my own application, that function will initially return channel #0, which in incorrect since that entry is already taken by the TWI master.

This seems like a bug. It seems like nrf_drv_ppi_channel_alloc() should look at each of the EEP/TEP registers to find which channels are actually allocated, rather than rely the m_channels_allocated bitmask. It also seems like TWI HW Master should use nrf_drv_ppi_channel_alloc() to prevent these collisions. This is in SDK v8.0.0. Thoughts?

[RK]

If you are using any recent version of the nrf silicon then the PPI code for the TWI master is unnecessary and can/should be replaced by the SHORTS. That hack was only there because the shorts didn't work on the first revision of the silicon. It's probably about time some of that code was updated in the latest SDKs as they are documented only to work with more recent silicon anyway.

And yes the code is probably wrong because the twi master code long predates the ppi channel management code and they probably don't work very well together.

Fortunately all that code is only a starting point and you can change it to suit your needs if you want TWI and PPI working together.