STM32 Proteus仿真入门：LCD1602与4×4矩阵键盘驱动模板

简介：基于STM32F103C8T6的Proteus基础模板，围绕LCD1602液晶显示与4乘4矩阵键盘交互，面向初学者快速构建单片机原型。工程由CubeMX初始化，基于HAL库编写驱动，可在Proteus仿真中直接运行。压缩包约6.25MB，共167个文件，包括源码（h与c）、CubeMX配置（ioc）、Proteus工程（pdsprj）及hex固件等，便于对照学习与二次开发。该模板已有784人学习浏览。通过它可掌握GPIO配置、时钟初始化、LCD1602时序控制、矩阵键盘扫描及中断处理等关键流程，同时理解HAL库的封装与调用逻辑。代码结构清晰，适合作为课程设计或毕业设计起点，后续也可扩展串口通信、传感器读取等功能。 很多刚学STM32的朋友都有过类似的经历：开发板上点亮LCD1602、扫描4×4矩阵键盘都顺顺利利，代码一跑就出效果；可一旦想着"我把它挪到Proteus里做个仿真，或者画个原理图给毕设用"，就各种莫名其妙的问题全冒出来了——屏不亮、乱码、按键没反应，甚至仿真器直接报错不干活。

我平时帮人调这类基础外设项目调得比较多，也逐渐攒了一套相对稳定的"基础模板"：STM32F103C8 + Proteus仿真 + LCD1602显示 + 4×4矩阵键盘输入。这套组合覆盖了GPIO操作、时序外设驱动、按键扫描消抖、模块化建工程这几个嵌入式入门的核心点，非常适合拿来练手，也适合做课程设计或毕业设计的前置验证。如果你正打算在Proteus里跑通一个"能显示、能输入"的完整小系统，这篇文章应该能帮你少走不少弯路。

1. 这个模板到底解决的是什么问题

先说说我为什么反复推荐用这个组合当基础模板。LCD1602是字符型液晶显示器的入门款，一次能显示两行、每行16个字符，时序逻辑清晰，几乎没歧义；4×4矩阵键盘则是学习行列扫描最典型的外设，16个按键只占8个IO口。两者配合起来，就是一个"输入→处理→输出"的完整闭环，比单纯点灯有意义得多。

但真正见功夫的地方在于：Proteus仿真和真实硬件之间的差距。开发板上外设的电源、上拉、滤波这些都已经帮你处理好了，你用代码操作寄存器基本"指哪打哪"。仿真环境不一样，引脚模式、时钟配置、外围电路的完整度，每一项都直接影响最终结果。比如GPIO没有配置成合适的模式，真实硬件上可能勉强能跑，仿真里就会直接表现成逻辑电平不对，进而让LCD1602显示乱码、矩阵键盘扫不出正确的键值。

这个模板里，我特意把硬件连接方式固定下来、把代码模块化拆开，让"显示"和"输入"两条链路彼此独立又能协作。做课程设计时，你可以在这个基础上加传感器采集、加PWM调速、加串口通信，不用每次从头去折腾底层显示和按键。

我的建议是：拿到这套模板以后不要急着跑仿真，先花十分钟把原理图里每一个引脚连到哪个GPIO、为什么连到这个GPIO搞明白。这一步想通了，后面加什么外设都顺。

1.1 模板的硬件环境

我用的芯片是STM32F103C8T6，72MHz主频，64脚（实际C8T6是48脚，Proteus里选STM32F103C8即可），资源足够这个场景用，也是Proteus里最容易获取和仿真的型号之一。Proteus版本建议8.x以上，元件库完整度更好、仿真速度也更快。

引脚分配按功能分成两片区域：

LCD数据线我用的是4线模式，D0-D3悬空。这样做的原因是省IO，而且能让PCB或仿真图纸的走线清爽很多，也给后面的传感器留出位置。

1.2 为什么采用LCD1602和4×4矩阵键盘来搭这套基础

LCD1602和矩阵键盘其实是"教科书级"的外设组合，但恰恰因为太基础，很多人反而不重视，觉得"网上代码一大把，抄一个就行了"。这种心态在仿真环境里特别容易栽跟头，因为仿真器对未初始化引脚的模拟非常严格，一个位没置对，整屏就是花的。

我见过不少人的LCD1602代码都是从51单片机那套改过来的——不是不能用，但STM32的GPIO初始化、时钟使能、延时精度都和51差异很大，直接平移过来的代码往往时序不对，LCD1602就是不工作。矩阵键盘也是，51里常用的"逐行拉低扫描法"到STM32上如果不在初始化阶段正确配置开漏或推挽模式，读列线时就会得到一堆随机数据。

这套模板的价值，就是把这两块外设里最容易出问题的"底层细节"一次配好，并提供一个能直接复用的初始化函数集合。你后面的代码只需要关注业务逻辑，不需要再为"为什么屏不亮"浪费一天时间。

2. Proteus仿真里最容易埋雷的硬件配置细节

这块内容是我特别想写的。很多人代码写得没问题，一放到Proteus里就"翻车"，问题十有八九不在代码，而在建图和芯片配置上。

2.1 芯片选型和时钟配置的坑

Proteus里的STM32F103C8支持仿真，但仿真模型对时钟的处理和真实芯片有些差别。真实板子上一般用8MHz晶振配合PLL倍频到72MHz，Proteus里也可以用HSI内部时钟或直接添加晶振器件。

实测下来，LCD1602这种低速外设对时钟精度并不敏感，8MHz和72MHz都能正常显示，关键是工程配置的时钟要和代码里SystemInit的预期一致。如果你用标准外设库或HAL库，默认都会调用SystemInit读RCC寄存器——在Proteus里，如果芯片型号选错（比如选了F103RB），Flash容量和SRAM信息不匹配，系统起不来是常事。

建议统一用"STM32F103C8"，晶振用8MHz，启动文件用startup_stm32f10x_md.s（中等容量），这个搭配在Proteus里最稳。我自己第一次在Proteus里跑的时候，就是因为芯片选了个大容量的F103ZE，结果程序停在启动文件里出不来，屏幕上啥都没有。

2.2 GPIO模式的隐藏雷区：开漏和推挽的选择

STM32的GPIO可以配置成多种模式，仿真环境下最常见的问题出在"开漏输出"和"推挽输出"之间。

LCD1602的数据线和控制线，我建议全部用复用推挽输出。有的人习惯用开漏输出再接外部上拉电阻，这在真实电路里没问题，但Proteus仿真里如果上拉电阻阻值选得不合适，信号上升沿会非常慢，LCD1602读到的数据就是错的。不是"显示乱码"，就是"偶尔正常偶尔不对"——这类问题最难排查，因为看起来像时序问题，其实是电平问题。

矩阵键盘的行线用推挽输出，列线用上拉输入（或者浮空输入配合软件内部上拉）。这里有个细节：STM32内部上拉的阻值在仿真里和真实芯片并不完全一致，如果你的列线直接接地没有串电阻，读到的数据极不稳定。所以我的习惯是在矩阵键盘的列线上也加上10kΩ上拉电阻，仿真稳定度和真实板子比较接近。

我做一个典型的连接配置清单供你对照。

2.3 电源和地：仿真图纸的"隐形杀手"

另一个容易被忽略的是Proteus里STM32模型默认没有显式电源引脚。你用搜索栏放出来一个STM32F103C8，它是默认已经接好VDD和VSS的，不像51单片机那样需要手动给40脚接5V。但如果你在图纸上额外添加了LCD1602的背光电源或者逻辑电源，一定要确保它们用的是同一个电源网络（一般是用POWER端子标VCC），不然LCD1602灯亮了但不显示字符，查半天发现是逻辑电源没接上。

我平时画的Proteus图纸，习惯在原理图一角统一放置VCC和GND的电源端子，所有器件需要供电的网络都从那边拉过来。这样做有三个好处：一是电源网络一目了然，二是仿真报错容易定位，三是后续扩展器件时不用到处找电源。

3. LCD1602驱动：初始化时序和读写函数一次讲透

