On Mon, Jul 7, 2014 at 9:37 AM, Alan Cudmore <alan.cudm...@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.marq...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel