简介：基于STM32的LCD1602基本库是一份轻量驱动源码，面向嵌入式初学者及需要快速在STM32工程中加入字符液晶显示的开发者，适用于设备状态显示、参数查看、简单菜单等场景。压缩包内共2个文件，包含1个c源文件和1个h头文件，整体仅1KB；c文件封装了LCD1602初始化、字符写入、清屏等核心操作，h文件提供函数声明与控制指令宏，便于直接包含和调用。已有1968人学习下载，对同类项目有参考价值。开发者根据GPIO连接LCD1602后，调用初始化函数即可完成配置，并通过封装好的接口显示字符串、定位光标或控制显示属性；底层并行时序被隐藏，应用层只需关注逻辑，更换不同STM32型号时也容易适配。该资源以极简结构降低了LCD1602的驱动门槛，适合入门学习或快速搭建带显示功能的小型嵌入式系统。
1. 为什么我会把LCD1602封装成一个独立库
先交代一下背景。上半年做项目时要频繁调试传感器数据，每次都要在OLED和LCD之间换来换去，OLED驱动已经封装好了，LCD1602却每次都要从头写初始化时序。最烦的是不同板子用的引脚还不一样，换个板子就要改一遍代码。后来静下心把LCD1602整理成一个独立的.c/.h驱动库，后面所有项目直接复制粘贴改引脚定义就能用，省下来的时间非常可观。
如果你也处于这几个阶段，这个库对你应该有帮助：
- 刚开始学STM32，想搞明白LCD1602的时序协议到底是怎么回事
- 已经能点灯、会串口打印，想让数据显示更直观，但每次写1602驱动都写不利索
- 在课设或比赛里要用LCD显示，只想要一个稳定、接口清晰的驱动，不要那些网上到处复制、逻辑混乱的代码
这个库的设计思路很简单：底层是GPIO模拟的并行时序驱动，上层提供字符串显示、数字显示、清屏、光标控制这些常用功能。不需要依赖STM32标准库以外的任何代码，HAL库和标准库都能用，甚至换个单片机平台，只要把几个引脚定义宏改一下就能跑。
下载地址就不放了，GitHub一搜一大把，我更想把整个设计思路、每个函数为什么这么写、移植时怎么改讲清楚，你花十分钟看完，比自己摸索两小时效率高得多。
2. LCD1602的底层时序：并行接口、指令字和数据字
LCD1602这块屏，本质上就是一个遵守HD44780协议的显示模块，16个引脚里真正干活的只有6个：
- RS：寄存器选择。低电平写指令，高电平写数据
- RW：读写选择。低电平写，高电平读
- E：使能信号。下降沿锁存数据
- D0~D7：8位数据总线（也可以只接高4位用4线模式）
RS和RW决定了你当前在和屏幕的哪个“房间”对话，E引脚则像是一个“确认收货”按钮。你需要做的就是把数据放到总线上，然后给E引脚来一个从高到低的跳变，告诉LCD1602可以取走数据了。
时序参数在数据手册里写得很清楚，E高电平最短持续时间、读写信号的建立时间都是ns级别，对STM32这种几十MHz的主频来说，GPIO翻转本身就够慢的，几乎不需要额外延时。但为了稳妥起见，我在驱动里还是加了几个空操作延时，防止在更高主频下出阴间问题。
指令字和数据字的区别，可以用一个很生活化的例子来理解：指令字是给屏幕下命令，比如“光标移到第二行开头”“清屏”；数据字是给屏幕喂内容，比如“显示字符A的ASCII码0x41”。RS引脚就是这两类操作的开关。
LCD1602常用的指令字不多，按优先级排一下就是：
- 0x38：8位数据总线、2行显示、5×8点阵
- 0x0C：显示开、光标关、不闪烁
- 0x06：写入数据后地址自动加一，光标右移
- 0x01：清屏
- 0x80~0x8F：设置DDRAM地址（第一行起始0x80，第二行起始0xC0）
了解了这些，再看驱动代码里每个函数干什么就有数了，无非就是按时序把指令字或数据字通过GPIO送出去。
3. 驱动库文件拆分：头文件对外暴露接口，源文件隐藏实现细节
写驱动库和写业务代码不一样，接口设计得好不好，直接决定了别人（或者说一个月后的你自己）用起来顺不顺手。这个库的接口设计，我遵循了一个原则：底层操作全部封装在.c文件里，头文件只对外暴露用户真正需要的API和高频宏定义。
lcd1602.h 的结构大致是这样：
#ifndef __LCD1602_H #define __LCD1602_H #include "stm32f1xx_hal.h" // 用户修改区：根据自己的接线修改这几个宏 #define LCD_RS_GPIO_PORT GPIOB #define LCD_RS_PIN GPIO_PIN_11 #define LCD_RW_GPIO_PORT GPIOB #define LCD_RW_PIN GPIO_PIN_10 #define LCD_E_GPIO_PORT GPIOB #define LCD_E_PIN GPIO_PIN_0 #define LCD_D4_GPIO_PORT GPIOB #define LCD_D4_PIN GPIO_PIN_1 #define LCD_D5_GPIO_PORT GPIOB #define LCD_D5_PIN GPIO_PIN_2 #define LCD_D6_GPIO_PORT GPIOB #define LCD_D6_PIN GPIO_PIN_3 #define LCD_D7_GPIO_PORT GPIOB #define LCD_D7_PIN GPIO_PIN_4 void LCD_Init(void); void LCD_ShowString(uint8_t row, uint8_t col, char *str); void LCD_ShowChar(uint8_t row, uint8_t col, char ch); void LCD_ShowNum(uint8_t row, uint8_t col, int32_t num, uint8_t len); void LCD_ShowHex(uint8_t row, uint8_t col, uint32_t num, uint8_t len); void LCD_Clear(void); void LCD_SetCursor(uint8_t row, uint8_t col); #endif头文件里刻意没有暴露任何内部函数，比如LCD_WriteCmd、LCD_WriteData这些，都是static修饰，待在.c文件里。这样做的原因有两个：
一是调用者根本不需要关心底层协议，他们只想知道“在第几行第几列显示一串字符”，暴露底层函数只会增加误用的概率。二是编译器可以做更好的优化，static函数如果只在一个文件里被调用，内联起来毫无压力。
我见过很多所谓的“驱动库”，头文件里一股脑地堆了十几个函数声明，包括那些只在内部用一次的底层函数，用户看着就懵。库的接口设计要像餐厅菜单：客人只需要看到菜名和价格，后厨怎么炒菜不用端出来展示。
4. 核心API的实现细节：从GPIO操作到字符串格式化
4.1 底层时序函数，为什么用4线模式而不是8线
这里先解释一个很多人会纠结的问题：LCD1602明明支持8线并行，为什么驱动库普遍用4线模式？原因非常简单，节省GPIO。8线模式需要完整的D0~D7共8个数据引脚，加上RS、RW、E一共11个引脚；而4线模式只需要D4~D7共4个数据引脚，总共7个引脚。对STM32来说GPIO本来就不算富裕，省下来4个引脚无论接按键、接传感器都很舒服。
4线模式唯一付出的代价是要分两次发送一个字节：先送高4位，再送低4位。时序上只是多了一次写操作，速度影响微乎其微，LCD1602本身就不是高速设备，几十微秒的显示延迟用户根本感知不到。
底层写数据函数如下：
static void LCD_Write4Bit(uint8_t data) { HAL_GPIO_WritePin(LCD_D4_GPIO_PORT, LCD_D4_PIN, (data >> 0) & 0x01); HAL_GPIO_WritePin(LCD_D5_GPIO_PORT, LCD_D5_PIN, (data >> 1) & 0x01); HAL_GPIO_WritePin(LCD_D6_GPIO_PORT, LCD_D6_PIN, (data >> 2) & 0x01); HAL_GPIO_WritePin(LCD_D7_GPIO_PORT, LCD_D7_PIN, (data >> 3) & 0x01); LCD_E_SetHigh(); delay_us(2); LCD_E_SetLow(); }然后是写指令和写数据：
static void LCD_WriteCmd(uint8_t cmd) { LCD_RS_SetLow(); // 指令模式 LCD_RW_SetLow(); // 写模式 LCD_Write4Bit(cmd >> 4); // 先送高4位 LCD_Write4Bit(cmd & 0x0F); // 再送低4位 } static void LCD_WriteData(uint8_t data) { LCD_RS_SetHigh(); // 数据模式 LCD_RW_SetLow(); // 写模式 LCD_Write4Bit(data >> 4); LCD_Write4Bit(data & 0x0F); }这里有个小细节：RS和RW的电平设置必须在E引脚产生下降沿之前完成，并且要保持稳定。HD44780的时序要求是在E下降沿的时刻，RS、RW和数据线上的电平都必须有效。我在每个写操作前都先设置RS/RW，再写数据，最后拉低E，这个顺序不能颠倒。
4.2 初始化序列：为什么网上代码里的初始化顺序都不一样
LCD1602的初始化是一个特殊过程，因为上电后模块内部状态是不确定的，必须通过一串指令把它带到已知状态。这也是网上代码最容易出问题的地方，很多人的LCD不显示，多半就是初始化时序有问题。
我的初始化函数是这样的：
void LCD_Init(void) { // 等待模块内部上电复位完成 HAL_Delay(50); // 第一次握手：告诉模块使用8位模式 LCD_RS_SetLow(); LCD_RW_SetLow(); LCD_Write4Bit(0x03); delay_us(4500); // 第二次握手 LCD_Write4Bit(0x03); delay_us(4500); // 第三次握手 LCD_Write4Bit(0x03); delay_us(150); // 切换为4位模式 LCD_Write4Bit(0x02); delay_us(100); // 正式功能设置：4位模式、2行、5x8点阵 LCD_WriteCmd(0x28); delay_us(60); // 显示开关控制：开显示、无光标 LCD_WriteCmd(0x0C); delay_us(60); // 写入模式：地址自动加一 LCD_WriteCmd(0x06); delay_us(60); LCD_Clear(); }前三次0x03的握手，很多人不理解为什么要发三次。这是因为上电后LCD1602可能处于任意状态，只有连续发送0x03并保持一定间隔，才能确保模块稳定地进入8位模式的同步状态。如果你跳过或者缩短这些延时，模块可能还在内部复位，直接把后面的指令忽略掉了，表现为“屏幕背光亮但一个字都不显示”。
这里我用的都是固定延时，而不是读取忙标志（BF）。后面会专门说为什么这样设计。
4.3 字符串显示和数字显示的封装
显示字符串是做过封装的核心API：
void LCD_ShowString(uint8_t row, uint8_t col, char *str) { uint8_t i = 0; if (row > 1) row = 1; if (col > 15) col = 15; LCD_SetCursor(row, col); while (str[i] != '\0' && i < (16 - col)) { LCD_WriteData(str[i]); i++; } }这个函数相比之下多了两个判断：一是行列参数超限要钳制，二是字符串长度不能超过LCD一行的剩余空间。很多原版的驱动没有这两个保护，传入一个超长字符串，字符就会溢出到第二行，或者干脆写满第二行之后发生地址回绕，看起来很诡异。
数字显示的封装就要注意格式化处理：
void LCD_ShowNum(uint8_t row, uint8_t col, int32_t num, uint8_t len) { char buf[12]; char temp[12]; uint8_t i; uint8_t is_neg = 0; if (num < 0) { is_neg = 1; num = -num; } // 数字转字符串，不足len位前面补'0' for (i = 0; i < len; i++) { temp[i] = '0' + (num % 10); num /= 10; } if (is_neg) LCD_ShowChar(row, col, '-'); for (i = 0; i < len; i++) { buf[i] = temp[len - 1 - i]; } buf[len] = '\0'; LCD_ShowString(row, col + (is_neg ? 1 : 0), buf); }这段代码的作用是把一个int32_t类型的数字，按指定长度显示成定长字符串，比如LCD_ShowNum(0, 0, 123, 5)会在第一行显示“00123”。定长显示在仪表类项目里非常实用，不然你显示温度从9变成10的时候，最后一位残影根本消不掉。
要注意的是我这里没有用sprintf，原因有两个：一是Keil里默认的sprintf非常占Flash，对单片机资源是种浪费；二是自己实现这些转换函数，行为完全可控，不依赖编译器。
5. 忙标志检测 vs 固定延时：一个影响系统稳定性的关键取舍
HD44780协议其实提供了一个忙标志（BF）检测机制——读取D7引脚的电平，为高表示模块正在忙，不能接收新指令。理论上，严谨的驱动应该在每次写操作前都检查BF。
但这里有个前提：你要把RW引脚接出来用于读操作。很多精简方案为了省1个GPIO，直接把RW接地固定写模式，那就只能靠延时。
我的选择是：默认用固定延时，并把延时时间留足。原因很实际：LCD1602速度太慢了，即使最简单的指令也要消耗37微秒才能完成内部操作。如果我每次写指令前都去读BF，读操作需要把D7引脚配置成输入模式，写完再切回输出模式，GPIO模式切换本身就有开销，和直接延时40微秒相比，收益几乎为零。
但为了兼容需要读BF的场景，我在代码里保留了读BF的注释块，需要的话可以手动开启，把固定延时替换成忙标志检测。这不是二选一的死局，完全看你的系统对时可要求。如果LCD被调用的频率不高，固定延时完全不占资源；如果在定时器中断里频繁写LCD，那么读BF能减少空等时间，但对时基系统来说，任何阻塞式等待都可能带来风险。
我在实际固件中会把LCD操作尽量挪到主循环或低优先级回调里，中断里只置标志位，这样即使LCD延时再大也不会干扰实时性要求高的外设。
6. 移植到不同板子的三个主要改动点
很多人拿到这个库，直接往下编译，结果报一堆错或者屏幕不亮，就以为库有问题。其实大部分情况是移植没做对。换板子时，你必须检查以下三处：
6.1 引脚宏定义
头文件顶部的引脚定义必须改成你实际接线的引脚。这个不用多说，但要提醒一个反直觉的坑：RS、RW、E这三个控制引脚的顺序排列有讲究。PCB布线上，RS和RW挨在一起，E引到另一侧，如果你照抄别人的硬件设计，接好线后还要在代码里挨个对一遍宏定义，不然显示乱码时排查起来很痛苦。
6.2 时钟使能函数
如果你用的不是HAL库，而是标准库或LL库，GPIO时钟使能在system_init里就要准备好。我在lcd1602.c里的LCD_Init中默认不使能GPIO时钟，因为我的系统中GPIO时钟在板级初始化里已经全部打开了。如果你习惯在驱动里自己开时钟，需要加上类似这样的代码：
__HAL_RCC_GPIOB_CLK_ENABLE();6.3 延时函数的替换
我的库默认用HAL_Delay接收毫秒级延时，用自己封装的delay_us处理微秒级延时。不同的工程里延时的实现方式五花八门：用SysTick的、用DWT的、用定时器的，还有用空循环凑数的。移植时delay_us这个函数必须按你的平台重新实现，不然显示初始化过程中的时序完全不达标。
实际上，有个更省心的思路：微秒级延时可以直接用for循环无脑翻转GPIO几次来凑。LCD1602对时序的下限要求极低，多延长时间通常无害，只有E引脚高电平需要保证超过450ns。你只要确保不是零延时，基本都能跑。这个“宽松时序”的特性，是HD44780协议能活几十年的一个重要原因。
7. 显示异常排查链路：从背光亮但无字，到乱码，再到闪屏
写驱动项目最痛苦的不是写代码，而是屏幕不按预期工作。我按自己排查过的问题，按现象分了几类，说清楚根因和解法。
7.1 现象一：背光亮，但屏幕全白/全黑，无任何字符
这类问题优先查初始化时序。具体来说就是回到LCD_Init，确认每个步骤之后的延时有没有被编译器优化掉。有个坑：如果你写成for (i = 0; i < 100; i++);，并且开启了-O2优化，编译器可能整个循环直接删掉，延时等于零，LCD根本无法完成握手。
解法是延时函数体里要有编译器“不敢动”的变量操作，或者干脆用HAL_Delay。一开始就用HAL_Delay的人永远不会遇到这个问题，但手写延时函数的人一定要小心优化开关。
另外，如果对比度电位器旋错了位置，也会表现为“有背光、无字符、屏幕均匀滚白”。LCD1602的V0引脚接一个10~20K电位器，调节电压差可以控制显示对比度。这大概是最被忽略的硬件坑，因为软件怎么调都不会有变化。
7.2 现象二：显示乱码，或者字符不对
乱码的原因多半是RS引脚逻辑反了，或者时序中把指令字和数据字搞混了。举个例子，如果RS拉高和拉低的操作写反了，那么所有本该是数据的内容都会被当成指令执行，屏幕上的“字形”会变得零乱。
排查方法：用逻辑分析仪抓RS、RW、E、D7这几根线的波形，对照数据手册检查每个写操作前后的电平是否符合预期。没有逻辑分析仪的话，可以用GPIO翻转来粗糙地“示波”——在LCD_WriteCmd前后翻转某个调试引脚，用示波器看时间间隔是否正常。
另一个常见原因是字符编码问题。LCD1602内置字库是ASCII码，你如果直接往里面塞GB2312编码的中文字符，只会得到一堆乱码。和LCD1602打交道，老老实实用ASCII字符。想显示中文，要么自己做字模存CGRAM，要么换带中文字库的LCD12864，这也是很多人从1602转向12864的根本原因之一。
7.3 现象三：屏幕能显示，但一闪一闪，或者过一会儿才亮
闪屏通常是供电不足或者GPIO驱动能力不够。LCD1602的背光模块电流在几十毫安级别，如果用单个GPIO直接驱动背光，电流很可能不够，背光会暗淡甚至闪。正确做法是背光接一个三极管或MOS管驱动，GPIO只控制开关。
还有一种闪屏是软件级的：如果LCD初始化函数被多次调用，每次都会重新握手并清屏，看起来就像屏幕在闪。检查你的主流程里有没有不小心重复调用LCD_Init。
7.4 现象四：屏幕输出内容有拖影或残影
残影的本质是上一条字符串末尾的字符没有擦除。解决思路有二：一是每次显示前清屏，但要注意频繁清屏会带来闪烁；二是所有数字显示都用定长模式，不足位补空格或补0，把上一次的内容“覆盖”掉。这也是我在LCD_ShowNum里引入len参数的原因——它不只为了好看，更是为了防空。
8. 一个实用小技巧：用LCD1602做一个微型的系统监视器
最后分享一个彩蛋级用法。LCD1602不只能显示你主动push的数据，还能在调试阶段当一个廉价的系统监视器用。
我做的一个项目里，需要知道系统电压、CPU占用率和定时器中断频率。我开了一个软件定时器，每500ms调用一次更新函数，分别读取这些参数并格式化到LCD上。因为LCD1602刷新速度慢，高频率的数据变化反而看不清，这个低频率的轮询刷新恰好合适。
我把关键代码贴出来：
void SystemMonitor_Task(void) { char strBuf[17]; uint16_t vbat_mv = Read_Battery_Voltage(); uint8_t cpu_load = Get_CPU_Load(); LCD_ShowString(0, 0, "BAT:"); LCD_ShowNum(0, 4, vbat_mv, 4); LCD_ShowString(0, 8, "mV"); LCD_ShowString(1, 0, "CPU:"); LCD_ShowNum(1, 4, cpu_load, 3); LCD_ShowString(1, 7, "%"); }这里有个很隐蔽的坑：我用LCD_ShowNum显示vbat_mv，如果电压从4125变成298，显示结果是“0298”而不是“ 298”，虽然看得懂，但数字会向左对齐跳动。如果你想右对齐显示，可以用一个简单的补空格函数：
static void LCD_ShowNumRightAlign(uint8_t row, uint8_t col, int32_t num, uint8_t len) { char buf[12]; snprintf(buf, sizeof(buf), "%*ld", len, num); LCD_ShowString(row, col, buf); }不过这又回到了snprintf的Flash占用问题。折中做法是自己写一个转置函数，把数字转成字符串后，数一下长度，前面补空格。代码量也不长，直接看书就行，跟前面的定长转换逻辑一样，区别是高位补的是空格。
写到这里，这个库的核心设计、API细节、移植要点和常见问题基本都覆盖了。我的体会是，LCD1602虽然技术含量不算高，但恰恰是这种“简单外设”最能锻炼驱动封装能力：你要考虑接口边界、时序细节、异常处理、可移植性，每一步都有取舍。把这类基础外设的驱动写好、写稳，后面上I2C、SPI、甚至上RTOS时，很多设计思想是完全通用的。
本文还有配套的精品资源，点击获取
