RTEMS GPIO API

Tue Jun 16 16:54:13 UTC 2015

On Tue, Jun 16, 2015 at 8:14 AM, André Marques
<andre.lousa.marques at gmail.com> wrote:
> Hello ,
>
> Thank you for the responses. Sorry for the late response and lengthy mail.
>
> At this point the features mentioned in the blog post are almost done in the
> code (apart from some details). There are some differences from what is
> mentioned in the blog, but the overall idea still stands (an blog update is
> in order, as well as more documentation in the code).
>
> One major change is related with the interaction with the API. It currently
> maintains a data structure which holds the current GPIO status (which pins
> are used, what interrupt handlers they have associated, ...), so an
> application can either fill a different structure to configure a pin, which
> is passed to the API through an API call, or configure the pin directly
> through API calls.
>
> The struct approach can be used either to define a new pin to be requested,
> or to update its configuration, all done by updating/changing the struct and
> doing the same function call to the API. Since the structs can be defined on
> a separate file, the application code can be the same across different
> platforms, as the only diference is the configuration file that is
> used/called. The platform specific configuration (which pin in y platform
> corresponds to the warning led?) for an application would then be reduced to
> file management.
>
> The API call that does the processing of these structs parses them and does
> the necessary API calls to setup/update the GPIO hardware as needed.
>
> By having both a struct based interface and direct API call options an user
> can choose what is best for their need. The direct API calls can be
> specially useful for an interactive usage, through a shell program.
>
> The current implementation for the above can be seen in [1], [2] and [3].
> Note that the gpio.c and gpio.h can be anywhere else at this point, as they
> do not have any rpi code anymore (another question is where they could go
> then?).
>
I think the first place to migrate shared code is libbsp/shared. After
that, we can consider whether the code is generic enough to put in
cpukit, which is where other driver frameworks (i2c, libdrvmgr) have
landed recently.

> A pending issue is related with pin definitions. It would be useful if after
> the pin request to the API, the application could have a gpio_pin_id which
> would be used as a reference to an application pin.
>
> Small example with direct API call:
>
> gpio_pin_id warning_led;
>
> gpio_request_pin(RPI_GPIO_23, &warning_led, DIGITAL_OUT, ..);
>
> gpio_set(warning_led);
>
> The RPI_GPIO_23 would be the platform pin number (the API calculates the
> bank and pin number from this), but after the request the application uses
> the gpio_pin_id to refer to it. The gpio_pin_id would be a simple struct
> filled by the API with the calculated bank and pin numbers, which no one
> else is supposed (or have the need to) to modify/use this struct other than
> to pass it to the API to refer to a pin. This would also avoid the constant
> bank/pin numbers calculation and pin number boundary validation that is made
> currenty in every API call.
>
That makes sense. You could define an opaque type to store the
identifier. However, if it is a struct, passing it by value could be
an expensive operation, so care should be taken there. (If you can fit
it in 32-bits, you can union the gpio_pin_id with a uint32_t)

> A final note would be the need for multiple pin operations. The rpi and most
> platforms (I suppose) allow several pins to be defined on a single call, by
> writting a more complete bitmask to the registers. This could be a challenge
> with the struct approach (maybe by having pin arrays, instead of a single
> pin in the struct, if they all share the same configuration). As for direct
> pin calls maybe through variadic functions.
I just got done writing about zero-length arrays for Yang Qiao
[https://github.com/yangqiao/rtems/commit/38c26a49126e5cff92ae389dba252cb180362c90#commitcomment-11707035],
but perhaps you could use something similar albeit simpler in this
case too. You define the pin as a zero-length array (it should always
be at least 1 though), and then include the number of pins in the
struct.

>
> [1] -
> https://github.com/asuol/rtems/tree/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/gpio
> [2] -
> https://github.com/asuol/rtems/blob/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/include/gpio.h
> [3] -
> https://github.com/asuol/rtems/blob/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/include/rpi-gpio.h
>
> --André Marques.
>
>
> On 11-06-2015 15:13, Gedare Bloom wrote:
>>
>> 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
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel