Fwd: Re: [GSOC] rtems GPIO API

[Gedare Bloom]

On Sat, May 24, 2014 at 12:08 PM, Andre Marques
<andre.lousa.marques at gmail.com> wrote:
> On 05/23/14 17:57, Chris Nott wrote:
>>
>>
>> My two cents:
>>
>> On 22/05/2014 3:30 PM, Andre Marques wrote:
>>>
>>> Hello,
>>>
>>> I will start my GSOC project with a GPIO driver for the RPi BSP, and
>>> part of the GPIO driver code will not be specific to the RPi but to
>>> any board with a GPIO interface. With code reuse in mind and since I
>>> did not found any "generic" API for the GPIO interface in the RTEMS
>>> code base, I intend to propose here an initial *rough* draft of what
>>> this API may look like.
>>>
>>> To initialize the API:
>>>
>>> rtems_gpio_initialize (struct gpio_config)
>>>
>>> which would initialize the API with a specific GPIO peripheral
>>> configuration: number of gpio pins, gpio register addresses, ...
>>>
>>> To set a gpio pin as input or output (the direction would be a macro):
>>>
>>> rtems_gpio_direction (int gpio, int direction)
>>>
>>> To set a gpio pull resistor (either pull up/down or no pull resistor):
>>>
>>> rtems_gpio_set_Pull (int gpio, int pull)
>>
>> You probably want to add push-pull/open drain as a pin option.
>>
>> Some targets would have drive strength or other options as well, that
>> may be useful to add in the GPIO API ?
>>
>
> Possibly.
>
>
>>>
>>> Some GPIO I/O:
>>>
>>> rtems_gpio_set(int gpio)
>>> rtems_gpio_clr (int gpio)
>>> rtems_gpio_read_value (int gpio)
>>
>> Is it your intention to abstract GPIO as separate single-bit ports? It
>> might be better to keep the GPIO in natural groupings, otherwise doing
>> I/O through this API you would lose the ability to toggle multiple pins
>> in a GPIO group at once, which is sometimes important.
>
>
> In that case it could be done as:
>
> rtems_gpio_set(int port, int gpio)
> rtems_gpio_clr (int port, int gpio)
Prefer to use full names instead of abbreviations when length is not
an issue, so here rtems_gpio_clear() is better.

> rtems_gpio_read_value (int port, int gpio)
>
> Where port would be a group of gpio pins, and a gpio number of < 0 would
> mean all the gpio pins in a group?
>
Would it make sense to define a struct to encapsulate a GPIO context
(as a set of pins, perhaps some other metadata about the pins like
strength, interrupts) that gets passed in to these functions?

>
>>
>>>
>>> And interrupt management:
>>>
>>> rtems_int_enable (int gpio, rtems_interrupt_level int)
>>> rtems_int_disable (int gpio)
>>> rtems_int_clear (int gpio)
>>
>> Interrupts may be a little tricky to abstract in an API. The interrupt
>> capability for GPIO pins varies a lot.
>>
>> Also you would need to be able to be able to configure what causes an
>> interrupt, ie. edge capture options etc.
>>
>> I think what you are proposing is a good idea, but I think it might be
>> worth taking a quick survey of the existing platforms supported in RTEMS
>> to get an idea of the capabilities of the hardware before specifying the
>> API.
>>
>
> That can be done, but for now this API would be based on the non specific
> features of the Raspberry Pi board (so that they can be reused outside the
> RPi BSP). The API can obviously be further improved. Also, the RPi is the
> only board I have access to, so any feature that isn't there I would not be
> able to test, or may not even fit the generic purpose of this API.
>
>
>> Also, this is only my opinion. I am not really sure what the intention
>> is with regards to driver API in RTEMS. I expect there is probably going
>> to be a choice between generic/flexible and performance. For example -
>> do you support multiple _types_ of GPIO controller? Ie. some kind of
>> GPIO device driver, which will require call-through-pointer tables and
>> is going to be a little slower. I am looking at implementing a USB
>> device API which has the same choice, and so far I think it is safe for
>> USB to only provide one kind of USB device core "driver" per target, and
>> thus avoid a layer of indirection.
>>
>>>
>>> Would appreciate some feedback on this.
>>>
>>> --Andre Marques.
>>> _______________________________________________
>>> rtems-devel mailing list
>>> rtems-devel at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>>
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel