RTEMS GPIO API

[Chris Johns]

On 11/06/2015 3:01 am, Gedare Bloom wrote:
> 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.

I agree, it is a nice 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.

Being const lets you fill them out when coding as a table which I have
found easy to review plus being const has the advantage on small RAM
devices of only using ROM type storage which they usually have more of.

I think an API to fill the struct in would be confusing and so think at
this point in time we should limit what we do.

I currently have 3 Zynq variants with similar IO requirements with very
different pin selections due to easier PCB routing and I have a separate
C file with pin definitions per variant. The resulting user code is
clean and simple.

> - 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.)

I have not looked at that API so I cannot comment but I wonder if this
is outside the scope of this GSoC project.

Chris