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.
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]
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.
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
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. Alternatives for driving these display panels[edit source]
9. References[edit source]
- ↑ 1.0 1.1 1.2 SSD1306 Linux kernel driver: drivers/gpu/drm/solomon/ssd130x.c
- ↑ 2.0 2.1 Dither article on Wikipedia: https://en.wikipedia.org/wiki/Dither