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 ?
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.
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. 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
