Fwd: Re: [GSOC] rtems GPIO API

Wed May 28 19:24:30 UTC 2014

OK, that's good to know. But it could at least help shape the RTEMS GPIO
API.

Alan

On Wed, May 28, 2014 at 3:08 PM, Gedare Bloom <gedare at rtems.org> wrote:

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