<div dir="ltr"><div>A question about the rtems_gpio_setup_UART functions; </div><div>Could it be implemented with rtems_gpio_set_mb(RPI_PORT, RPI_GPIO_UART_MASK) , or would it do additional setup?</div><div><br></div><div>
If BSP specific mask defines could be used, it would be easier to implement, and it would not matter which GPIO peripherals each BSP supported. </div><div><br></div><div>Alan</div><div><br><div><br></div><div><br><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 10:52 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">
<div bgcolor="#FFFFFF" text="#000000"><div class="">
<div>On 06/17/14 15:39, Alan Cudmore wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Andre,
<div>I checked out the your GPIO_API branch and tried it out. I
had do do a couple of things to get it to build:</div>
<div>1. On the configure, I had to use --disable-multiprocessing
( I think that is the option, I'm going from memory ). I
wonder if this is now required for non SMP systems?</div>
</div>
</blockquote>
<br></div>
I don't use that option.<div class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>2. I had to add the libgpio.h header install in the cpukit/<a href="http://preinstall.am" target="_blank">preinstall.am</a>
file</div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
I forgot to push it. It is on github now.<div class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>I like the idea of setting up individual peripherals such
as the UART, JTAG, or I2C with a single call. But, are all
CPUs with GPIO configured this way? If this configuration is
unique the the Pi/Broadcom CPU then it may not be applicable
as a generic GPIO API. </div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
The point was if a certain CPU does not support one of the
interfaces it would not implement that function, and return some
rtems status code to signal that. I am also not sure if the right
place for it is in the GPIO API, but I do like the idea of the API
being able to track which pins are being used. Maybe a better
approach would be to have the peripheral functions somewhere else
and they would call a function on the GPIO API to request pins, so
it could still track them.<div class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>I wonder if we should just make the GPIO library specific
to the Raspberry Pi BSP for now, then try to take on the
project of creating a generic GPIO API for all RTEMS BSPs
later. I feel that we need more community input to make a
generic GPIO API that will not change. </div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
Sure.<div class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Thanks,</div>
<div>Alan</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Jun 16, 2014 at 6:39 PM, 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 all,<br>
<br>
I have been very busy with my undergraduate thesis, but I
expect to have more free time by friday. In the meantime, i
have added some code to github which implement some of the
features I have mentioned on the last blog post.<br>
<br>
First I added a function on the GPIO API that will alow a
BSP that support JTAG interfacing through GPIO to setup and
use it. The advantage of doing this through the API is that
it tracks which pins are being used, preventing the use of
pins that were already setup for something else. It also
makes it very easy to the user to setup a JTAG interface (a
test case was also created to demonstrate that). This JTAG
setup function can also be seen as a proof of concept of the
usefulness (or not) of having a function for these sort of
interfaces that may be available through GPIO.<br>
<br>
The JTAG libgpio function is based on alan's JTAG gpio setup
program, along with some changes both to that code and to
the pin setup function on the API, that can now setup pins
to functions other than just input and output (up to 6
alternate "generic" functions, which would be BSP specific).<br>
<br>
libgpio api -> <a href="https://github.com/asuol/rtems/blob/GPIO_API/cpukit/libgpio/libgpio.h" target="_blank">https://github.com/asuol/rtems/blob/GPIO_API/cpukit/libgpio/libgpio.h</a><br>
libgpio raspberry implementation -> <a href="https://github.com/asuol/rtems/blob/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/gpio/libgpio.c" target="_blank">https://github.com/asuol/rtems/blob/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/gpio/libgpio.c</a><br>
<br>
libgpio jtag function test case -> <a href="https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_JTAG/init.c" target="_blank">https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_JTAG/init.c</a><br>
alan's jtag program -> <a href="https://github.com/alanc98/hello-rtems-jtag/blob/master/test.c" target="_blank">https://github.com/alanc98/hello-rtems-jtag/blob/master/test.c</a><br>
<br>
Any feedback is well apreciated!<br>
<br>
Thanks for your time,<br>
André Marques.<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div>
</blockquote></div><br></div></div></div></div>