This blog post will add to the project documentation on the RTEMS wiki by presenting actual test cases on the provided work. The test cases and device drivers used to test the work can be found on this github repository.
During the project I have used a microchip 23k256 SRAM memory device to test the SPI bus. The device driver I have created for it can be found here and the test case here. It is a minimal driver meant to just write a message to a fixed memory offset on the device and then to read it back.
Before using the SPI bus it must be enabled on the raspberrypi BSP configure.ac script (BSP_ENABLE_SPI) and its I/O mode selected (SPI_IO_MODE) to either polled or interrupt-driven access.
The device must be connected to the pi like shown above, and care should be taken with the cable lengths of the MOSI, MISO and CLK lines, which should not be much greater than 20cm, above which errors can start to occur on the sent and received data through the bus.
The test case opens the device file associated with the device (which must be registered as mentioned on the wiki) and read and writes using the read() and write() calls using the device file file descriptor.
To test the I2C bus I have used a microchip mcp23008 GPIO port expander. It uses the I2C bus to provide 8 extra GPIO pins and the device driver can be found here. The driver for this device is ioctl based, and is able to use all 8 GPIOs using polled-driven access. Future work for this driver will include support for interrupts on these GPIO pins and support for the microchip mcp23017 which is the same device but has twice the amount of GPIOS. These devices driver can be useful to have as they are commonly used with the raspberry pi to gain more GPIO pins.
Before using the I2C bus it must be enabled on the raspberrypi BSP configure.ac script (BSP_ENABLE_I2C) and its I/O mode selected (I2C_IO_MODE) to either polled or interrupt-driven access.
As with the SPI bus, the SDA and SCL cables should not be greater than 20cm in length.
The test case opens the device file associated with the device (refer to the wiki) and then performs ioctl requests using the ioctl() call to operate the device. In operates GPIO pin 4 as an output pin (connected to a LED) and GPIO pin 2 as an input pin (connected to a button). When the button is pressed the LED switches on.
The GPIO pins can be used to perform digital I/O. Digital input pins may be polled or interrupt-driven. To use GPIO 2 and 3 the I2C bus must be disabled on the configure.ac script (at the root of the raspberrypi BSP), and the same applies to the SPI bus before using GPIO 7, 8, 9, 10 or 11.
Both the following test cases start by initializing the GPIO API, setting GPIO 2 and GPIO 17 as digital inputs (using the internal pull up resistor) and GPIO 3 and GPIO 7 as digital outputs.
GPIOs 3 and 7 are sent a logical 0 (so the LEDs start turned off), and then the Raspberry Pi polls forever the GPIO 2 and GPIO 17 pin for button presses. Because the internal pull up resistor is enabled, when a button in not being pressed the digital input pin values, or level, is 1, and when a button is pressed the pin level is 0. The test case reads the GPIO 2 pin level, and when the level is 0 it sets GPIO 3 , so the LED lits up, otherwhise GPIO 3 pin is cleared (and the LED is off). The same aplies to GPIO 17 and GPIO 7.
The test case calculates how many clock time exist per second, which will be used to debounce the swritches through sofwtare. GPIOs 3 and 7 are sent a logical 0, and the GPIO API debounce function is attached and set to require a wait between interrupts of 50 miliseconds. Both digital input pins (GPIO 2 and 17) are configured to generate a interrupt both on rising and on falling edge, so every time a switch is pressed or released a interrupt is generated. This interrupt will call the functions edge_test_1 and edge_test_2 respectively which will read the input pin values and depending on the button condition will turn on the corresponding LED. The digital output GPIO 2 is also configured to generate an interrupt on high level. This means that when the pin is high (meaning that the LED is on), the function level_test is called, which prints “LED ON” on the console.