RTEMS GPIO API design (start)

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.

GPIO API data structs

Where:

  • 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:

int rtems_gpio_set_UART(void)

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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s