<div dir="ltr">Andre,<div>If you have not seen this library, please check this out:</div><div><a href="http://wiringpi.com">http://wiringpi.com</a></div><div><br></div><div>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. </div>
<div>Alan</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 24, 2014 at 8:37 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, May 24, 2014 at 12:08 PM, Andre Marques<br>
<<a href="mailto:andre.lousa.marques@gmail.com">andre.lousa.marques@gmail.com</a>> wrote:<br>
> On 05/23/14 17:57, Chris Nott wrote:<br>
>><br>
>><br>
>> My two cents:<br>
>><br>
>> On 22/05/2014 3:30 PM, Andre Marques wrote:<br>
>>><br>
>>> Hello,<br>
>>><br>
>>> I will start my GSOC project with a GPIO driver for the RPi BSP, and<br>
>>> part of the GPIO driver code will not be specific to the RPi but to<br>
>>> any board with a GPIO interface. With code reuse in mind and since I<br>
>>> did not found any "generic" API for the GPIO interface in the RTEMS<br>
>>> code base, I intend to propose here an initial *rough* draft of what<br>
>>> this API may look like.<br>
>>><br>
>>> To initialize the API:<br>
>>><br>
>>> rtems_gpio_initialize (struct gpio_config)<br>
>>><br>
>>> which would initialize the API with a specific GPIO peripheral<br>
>>> configuration: number of gpio pins, gpio register addresses, ...<br>
>>><br>
>>> To set a gpio pin as input or output (the direction would be a macro):<br>
>>><br>
>>> rtems_gpio_direction (int gpio, int direction)<br>
>>><br>
>>> To set a gpio pull resistor (either pull up/down or no pull resistor):<br>
>>><br>
>>> rtems_gpio_set_Pull (int gpio, int pull)<br>
>><br>
>> You probably want to add push-pull/open drain as a pin option.<br>
>><br>
>> Some targets would have drive strength or other options as well, that<br>
>> may be useful to add in the GPIO API ?<br>
>><br>
><br>
> Possibly.<br>
><br>
><br>
>>><br>
>>> Some GPIO I/O:<br>
>>><br>
>>> rtems_gpio_set(int gpio)<br>
>>> rtems_gpio_clr (int gpio)<br>
>>> rtems_gpio_read_value (int gpio)<br>
>><br>
>> Is it your intention to abstract GPIO as separate single-bit ports? It<br>
>> might be better to keep the GPIO in natural groupings, otherwise doing<br>
>> I/O through this API you would lose the ability to toggle multiple pins<br>
>> in a GPIO group at once, which is sometimes important.<br>
><br>
><br>
> In that case it could be done as:<br>
><br>
> rtems_gpio_set(int port, int gpio)<br>
> rtems_gpio_clr (int port, int gpio)<br>
</div></div>Prefer to use full names instead of abbreviations when length is not<br>
an issue, so here rtems_gpio_clear() is better.<br>
<div class=""><br>
> rtems_gpio_read_value (int port, int gpio)<br>
><br>
> Where port would be a group of gpio pins, and a gpio number of < 0 would<br>
> mean all the gpio pins in a group?<br>
><br>
</div>Would it make sense to define a struct to encapsulate a GPIO context<br>
(as a set of pins, perhaps some other metadata about the pins like<br>
strength, interrupts) that gets passed in to these functions?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>><br>
>>><br>
>>> And interrupt management:<br>
>>><br>
>>> rtems_int_enable (int gpio, rtems_interrupt_level int)<br>
>>> rtems_int_disable (int gpio)<br>
>>> rtems_int_clear (int gpio)<br>
>><br>
>> Interrupts may be a little tricky to abstract in an API. The interrupt<br>
>> capability for GPIO pins varies a lot.<br>
>><br>
>> Also you would need to be able to be able to configure what causes an<br>
>> interrupt, ie. edge capture options etc.<br>
>><br>
>> I think what you are proposing is a good idea, but I think it might be<br>
>> worth taking a quick survey of the existing platforms supported in RTEMS<br>
>> to get an idea of the capabilities of the hardware before specifying the<br>
>> API.<br>
>><br>
><br>
> That can be done, but for now this API would be based on the non specific<br>
> features of the Raspberry Pi board (so that they can be reused outside the<br>
> RPi BSP). The API can obviously be further improved. Also, the RPi is the<br>
> only board I have access to, so any feature that isn't there I would not be<br>
> able to test, or may not even fit the generic purpose of this API.<br>
><br>
><br>
>> Also, this is only my opinion. I am not really sure what the intention<br>
>> is with regards to driver API in RTEMS. I expect there is probably going<br>
>> to be a choice between generic/flexible and performance. For example -<br>
>> do you support multiple _types_ of GPIO controller? Ie. some kind of<br>
>> GPIO device driver, which will require call-through-pointer tables and<br>
>> is going to be a little slower. I am looking at implementing a USB<br>
>> device API which has the same choice, and so far I think it is safe for<br>
>> USB to only provide one kind of USB device core "driver" per target, and<br>
>> thus avoid a layer of indirection.<br>
>><br>
>>><br>
>>> Would appreciate some feedback on this.<br>
>>><br>
>>> --Andre Marques.<br>
>>> _______________________________________________<br>
>>> rtems-devel mailing list<br>
>>> <a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
>>> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> rtems-devel mailing list<br>
>> <a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
>> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
><br>
><br>
> _______________________________________________<br>
> rtems-devel mailing list<br>
> <a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
_______________________________________________<br>
rtems-devel mailing list<br>
<a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
</div></div></blockquote></div><br></div>