[GSOC] Project update

[Andre Marques]

Hello,

On 06/18/14 02:21, Alan Cudmore wrote:
> A question about the rtems_gpio_setup_UART functions;
> Could it be implemented with rtems_gpio_set_mb(RPI_PORT, 
> RPI_GPIO_UART_MASK) , or would it do additional setup?
>
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.

This setup may be done in two ways:

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;

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.

To me the second options seems the best, as only one function call could 
setup any number of BSP specific GPIO configurations.

> 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.
>
> Alan
>
>
>
>
>
> On Tue, Jun 17, 2014 at 10:52 AM, Andre Marques 
> <andre.lousa.marques at gmail.com <mailto:andre.lousa.marques at gmail.com>> 
> wrote:
>
>     On 06/17/14 15:39, Alan Cudmore wrote:
>>     Hi Andre,
>>     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:
>>     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?
>
>     I don't use that option.
>
>
>>     2. I had to add the libgpio.h header install in the
>>     cpukit/preinstall.am <http://preinstall.am> file
>>
>
>     I forgot to push it. It is on github now.
>
>
>>     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.
>>
>
>     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.
>
>
>>     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.
>>
>
>     Sure.
>
>
>>     Thanks,
>>     Alan
>>
>>
>>     On Mon, Jun 16, 2014 at 6:39 PM, Andre Marques
>>     <andre.lousa.marques at gmail.com
>>     <mailto:andre.lousa.marques at gmail.com>> wrote:
>>
>>         Hello all,
>>
>>         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.
>>
>>         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.
>>
>>         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).
>>
>>         libgpio api ->
>>         https://github.com/asuol/rtems/blob/GPIO_API/cpukit/libgpio/libgpio.h
>>         libgpio raspberry implementation ->
>>         https://github.com/asuol/rtems/blob/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/gpio/libgpio.c
>>
>>         libgpio jtag function test case ->
>>         https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_JTAG/init.c
>>         alan's jtag program ->
>>         https://github.com/alanc98/hello-rtems-jtag/blob/master/test.c
>>
>>         Any feedback is well apreciated!
>>
>>         Thanks for your time,
>>         André Marques.
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140618/e670781a/attachment-0002.html>