Fwd: Re: [GSOC] rtems GPIO API

[Alan Cudmore]

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.
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140528/4acd6975/attachment-0001.html>