[GSOC] GPIO status and I2C start

[Gedare Bloom]

On Mon, Jul 7, 2014 at 9:37 AM, Alan Cudmore <alan.cudmore at gmail.com> wrote:
> Hi André,
> I updated my Pi setup to add the second LED and switch, and your example
> works for me. I did notice that when I power off the Rapberry Pi, then power
> it back on, the second LED will remain lit and cause interrupts in the RTEMS
> program. If I leave the Pi powered off for a little while, it works as
> intended. I don't think this is an RTEMS problem. The good news is that the
> RTEMS app continues to run and handle the interrupts, so it is stable.
>
> I will experiment with different button and LED combinations in the next few
> days.
>
> When you have an I2C driver to try, I have a number of I2C devices to
> interface. I will have to find an SPI device to try out. Something like
> this:
> https://www.adafruit.com/product/1897
> Or
> https://www.adafruit.com/product/1900
>
> A question about the examples ( maybe not for Andre ):
> Can we keep Board/BSP specific tests in the testsuites/samples directory?
>
We do not currently have a good location for BSP-specific tests in the
RTEMS tree. However, we now have a way to specify in a BSP which tests
it does not work for (test config file), so we could use that
filtering mechanism to enforce BSP-specific tests. The question then
is where to put those tests/examples so it is obvious to a user
whether the code should work for them or not.

-Gedare

> Alan
>
>
> On Sat, Jul 5, 2014 at 6:58 PM, Andre Marques
> <andre.lousa.marques at gmail.com> wrote:
>>
>> Hello,
>>
>> The Raspberry Pi GPIO interrupts are already working, and a test case is
>> available to test that [1]. A function is also provided to debounce a switch
>> if needed. The test case requires two switches and two LEDS using the same
>> setup described at [2] by only changing the pin numbers.
>>
>> The test works by setting interrupts on both edges of the switches, which
>> handlers will turn on or off the corresponding LED. One of the LEDs also has
>> a level interrupt which prints a message on the screen when the LED is on
>> (high level).
>>
>> While I wait for some feedback on that, I will be looking at the next
>> step: the I2C interface. To test both the I2C and the SPI interfaces I have
>> here a simple display [3]. The idea is to create a low level driver for I2C
>> to provide the needed directives for the libi2c API, so the driver for the
>> display will actually use the libi2c API. Any thoughts here are welcome too!
>>
>> Thanks,
>> André Marques.
>>
>> [1] -
>> https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_TEST_IQR/init.c
>> [2] - http://asuolgsoc2014.wordpress.com/2014/06/22/testing-the-gpio-api/
>> [3] - http://www.newhavendisplay.com/nhd0216k3zflgbwv3-p-5738.html
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel