<div dir="ltr">This looks good to me.. But we welcome feedback from those with more experience on different processors/BSPs. <div><br></div><div>Andre, I updated to your latest repository, rebuilt, and ran the GPIO test with an LED and button. it worked just as described. I'm going to try this with a couple of extra buttons and LEDs on my setup.  Great job!</div>
<div><br></div><div>Alan</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 22, 2014 at 11:22 AM, Andre Marques <span dir="ltr"><<a href="mailto:andre.lousa.marques@gmail.com" target="_blank">andre.lousa.marques@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
The GPIO API has been updated with doxygen documentation and code comments, along with a blog post that explains the current API work flow [1], and another blog post explaining how the API can be tested using the Raspberry Pi [2], both containing links to the actual code. Currently this API is only implemented for the RPi BSP, where it succeds at performing digital I/O.<br>

<br>
Changes to the API itself are:<br>
<br>
- It no longer stores memory addresses, as this is BSP specific;<br>
<br>
- Removed the interface setup functions (for UART, SPI, JTAG, ..) and replaced with a function that setups any GPIO pin configuration by using a struct. A BSP may define a number of specific GPIO interfaces/configuration on a header file, to be used by an application.<br>

<br>
The current way of using the API is to include the header file, initialize the API and call its directives to operate the GPIO pins, which can be used directly by an application or through a driver.<br>
<br>
Because the GPIO API itself only provides digital I/O directives (as any other type of I/O, such as SPI, is BSP specific), doing it directly using the API directives or using a digital I/O driver is almost the same, I am not sure if the said driver is useful at this point.<br>

<br>
For the API to become generic the implementation must go to cpukit too, and each BSP should provide low level functions to operate their specific hardware. Then a generic digital I/O driver can be created that should work with any BSP, as the high level functionality would be in cpukit. Comments to this idea are welcome.<br>

<br>
[1] - <a href="http://asuolgsoc2014.wordpress.com/2014/06/22/the-current-gpio-api/" target="_blank">http://asuolgsoc2014.<u></u>wordpress.com/2014/06/22/the-<u></u>current-gpio-api/</a><br>
[2] - <a href="http://asuolgsoc2014.wordpress.com/2014/06/22/testing-the-gpio-api/" target="_blank">http://asuolgsoc2014.<u></u>wordpress.com/2014/06/22/<u></u>testing-the-gpio-api/</a><br>
<br>
--André Marques.<br>
</blockquote></div><br></div>