<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello,<br>
<br>
On 06/18/14 02:21, Alan Cudmore wrote:<br>
</div>
<blockquote
cite="mid:CAJrjN73d5nepiO3=CcCJF4zewWTyE1aoaZRgj36u19a4Oj_c+Q@mail.gmail.com"
type="cite">
<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>
</blockquote>
The set function is for digital output pins, which sets a pin value
to 1. For the interface functions each pin would need to be setup
with the corresponding funtion (as the JTAG setup does), and not a
specific value.<br>
<br>
This setup may be done in two ways:<br>
<br>
1 - Using the existing rtems_gpio_setup_pin, which would receive the
pin number and its function, so if the interface needs to setup 5
pins it would call this function 5 times, one for each pin;<br>
<br>
2 - A interface_setup function which would receive a struct with the
pins and functions. Each BSP could define a structure for each
interface it suports, so the user would still get a one call setup.
In practice for each pin defined on the struct this function would
call rtems_gpio_setup_pin, so this would be a wrapper function.<br>
<br>
To me the second options seems the best, as only one function call
could setup any number of BSP specific GPIO configurations.<br>
<br>
<blockquote
cite="mid:CAJrjN73d5nepiO3=CcCJF4zewWTyE1aoaZRgj36u19a4Oj_c+Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>