[riot-notifications] [RIOT-OS/RIOT] periph/gpio: new expandable GPIO API (#14602)

Marian Buschsieweke notifications at github.com
Wed Aug 25 09:43:43 CEST 2021

I currently need a ws281x driver for the nRF52 family and reconsidered the approach. Basically, a fast (1-2 CPU cycles) GPIO API that doesn't rely on LTO and parameters being correctly identified as compile time constants would allow ignoring the overhead of the GPIO API for the bit-banging timing. Adding a separate API for precise busy-waiting for short durations (maybe using the SysTick timer on Cortex-M rather than counting CPU cycles to also work for Cortex M7 and not having to experimentally the number of CPU cycles per loop iteration) would do the trick.

I'm currently working on a new low-level peripheral GPIO API that is addressing this and a couple of other limitations of the current GPIO API, which is loosely based on this PR. It will however not take GPIO extenders into account. The current pin-oriented API can easily be implemented on top of that at one place - and likely most users will stick with the current API. It should be way easier to hook GPIO extenders into the pin-oriented GPIO API once there is only a single, hardware independent implementation of it.

The low-level port-oriented GPIO API that I'm working on is IMO not the right place for hooking in GPIO extenders, as this would affect timing. If we want to do precise bit-banging as required for speaking to the ws281x, we are limited to using the peripheral GPIOs and depend on reliable timing of GPIO accesses. Use-cases not depending on this will likely prefer the pin-based API anyway and will work just fine for external GPIOs.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210825/322bff00/attachment-0001.htm>

More information about the notifications mailing list