<div dir="ltr">OK, that's good to know. But it could at least help shape the RTEMS GPIO API.<div><br></div><div>Alan</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 28, 2014 at 3:08 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="">On Wed, May 28, 2014 at 11:56 AM, Alan Cudmore <<a href="mailto:alan.cudmore@gmail.com">alan.cudmore@gmail.com</a>> wrote:<br>

> Andre,<br>
> If you have not seen this library, please check this out:<br>
> <a href="http://wiringpi.com" target="_blank">http://wiringpi.com</a><br>
><br>
> It looks like a good resource programming the Raspberry Pi GPIO. It may give<br>
> you some insight and ideas about the GPIO API. The code appears to be LGPL.<br>
</div>Unfortunately, the LGPL is not suitable for the RTEMS code base [1].<br>
The code may still be useful to consider for some perspective, but it<br>
cannot be incorporated directly.<br>
<br>
-Gedare<br>
<br>
[1] <a href="http://gedare-csphd.blogspot.com/2013/05/software-licenses-with-rtems.html" target="_blank">http://gedare-csphd.blogspot.com/2013/05/software-licenses-with-rtems.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
> Alan<br>
><br>
><br>
><br>
> On Sat, May 24, 2014 at 8:37 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>><br>
>> 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>
>> Prefer to use full names instead of abbreviations when length is not<br>
>> an issue, so here rtems_gpio_clear() is better.<br>
>><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>
>> 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>
>><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<br>
>> >> RTEMS<br>
>> >> to get an idea of the capabilities of the hardware before specifying<br>
>> >> the<br>
>> >> API.<br>
>> >><br>
>> ><br>
>> > That can be done, but for now this API would be based on the non<br>
>> > specific<br>
>> > features of the Raspberry Pi board (so that they can be reused outside<br>
>> > the<br>
>> > RPi BSP). The API can obviously be further improved. Also, the RPi is<br>
>> > the<br>
>> > only board I have access to, so any feature that isn't there I would not<br>
>> > 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<br>
>> >> 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,<br>
>> >> 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>
><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>
</div></div></blockquote></div><br></div>