On Mon, Jul 7, 2014 at 9:42 AM, Gedare Bloom <ged...@rtems.org> wrote:
> 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 > > We probably don't want to keep the examples in the RTEMS tree, since they are so specific to the Raspberry Pi and the peripherals that we connect to it. I think it will be good enough for the project to end up with a github repository that has the code to exercise the various I/O interfaces. Alan > > 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
