Fwd: Re: [GSOC] rtems GPIO API

[Gedare Bloom]

On Wed, May 28, 2014 at 11:56 AM, Alan Cudmore <alan.cudmore at gmail.com> wrote:
> Andre,
> If you have not seen this library, please check this out:
> http://wiringpi.com
>
> It looks like a good resource programming the Raspberry Pi GPIO. It may give
> you some insight and ideas about the GPIO API. The code appears to be LGPL.
Unfortunately, the LGPL is not suitable for the RTEMS code base [1].
The code may still be useful to consider for some perspective, but it
cannot be incorporated directly.

-Gedare

[1] http://gedare-csphd.blogspot.com/2013/05/software-licenses-with-rtems.html

> Alan
>
>
>
> On Sat, May 24, 2014 at 8:37 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>> 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
>> _______________________________________________
>> 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
>