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