[GSOC] Project update

[Alan Cudmore]

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?

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/20140617/c039e316/attachment-0001.html>