On Wed, May 28, 2014 at 11:56 AM, Alan Cudmore <[email protected]> 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 <[email protected]> wrote: >> >> On Sat, May 24, 2014 at 12:08 PM, Andre Marques >> <[email protected]> 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 >> >>> [email protected] >> >>> http://www.rtems.org/mailman/listinfo/rtems-devel >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> rtems-devel mailing list >> >> [email protected] >> >> http://www.rtems.org/mailman/listinfo/rtems-devel >> > >> > >> > _______________________________________________ >> > rtems-devel mailing list >> > [email protected] >> > http://www.rtems.org/mailman/listinfo/rtems-devel >> _______________________________________________ >> rtems-devel mailing list >> [email protected] >> http://www.rtems.org/mailman/listinfo/rtems-devel > > > > _______________________________________________ > rtems-devel mailing list > [email protected] > http://www.rtems.org/mailman/listinfo/rtems-devel > _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
