Fwd: Re: [GSOC] rtems GPIO API

[Andre Marques]

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

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