RTEMS GPIO API

[Gedare Bloom]

On Wed, Jun 10, 2015 at 7:09 PM, Chris Johns <chrisj at rtems.org> wrote:
> 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.
>
OK that is fair. On the other hand, anything we can do to make the
const initializer easier would be good. I especially was concerned by
#ifdef's inside the initializer.

> 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.
>
That makes much more sense, where the struct definition will be pulled
in through the build system logic to choose the correct file to
compile.

>> - 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.
>
Definitely outside the scope.

> Chris