Fix erratum 58 workaround

[mark9064]

• No longer clobbers PPI and GPIOTE 0
  • GPIOTE channel is allocated, PPI is a well defined constant (still CH 0)
• Refactored to use NRF SDK where appropriate
• Tracks whether workaround is active (needed for GPIOTE management)

Split from #1869

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	377752B	272B
data	940B	0B
bss	63548B	8B

[JF002]

Other than improving the code readability, do those changes fix/improve something ? (no judgment here, I'm just curious)

Refactored to use NRF SDK where appropriate

Is this really mandatory? I'm trying to limit our dependency to the NRF SDK to the strict minimum, and if possible only use the MDK part of it. At the beginning of the project, when I wrote all those low-level drivers, I would use the SDK and... debugging was a nightmare, the code readability was really bad and it made it more difficult to understand what it was doing compared to what I understood from the datasheet. In this case, since we are only accessing a few registers, I'm not sure we need the help of those functions from the SDK.

Tracks whether workaround is active (needed for GPIOTE management)

Was there any issue with the previous implementation that would not check if the workaround was enabled/disabled (once again, I'm just curious :) )

[mark9064]

InfiniTime uses the SDK for GPIOTE management at the moment. I can remove the PPI setup stuff easily (though I'd just be reimplementing the functions from the SDK verbatim in InfiniTime, the nrf_ functions are very simple), but the GPIOTE bits are hard as other parts of the project uses the SDK for pin allocation. At the moment, the workaround just assumes GPIOTE channel 0 is free and replaces whatever is on it. The NRF SDK allocates GPIOTE channels from the low power block for input channels, and from the start (index 0) for output channels. This is why the workaround hasn't broken other parts of the project using GPIOTE like the side button. Anyway, when I set up AOD which uses GPIOTE it wasn't working - and of course it was because this workaround was replacing it as the SDK was allocating AOD channel 0 (as AOD uses GPIOTE for output rather than input).

We can choose to track GPIOTE channels either with the SDK or manually. But we should not do both. If we are getting rid of the SDK, we should remove it from the rest of the project too.

Tracking whether the workaround is active is needed to avoid double freeing/allocating GPIOTE/PPI channels with the SDK

[JF002]

Thanks for the clarification @mark9064.

As I said, I try to limit the use of the NRF SDK as much as possible because I had some very difficult time debugging I²C and SPI issues for which the SDK would make things more complicated than needed. Sometimes, writing a value in a specific register (according to the datasheet) is way simpler than initializing, configuring and using one of those nrfx module.

But I get your point : some parts of InfiniTime still use NRF SDK modules, and in this specific case, not using it would make things more complex and less readable. So... let's stick with your implementation 👍