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