This blog post will explain the logic behind the code currently at the GPIO_API github branch, and what the next steps may be.
Currently the code only focus on the discrete I/O part, but ADC and DAC pin types can be merged from multiio. The next image is a simple diagram of the data structures that hold each pin type information.
- DIN – Discrete/digital input
- DOUT – Discrete/gigital output
- ADC – Analog to digital converter
- DAC – Digital to analog converter
- GPIO – General Purpose I/O, which here means a pin that can be configured to behave either as a DIN or a DOUT
The API defines that each type of pin (DIN, DOUT, ADC or DAC) has a structure type with all the information that may be relevant about the pin. The GPIO box on the diagram is another structure that defines the pin physical address, the pin type and an union structure that allows to use either a DIN or DOUT pin data structure. The API would enforce a pin data structure based on the pin type field.
There would be an array for each type of pin (GPIO (which may be a DIN or DOUT), ADC or DAC), where the access to an individual pin would be made through the index. The size of these arrays would be based on a BSP defined macro, for instance RTEMS_GPIO_COUNT, which if undefined would disable the GPIO part of the library. The access to these arrays would be syncronized by the library, so that multiple drivers can operate at the same time, and each pin would have a major and minor number so that a driver cannot access pins operated by other drivers.
The advantage of the array approach is direct access to a pin, as it could be easily reached through the array index, and easy management of the diferent drivers that may be accessing the GPIO pins (ensuring that no two drivers are operating the same pin at the same time).
GPIO peripheral interfaces
All the interfaces using a GPIO configuration can go on this API, like UART, I2C, SPI, JTAG or others. For instance, the API can define a function prototype like:
That each BSP with this interface could implement to enable UART. This would mean that the pins used for UART would be accessible only for the UART driver.
More design notes on the GPIO API should appear soon.
The current API code can be found at: https://github.com/asuol/rtems/tree/GPIO_API/cpukit/libgpio
With draft implementation on the Raspberry Pi BSP: https://github.com/asuol/rtems/tree/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/gpio
And a small test case that lits a LED connected to the Raspberry Pi GPIO pin 25: https://github.com/asuol/rtems/tree/GPIO_API/testsuites/samples/LIBGPIO_TEST