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 <ged...@rtems.org> wrote: > On Wed, May 28, 2014 at 11:56 AM, Alan Cudmore <alan.cudm...@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 <ged...@rtems.org> wrote: > >> > >> On Sat, May 24, 2014 at 12:08 PM, Andre Marques > >> <andre.lousa.marq...@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@rtems.org > >> >>> http://www.rtems.org/mailman/listinfo/rtems-devel > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> rtems-devel mailing list > >> >> rtems-devel@rtems.org > >> >> http://www.rtems.org/mailman/listinfo/rtems-devel > >> > > >> > > >> > _______________________________________________ > >> > rtems-devel mailing list > >> > rtems-devel@rtems.org > >> > http://www.rtems.org/mailman/listinfo/rtems-devel > >> _______________________________________________ > >> rtems-devel mailing list > >> rtems-devel@rtems.org > >> http://www.rtems.org/mailman/listinfo/rtems-devel > > > > > > > > _______________________________________________ > > rtems-devel mailing list > > rtems-devel@rtems.org > > http://www.rtems.org/mailman/listinfo/rtems-devel > > >
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
