How to write a low resolution and slow interface display panel driver

Revision as of 17:15, 22 July 2024 by Registered User (→‎Performance considerations)
Applicable for STM32MP13x lines, STM32MP15x lines, STM32MP25x lines


1. Article purpose[edit source]

Low resolution display panels can be connected to STM32 boards using low speed interfaces like I2C, SPI or FMC. Some famous of this category of display panels are:

  • the SSD1306 monochrome OLED panels,
  • the GC9A01 round 16-bit color panels,
  • the 1602 monochrome 2 text lines panels.


The purpose of this article is to:

  • briefly describe the main characteristics of the low resolution panels,
  • present some hardware attention points to consider before writing a panel software driver,
  • introduce the Linux® kernel frameworks used to control these display panels,
  • describe how to write, test and debug your own display panel driver,
  • demonstrate simple use cases based on these display panels,
  • suggest alternatives for driving these display panels.
Info white.png Information
Before you continue reading this article, you might be interested in the following articles: DRM KMS overview, How to write a display panel or bridge driver, I2C overview, SPI overview.

2. Main characteristics of low resolution slow interface panels[edit source]

The main characteristics of low resolution slow interface panels are the followings:

  • the possible bus interfaces are I2C (serial), SPI (serial) and FMC (parallel).
  • the display resolution goes from few text lines to nearly 320x240 QVGA pixels. For instance: 128x64 pixels for many SSD1306 panels, 240x240 for GC9A01 round panels.
  • the interface speed goes from few kHz to nearly 10MHz. For instance: up to 400KHz in I2C, 10MHz in SPI and 3.3Mhz in parallel for SSD1306 panels.
  • the color format goes from monochrome to RGB24. For instance, SSD1306 panels are monochrome, GC9A01 panels are up to 262K colors but are often used in RGB16 as a compromise between simplicity and performance.
  • these panels are RAM-based: pixels are stored in an embedded memory inside the panel IC driver. The main reason is because the display update process from the host is slow and not continuous. Nevertheless, RAM-based panels sometimes offer useful features like:
    • partial updates: possibility to update only a rectangle part on the screen, that is more efficient than a full screen update.
    • partial refresh: possibility to update only few lines on the screen to save power as only the related RAM is powered.
    • low power mode for the system: the panel continues to display something while the host is in a low power state (sleep, off...).
    • low color mode: the panel uses less colors to save RAM and power.
    • horizontal & vertical scrollings: possibility to scroll the display content and to update only the new lines.
    • 90/180/270° rotation, horizontal & vertical mirrors: possibility to adjust the display panel content to the mechanical orientation or the user usage.

3. Hardware considerations[edit source]

4. Linux Kernel[edit source]

4.1. Architecture[edit source]

Alternate text

4.2. Software frameworks and drivers[edit source]

4.3. Tests and Debug[edit source]

4.4. Performance considerations[edit source]

Most of the time, the overall update performance of these display panels is not an issue because the resolution is low and related use cases do not require high refresh rates.

Nevertheless, sometimes the update performance is not at the expected level for the use case due to:

  • color conversion: the color format exposed at the userland API is sometimes different from the built-in color format of the panel, requiring a software processing for performing the color conversion. This is the case for the SSD1306 monochrome panel: the userland color is XRGB8888 (32-bit), frame buffers are converted in software to monochrome inside the SSD1306 Linux kernel driver[1].
  • color dithering: for a better color quality, sometimes the color conversion is performed with dithering[2] algorithmes in software.
  • RAM organized in pages: some panels have a specific RAM organization requiring a software process to re-arrange data before sending them to the panel. This is the case for the SSD1306 monochrome panel: before transferring the data to the display, they are re-organized inside the SSD1306 Linux kernel driver[1].
  • full versus partial update: some software drivers manage the partial updates thanks to the DRM/KMS userland API but this is not the case of all panel drivers. Moreover, the userland application does not always use this partial update API. Note that the SSD1306 monochrome panel software driver[1] use the DRM/KMS partial update API.
  • Low frequency on bus interface due to the device tree configuration: The bus interface may be shared between several peripherals and it may slow down panel updates if there are performed simultaneously with others peripherals on the same bus.
Info white.png Information
If performance is an issue for the use case, please read the chapter [[]].

4.5. Quality considerations[edit source]

Here below some considerations for improving the quality of the use case.

  • color quality: the color conversion from XRGB32_8888 to RGB16_565 or to monochrome may impact the use case color quality. Appropriate dithering[2] methods need to be put in place for fixing color conversion artefacts.
  • display tearing<ref name=tearing>Screen tearing article on Wikipedia: https://en.wikipedia.org/wiki/Screen_tearing/<ref>: the screen tearing appears when the host and the peripheral are not well synchronized to properly manage screen updates. There are many causes of screen tearing. Some panels do not have tearing GPIO to start


Info white.png Information
In the chapter [[]], the use case example demonstrates the usage of GStreamer dithering for improving the quality of a video playback on a monochrome display.

5. Use case examples[edit source]

5.1. System monitoring[edit source]

5.2. Video playbacks[edit source]

5.3. Graphics with GPU[edit source]

6. Backlight[edit source]

7. U-boot[edit source]

8. Procedure 1[edit source]

Explain the outcome of this procedure. In the table below, list each high-level step which will be documented in detail below the table.

Step What to do Notes
1
2
3

8.1. Step-by-step instructions[edit source]

  1. Do step 1
  2. Do step 2
    1. Do substep 2.1
  3. Do step 3

9. Procedure 2[edit source]

Explain the outcome of this procedure. In the table below, list each high-level step which will be documented in detail below the table.

Step What to do Notes
1
2
3

9.1. Step-by-step instructions[edit source]

  1. Do step 1
  2. Do step 2
    1. Do substep 2.1
  3. Do step 3

10. Related pages[edit source]

  • Link to related page 1
  • Link to related page 2


11. References[edit source]

  1. 1.0 1.1 1.2 SSD1306 Linux kernel driver: drivers/gpu/drm/solomon/ssd130x.c
  2. 2.0 2.1 Dither article on Wikipedia: https://en.wikipedia.org/wiki/Dither