[GSOC] Project update

[Alan Cudmore]

I agree on (2). Having a generic function to setup an interface seems best.

I think that having a collection of specific interface setup functions such
as rtems_gpio_setup_UART might only be useful for a couple of BSPs.






On Wed, Jun 18, 2014 at 7:00 AM, Andre Marques <
andre.lousa.marques at gmail.com> wrote:

>  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> 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
>> 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> 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/20140619/30c36a5b/attachment-0002.html>