Designing a Modular LCD Driver Framework for STM32 Embedded Systems

Many STM32 development boards provide LCD examples, but they often suffer from poor modularity, tangled interfaces, low portability, and limited reusability. The article first lists typical problems such as unclear layering, chaotic interfaces, poor portability, and lack of generality, then poses concrete scenarios that illustrate why these issues matter.

LCD Types Overview

Three common LCD families are introduced:

TFT LCD : High‑resolution color screens (e.g., 2.8" 320×240, 4" 800×400) usually driven via 8080/6800 parallel bus or RGB interface; SPI is discouraged for large screens.

COG LCD : Chip‑On‑Glass displays with low resolution (e.g., 128×64, 128×32), typically monochrome or grayscale, driven via SPI or I²C; driver IC example: STR7565.

OLED LCD : Small, high‑quality displays without backlight, driven via SPI/I²C; driver IC example: SSD1615.

Hardware Scenario

The design assumes four devices:

TFT screen on FSMC (unknown model).

COG LCD (STR7565, 128×32) on GPIO.

COG LCD (STR7565, 128×64) on SPI3.

OLED LCD (SSD1315) on SPI3 with separate CS.

Prerequisite Concepts

Object‑oriented programming in C is demonstrated with a simple LED example, showing how to encapsulate state and behavior in a struct and provide a uniform API. This concept is then extended to LCD devices, treating each display as an object whose attributes (size, bus, driver ID) are separated from its methods (initialization, drawing, backlight control).

Driver‑Device Separation

The core idea is to keep the driver code independent of specific hardware instances. A driver implements a set of generic functions (init, draw_point, fill, onoff, set_dir, backlight, etc.) defined in a _lcd_drv structure. Each LCD device supplies a DevLcd instance that references its parameters, driver, and runtime state, allowing the same driver to control multiple devices.

Modular Architecture

The framework consists of three layers:

GUI & LCD layer : Manages device lists, parameter tables, and provides high‑level APIs such as dev_lcd_put_string. Example structures _lcd_pra (static parameters) and LcdObj (device tree) are shown.

Driver‑IC layer : Implements the low‑level driver for each IC (e.g., CogLcdST7565Drv, TftLcdILI9341Drv) and abstracts the bus (8080, SPI, VSPI) via a unified "buslcd" interface.

Interface layer : Provides hardware‑specific primitives for SPI, FSMC, and GPIO, exposing functions like mcu_spi_init, mcu_spi_transfer, etc.

Overall Flow

During initialization, the system scans the device tree, matches each device with its driver and parameters, and populates a DevLcd structure. Applications open a device with dev_lcd_open(name), receiving a pointer to the corresponding DevLcd. All subsequent operations (drawing points, filling areas, displaying strings) are performed through the driver functions referenced in this structure, ensuring that the same code works for any LCD type.

Usage Example

A test program demonstrates opening three devices (OLED, COG, TFT), turning on backlights, and printing strings with different fonts and colors on each screen. The same dev_lcd_put_string API works across all displays, highlighting the benefit of a unified interface.

Benefits

Adding or moving a display only requires updating the device‑tree array; no driver code changes are needed.

One set of GUI functions serves all screens, reducing code duplication and simplifying application logic.

Font Library

Font data is stored on an SD card; the implementation details are in font.c and can be adapted as needed.

License Notice

The source code is provided under a copyright agreement, with plans to publish the full repository on GitHub for further development.