LCD1602的底层驱动不外乎几件事：初始化序列、写命令、写数据、光标控制。网上代码一大堆，但很多都是直接抄的，连延时都没有，跑在Proteus里就出事。这里我按自己的模板把代码拆开讲清楚，说明每一步在干什么。

3.1 写命令和写数据的基本函数

在4线模式下，数据是一次性通过D4-D7分两次发送的：先发送高4位，再发送低4位。很多人第一次写4线驱动会忘记这个"先高后低"的顺序，导致LCD1602收到莫名其妙的命令，显示自然不对。

void LCD_WriteCmd(uint8_t cmd) { GPIO_ResetBits(GPIOA, GPIO_Pin_0); // RS=0, 命令模式 GPIO_ResetBits(GPIOA, GPIO_Pin_1); // RW=0, 写模式 LCD_WriteNibble(cmd >> 4); // 发高4位 LCD_WriteNibble(cmd & 0x0F); // 发低4位 Delay_us(50); } void LCD_WriteNibble(uint8_t nibble) { GPIO_ResetBits(GPIOA, GPIO_Pin_4 | GPIO_Pin_5 | GPIO_Pin_6 | GPIO_Pin_7); if (nibble & 0x01) GPIO_SetBits(GPIOA, GPIO_Pin_4); if (nibble & 0x02) GPIO_SetBits(GPIOA, GPIO_Pin_5); if (nibble & 0x04) GPIO_SetBits(GPIOA, GPIO_Pin_6); if (nibble & 0x08) GPIO_SetBits(GPIOA, GPIO_Pin_7); GPIO_SetBits(GPIOA, GPIO_Pin_2); // EN=1 Delay_us(10); GPIO_ResetBits(GPIOA, GPIO_Pin_2); // EN=0 Delay_us(10); }

这里有个细节值得注意：写完之后不要立刻切换RS的状态，要先等一小段时间。LCD1602内部处理一条指令需要一定时间，尤其在仿真环境里，如果指令间隔太短，后续指令会被丢弃，表现出来就是"第一行显示正常，第二行乱码"或者"字符显示错位"。

3.2 初始化序列为什么是这个顺序

LCD1602的初始化顺序非常固定，从上电到进入4线模式，每一步都有它的道理。网上那些"精简版"初始化代码虽然也能跑，但在仿真里很容易出现首行不显示的问题。

void LCD_Init(void) { Delay_ms(50); // 等待LCD上电稳定 LCD_WriteNibble(0x03); // 切换到8线模式的初始命令 Delay_ms(5); LCD_WriteNibble(0x03); Delay_us(100); LCD_WriteNibble(0x03); // 第三次发送8位命令 LCD_WriteNibble(0x02); // 切换为4线模式 LCD_WriteCmd(0x28); // 4线模式、2行、5x8点阵 LCD_WriteCmd(0x0C); // 显示开、光标关、闪烁关 LCD_WriteCmd(0x01); // 清屏 Delay_ms(2); LCD_WriteCmd(0x06); // 地址自动+1，光标右移 LCD_WriteCmd(0x80); // 将DDRAM地址设为0x00，即第一行第一列 }

前三次写0x03，是为了在不确定LCD当前处于什么模式的情况下，强制把它拉回8线模式，然后再切换到4线。很多人省掉前两次，直接从4线模式开始初始化，这在真实硬件上偶尔能蒙对，因为硬件的上电时序和速度够快；但在Proteus的仿真时序里，非常容易导致LCD没进入正确的模式，后面所有指令都白写。

我踩过的一个真实教训：有段时间我为了"精简代码"，把前三次0x03改成了一次，结果在Proteus里死活显示不出来。折腾了一下午，后来老老实实把完整初始化加回去，一次就过了。从那以后我再也不在初始化时序上做"优化"。

3.3 字符显示和光标定位函数

显示一个字符其实就是写DDRAM地址，然后写对应的ASCII码。LCD1602的DDRAM地址布局要记住：第一行0x00-0x0F，第二行0x40-0x4F。所以定位到第二行第三个字符，实际写入的地址就是0x40 + 2 = 0x42。

void LCD_SetCursor(uint8_t row, uint8_t col) { uint8_t addr; if (row == 0) addr = 0x00 + col; else if (row == 1) addr = 0x40 + col; LCD_WriteCmd(0x80 | addr); } void LCD_ShowString(uint8_t row, uint8_t col, char *str) { LCD_SetCursor(row, col); while (*str) { LCD_WriteData(*str++); } }

这套函数写清楚以后，显示数据就变成了一件很简单的事情：SetCursor定位置，ShowString填内容。后面接4×4矩阵键盘时，整个联动逻辑就非常清晰了。

4. 4×4矩阵键盘：扫描原理与稳定键值映射

矩阵键盘的核心价值就是省IO：16个按键只占8个IO口。原理是行列交叉，每一行和每一列的交叉点一个按键；扫描时逐行拉低，再读列线，看哪一列也是低电平，就知道哪个按键被按下。

4.1 行扫描法的具体实现

逐行扫描是理解矩阵键盘最直接的方式。以4×4矩阵为例，行线接PB0-PB3，列线接PB4-PB7。初始化时，行线配置为推挽输出，列线配置为上拉输入（最好外部也加上拉电阻）。

uint8_t Key_Scan(void) { uint8_t row, col; uint16_t key_value = 0; GPIO_ResetBits(GPIOB, GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3); // 全部拉低 if ((GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_4) == 1) && (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_5) == 1) && (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_6) == 1) && (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_7) == 1)) { return KEY_NONE; // 没有按键按下 } for (row = 0; row < 4; row++) { GPIO_ResetBits(GPIOB, GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3); GPIO_SetBits(GPIOB, GPIO_Pin_0 << row); // 拉高其他行，只拉低当前行 for (col = 0; col < 4; col++) { if (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_4 + col) == 0) { key_value = row * 4 + col + 1; // 映射为1~16 } } } return key_value; }

这里有一个很容易犯的错：扫描前必须把所有行线先全部拉低一次，用来判断"是否有按键"。如果你跳过这一步，直接逐行扫描，有可能漏掉某一行按下的按键。这个"预扫描"步骤虽然多几行代码，但对稳定性提升非常明显。

4.2 消抖策略：延时消抖还是状态机？

按键消抖几乎是所有按键项目的必经环节。矩阵键盘比独立按键更容易出现抖动，因为扫描本身有开销，按下的瞬间可能被扫描到多次。

我建议用"两次扫描间隔消抖"：第一次检测到按键后等待10-20ms，再次确认同一个位置仍然是按下状态，才认为按键有效。这个方案简单直接，在Proteus仿真里足够稳定。追求代码更优雅的朋友可以上状态机消抖，但对这个基础模板来说，反而显得复杂了。

uint8_t Key_GetPressed(void) { uint8_t key; key = Key_Scan(); if (key != KEY_NONE) { Delay_ms(20); // 消抖 if (Key_Scan() == key) { return key; } } return KEY_NONE; }

有一个细节需要注意：消抖延时期间如果还做着LCD刷新等耗时操作，按键响应会变慢。所以在主循环里，我一般把按键检测和显示刷新错开时间片，或者把消抖延时降到10ms级别。真实项目中用定时器做分时调度更好，但在这个模板里保持简单即可。

4.3 键值映射：从"行×列"到用户能看懂的字符

扫描函数返回的是1-16的数字，真正显示到LCD上时需要映射成字符，比如0-9、A-F、*、#之类的。我习惯做一个简单的映射表：

这样键盘和LCD的配合就非常自然：检测到哪个键，就在屏幕上显示对应的字符，天然形成了"输入→显示"的闭环。

5. 键盘输入和LCD显示的联动逻辑：怎么让两者配合起来

LED1602负责显示，矩阵键盘负责输入，两者单独工作都正常之后，真正的"项目感"来自于把两件事串成一个完整逻辑。这一步没有太多技术含量，但结构设计得好不好，直接影响你后续加功能的难度。

5.1 主循环的架构选择

最常见的主循环写法有两种：一种是"顺序执行式"，整个循环里依次做键盘扫描、显示刷新；另一种是"事件驱动式"，平时只做显示，检测到按键事件才去更新显示。

对这个模板来说，我推荐顺序执行式，因为逻辑简单、不容易踩坑。矩阵键盘的扫描速度很快，单个按键的检测耗时在百微秒级别，完全不影响LCD1602的显示刷新。事件驱动式需要引入状态标志位和中断，在这个阶段属于给自己加负担。

int main(void) { uint8_t key; Delay_Init(); GPIO_Config(); LCD_Init(); LCD_ShowString(0, 0, "Key:"); while (1) { key = Key_GetPressed(); if (key != KEY_NONE) { LCD_SetCursor(0, 5); LCD_WriteData(Key_MapToChar(key)); } } }

一个非常重要的细节：LCD1602的显示内容不需要反复刷新。有的人喜欢把"显示"放在while循环里每次都调用，这会导致屏幕闪烁。正确做法是只有数据变化时才去更新对应位置的字符。上面的例子里，只有检测到新按键才更新一次显示，整个程序运行起来非常稳定，屏幕也不闪。

5.2 多按键输入和简单状态机的扩展思路

如果后续需要实现类似"输入4位密码，按#确认"的功能，我的建议是先把键盘按键映射独立成一个模块，然后增加一个简单的输入状态缓冲区。

比如用一个数组存储用户按下的按键序列，每次检测到按键就追加进数组并显示在当前行；检测到#就把数组内容当成一次完整输入去处理。这种设计在课程设计中非常实用，比如"密码锁""简易计算器"都能在此基础上扩展出来。

我在带学生做课设时，让他们先在这个模板上跑通"按键显示"，再改成"密码判断"——一般半天能搞定。如果直接从空白工程开始做密码锁，光LCD1602底层的调试就能耗掉两天时间，这就是模板的意义。

6. 调试手记：Proteus仿真里最常见的几个翻车现场

写这节时我回顾了自己和身边人经常遇到的问题，挑几个发生率最高的整理成一个排查表格。这些都是真实调试过程里最容易卡住的地方。

针对表格里那几个重点再展开一下。

LCD乱码问题是最普遍的。很多人的代码在真实开发板上下载正常，一放到Proteus就乱码，原因多半是GPIO配置。真实硬件上即使模式配置不太对，由于外部电路的上拉/下拉能力比较强，还能勉强工作；但仿真器是严格按照引脚模型计算的，模式配置不对就是不对，结果就是逻辑电平错误，显示乱码。遇到乱码第一反应不应该是"时序有问题"，而是"引脚模式正确吗"。

矩阵键盘的跳号问题也很有迷惑性。表面上看，按键从0到9扫描出来都正常，但按下某个键偶尔会触发两次或者触发相邻键。这个在纯仿真里常见的原因是预扫描逻辑漏了"先把所有行线拉低"这一步，导致误判了其他行的按键状态。另外，如果消抖延时不加，按键速度稍快一点就会出现一次按下被扫描到多行的情况。

仿真卡顿则往往被误认为是"代码效率低"。有一次我调一个稍微复杂的显示界面，仿真卡到一秒刷新一帧，最后发现问题不是代码效率，而是Proteus里开了太多波形探针。把探针删掉之后速度立马恢复正常。所以遇到仿真卡顿，先检查是不是调试工具本身拖慢了速度。

最后再分享一个经验：Proteus仿真的优先级是"先跑通逻辑、再调显示效果"。不要一开始就把时钟倍频到72MHz，先拿默认8MHz把LCD1602和矩阵键盘跑通，验证扫描和显示逻辑没问题了，再考虑倍频、加中断、加复杂算法。这样每一层都建立在已经验证的基础上，排查问题会快得多。

这套模板我前后迭代过几个版本，从最早的8线LCD驱动改成4线省IO版，从纯轮询按键改成带消抖确认版。现在这个版本每一步都用最朴素、最直观的方式实现，恰恰因为它朴素，反而最适合作为后续所有STM32项目的地基。你要是刚开始接触这块，先把这套模板跑通，再慢慢往里加东西，整个学习路径会顺畅很多。

本文还有配套的精品资源，点击获取