[riot-notifications] [RIOT-OS/RIOT] periph/gpio: new expandable GPIO API (#14602)
notifications at github.com
Thu Nov 12 18:50:49 CET 2020
> I really would like to see this finally getting upstream.
Me too :wink: Unfortunatly, I'm completly busy due to the second Corona online semester. That's why I didn't contribute anything to RIOT in the last months. All my contributions are currently on hold. This will probably remain so for the next two months. But I'm willing to resume my work after that.
Maybe the PR seems to be too fat, but it isn't. The core of this PR are just a small number of files.
- Only some small changes in [`drivers/include/periph/gpio.h`](https://github.com/RIOT-OS/RIOT/pull/14602/files#diff-5b4e5a3286193d56d2cbf54fbf0d3252c6768994a6ee8bd1899b6a09db665187).
- Definition of the the new GPIO API in [`drivers/include/periph/gpio_exp.h`](https://github.com/RIOT-OS/RIOT/pull/14602/files#diff-940ad3fa1fc5b4ab32db66f349ee4d30541463b182975e8c17c6e87405ec9cbb)
- CPU driver handling in [`drivers/periph_common/gpio.c`](https://github.com/RIOT-OS/RIOT/pull/14602/files#diff-93b328270681e5c53fcf5a4a13262e3f9d4cecbf5cb629b7653bcceafde22765)
- Test application in `tests/periph_gpio_exp`.
That's it. All other changes in the source code are just small modifications to make the code compilable with the new `gpio_t` type.
The new GPIO API is completely transparent for existing applications and the existing high-level API with one exception, comparision functions have to be used instead of value comparisons due to the structured `gpio_t`.
> 1. Addition of port access for peripheral GPIO ports, ideally as a `static inline` header only implementation for single CPU cycle access even without `LTO=1`
> * As this would be independent of the existing `periph_gpio` API, this could be added one platform at a time
As already mentioned, the current approach doesn't require that all platforms implement the new GPIO API at the same time. It can be done platform by platform. A platform that supports the new GPIO API just provides the feature `periph_gpio_exp`. If a platform doesn't support the new GPIO API, it just uses the old one.
> * This API will remain useful for high throughput bit-banging, even after a common high-level GPIO API for both external and peripheral GPIOs finally is upstream
> * And having a super fast low level alternative can be a good excuse for trading in some speed for convenience in the high level GPIO API
> 2. Once all platforms have the "`periph_gpio_ng`", we could replace `periph_gpio` with a common implementation on top of `periph_gpio_ng`
> 3. A port access API to peripheral GPIO extender
> * This could be done in parallel and fully independent of 1. / 2.
> * However, the function signatures should be the same, as ultimately we want a common high level GPIO API
> 4. Once parts 1. - 3. are upstream: A common high level GPIO API
> * This should be easier now, as `periph_gpio` is now a common platform independent implementation based on `periph_gpio_ng`. So only one place to modify.
> Does this sound reasonable? I could help with reviewing and/or coding parts of this.
The critical point seems to be the new structured GPIO type which consists of a port of type `gpio_port_t` and pin of type `gpio_pin_t`. `gpio_port_t` is also required by the low-level API and I'm not yet sure whether it is possible to define it without the definition of the stuctured `gpio_t` of the high-level API.
If I understand your approach correctly, you would split [`drivers/include/periph/gpio_exp.h`](https://github.com/RIOT-OS/RIOT/pull/14602/files#diff-940ad3fa1fc5b4ab32db66f349ee4d30541463b182975e8c17c6e87405ec9cbb) into two parts, the definition of the low-level API and the definition of the high level API that would be introduced later. Right?
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...
More information about the notifications