RE: Create a bi-directional pin using PPI

dbuijsma — Mon, 16 Apr 2018 19:22:42 GMT

No problem! Thanks for the fast response.

The second reason for using just the PPI, which I should have mentioned, is to be able to guarantee the PIR waveform timing. The issue with using the CPU for any aspect of the read-out process is that the Softdevice might interfere and we end up not making the timing specs for the PIR sensor (some parts of the waveform need to be timed within < 2us). With the Softdevice doing its own thing, this is almost guaranteed to be an issue.

I've got the waveform generation covered like you mention with timers and CC-events/GPIOTE tasks. The plan was to clock the data into the SPI peripheral (slave mode). If I'm going to use IRQs, that's no longer necessary. I just need to be able to generate IRQs timely (without Softdevice shenanigans).

If you don't mind, could you look at some ideas to get around the issue (which don't involve changing the HW) to make sure I am not missing potentially better options?

1) Make sure the Softdevice is not used or even disabled while we're sampling from the sensor. I noticed this thread which suggests this is possible: https://devzone.nordicsemi.com/f/nordic-q-a/24426/disabling-s132-softdevice-when-running-freertos. However, this option will require some major changes in the current application-level code which is relying on the Softdevice to always be enabled.

2) A little ugly, but...change the vector table so we have a hook into this and can re-direct the SD -IRQ (level 0) handler and forward this from our super-short "change-pin-direction" handler.

3) Even uglier: Use the PPI/MWU + some other peripheral with EasyDMA to generate a NMI which we can then use as our IRQ handler to change the pin direction.

4) Blasphemy...but: In theory I could edit the Softdevice binary to change the IRQ (level 0) to a lower level such that my application. I am guessing that this is a no-go (Nordic user agreement violation?), but wanted to mention it nonetheless in case someone has done it before.

Now ideally there would have been a task in the GPIOTE peripheral to set direction on a pin. This would at least for my case really be a useful feature for the next nRF52 SoC. Just say'in!

Thanks,

Dirk

RE: Create a bi-directional pin using PPI

haakonsh — Mon, 16 Apr 2018 11:41:53 GMT

Hey Dirk,

I believe I've made a mistake.

You cannot disable a GPIOTE pin via PPI once it's configured as an output, you can only disconnect it from the PPI system. It will drive the input pin to whatever voltage of its last state.

This means that you will need to reconfigure the output pins direction via CPU. The good news is that you will only need one pin instead of two.

You should use a TIMER to control the output pin. Create a one-shot TIMER with COMPARE0 event connected to the output pins GPIOTE toggle task (initial GPIO state high), COMPARE1 event connected to the output pins GPIOTE toggle task, and COMPARE2 event to fire a CPU interrupt.

COMPARE0 can be set to whatever time you want, it starts the sequence of events by pulling the output pin low. COMPARE1 needs to be set 1µs after COMPARE0 and COMPARE2 needs to be set 1µs after COMPARE1.

Cheers,

Håkon.