Gedare Bloom gedare at gwu.edu
Wed Jun 10 17:01:42 UTC 2015

On Mon, Jun 8, 2015 at 5:44 AM, André Marques
<andre.lousa.marques at gmail.com> wrote:
> Hello,
> I have just updated my GSOC blog [1] with a detailed post about how a
> rtems-wide GPIO API could look like, and at the same time exposing the
> current features of the Raspberry Pi GPIO API and how it can evolve to that
> level.
> I tried to make it as generic and flexible as possible, but that can be hard
> with the number of platforms where rtems can be used. Api and method naming
> were somewhat overlooked, as well as the definition of possible error codes
> since I am not sure if it would be correct to have a set of error codes for
> this API, or if it should use rtems_status_code, or other.
> Current code for the Raspberry Pi GPIO API can be looked at in [2], where I
> am currently carving out the rpi specific code.
> I tried to be as clear as possible in the blog, and now I would like to ask
> any interested party to have a look and hopefully point failure points and
> suggestions, or ask for clarifications. It would also be interesting to hear
> the community expectations towards an API such as this one.
Great write-up. Here are some comments/questions:
- The "user application must fill a gpio_pin struct for every pin it
needs" should probably be done through some set of API calls that help
filling out that struct. I'd imagine some alloc with initialization,
and dealloc, with most of the complexity in alloc/init.
- The bsp_specific pointer might be better implemented with a
zero-length array
[https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html]. Since you embed
the type of the struct, you can tell whether that array should have
any data in it or not.
- I wonder if eventually we can refactor all this to work with the
libdrvmgr. This is a long-term question but might be one worth
thinking about now. (libdrvmgr mainly focuses on providing
abstractions for device drivers that attached to bus-based i/o
protocols. You may like to take a look at its documentation.)

> [1] - https://asuolgsoc2014.wordpress.com/2015/06/08/rtems-gpio-api/
> [2] -
> https://github.com/asuol/rtems/tree/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/gpio
> Thanks for your time,
> André Marques
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

More information about the devel mailing list