Gedare Bloom gedare at gwu.edu
Thu Jun 11 14:13:20 UTC 2015

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

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

More information about the devel mailing list