[riot-notifications] [RIOT-OS/RIOT] periph/gpio: enable API usage for expanders (#9690)

Kaspar Schleiser notifications at github.com
Wed Jan 9 12:19:37 CET 2019

> I would really like a concept that integrates expanders seamlessly and completely invisible for users. 

Yes, me too.

Let's assume that in the application's periph_conf.h (or however we're organizing configuration in the future) there's a defined expander struct, and it has been given a speaking name like ```#define GPIO_EXT_0```. What we want to be able to do is using both ```GPIO_PIN(PORT_A, 0)``` (referencing a CPU internal pin) and ```GPIO_PIN(GPIO_EXT_0, 0)``` for specifying the expander port.

I think with the current gpio implementations that might be difficult, as the ```GPIO_PIN()``` macros turn port, pin arguments into some CPU specific single value (or multiple). But that should be easy to change so the CPU uses the pointer+pin-number. We'd have to check for code size implications, though.

> It might be difficult to initialize these data structures for all CPU and expander pins without having tables of these structures for all pins that are initialized during the initialization of the CPU/expander. Such tables would require additional memory.

Do they have to be initialized?

I'd assume an expander to have:

- some general private information (how is it connected, how configured
- some per-pin configuration (pin configured, interrupt, in/out, ...)

IMO gpio_t should only serve as reference (not contain state information), as it might be copied around into e.g., a driver's param struct. It should be left to the expander's internal implementation how to save state.

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/20190109/048fe7a4/attachment.html>

More information about the notifications mailing list