[GSOC] GPIO status and I2C start

[Joel Sherrill]

On 7/7/2014 8:42 AM, Gedare Bloom wrote:
> 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.
That's a good idea for an extension of the test configuration file.
Right now the sense is "don't build this" so there would have
to be an indication to "build this only for me".

I wonder if Chris has any magic up his sleeve to support this.
He is on holiday right now, so we may have to ping him when he
pops up.

I would suggest an obvious directory like testsuites/bsptests
and names that are pretty indicative of the BSP they are specific
to like starting with the BSP name, an underscore and some
indicator of purpose.
> -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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985