简介：本资源是一套面向嵌入式初学者与STM32课程实践者的Proteus仿真基础模板，聚焦STM32F103C8T6单片机的外设驱动与人机交互开发，解决入门者在硬件资源受限时难以快速验证LCD显示与矩阵键盘功能的问题。压缩包共167个文件，含58个C/C++源码（.c/.h）、22个编译中间文件（.o/.d）、21个链接依赖（.crf/.dep）及3个Proteus工程（.pdsprj），完整覆盖CubeMX生成的HAL库工程结构，包含GPIO、TIM、UART、FLASH等标准外设驱动文件，便于理解底层初始化逻辑与模块化代码组织。已有792人学习下载，适合开展课堂实验、课程设计或自学演练。读者可直接导入Keil与Proteus进行联合仿真，观察4×4矩阵键盘扫描过程与LCD1602实时字符响应，掌握中断配置、按键消抖、字符发送时序等关键实践细节，并基于该模板快速扩展温度采集、密码锁等进阶功能。

1. 这不是“单片机玄学”，而是一套能立刻点亮屏幕、按出数字的入门组合包

你是不是在搜索“STM32 入门”时，看到过这样的画面：开发板插满线、Keil界面密密麻麻、Proteus里一堆红叉报错、LCD屏黑着、按键按下去没反应……最后关掉软件，默默怀疑自己是不是不适合学嵌入式？别急——这根本不是你的问题。真正卡住新手的，从来不是芯片多难，而是第一步缺一个“能跑通”的最小闭环：按下键 → 屏幕立刻显示数字 → 你能看懂每一行代码在干什么 → 下次自己改个字符也能成功。这份“STM32单片机Proteus基础模板：LCD1602显示加4×4矩阵键盘”，就是专为这个“第一次亮屏时刻”准备的：它不讲寄存器手册的千页厚，不堆RTOS或FreeRTOS概念，就用最直白的C语言，把STM32怎么控制LCD、怎么扫描键盘、怎么把按键映射成数字，全打包进一个Proteus仿真工程里。你不需要买开发板、不用烧录器、不用接线——打开就能看波形、点按键、改代码、实时观察结果。适合零基础、刚学完C语言、连GPIO是啥都还在查百度的同学；也适合被“裸机驱动”吓退、想先建立手感再啃底层的转行者。它解决的，就是一个最朴素的问题：我写的代码，到底有没有被芯片听懂？

2. 先搞懂三件事：为什么是STM32 + Proteus + LCD1602 + 4×4键盘这个组合？

2.1 为什么选STM32而不是51或Arduino？

很多新手以为“51简单，该从它开始”，但现实是：51的资源太老，教程里用的Keil C51现在连Win10都装不上；而Arduino虽然“一键上传”，可一旦你想弄懂“为什么按下键屏幕才变”，它那层封装就会变成黑匣子——你改不了扫描时序，调不了延时精度，更看不到IO口电平怎么跳变。STM32（这里指主流F1系列，如STM32F103C8T6）刚好卡在一个黄金平衡点：它有足够清晰的寄存器映射（比如GPIOA->ODR |= (1<<5)就是点亮PA5），官方标准外设库（STDPeriph）或HAL库文档齐全，更重要的是——Proteus对它的仿真支持成熟稳定。你不用等硬件到货，也不用担心接错线烧芯片，所有IO行为、中断触发、定时器溢出，在Proteus里都能用逻辑分析仪一帧帧拉出来看。这不是偷懒，是把“验证想法”的时间从“等快递+调试硬件”压缩到“改完代码→点仿真→看结果”三步内。

2.2 为什么Proteus是新手第一站？

有人问：“不直接用真实开发板吗？”答案很实在：真实板子上，一个接线松动、一个电容虚焊、一个下载接口接触不良，就能让你卡三天，最后发现是杜邦线坏了。而Proteus是纯数字仿真——它不模拟焊点氧化，不模拟电源纹波，只忠实执行你写的代码逻辑和电路连接关系。这份模板里，你看到的LCD1602模块，引脚已按标准4位模式接好（RS、RW、E、D4~D7），4×4键盘的8根线也已对应连到STM32的PA0~PA7——所有物理连接错误，Proteus会在启动仿真前就标红报错，比如“LCD_RS not connected”。你第一次运行，如果屏幕不亮，问题100%出在代码逻辑或初始化顺序，而不是“不知道哪根线没插紧”。这种确定性，对建立信心太关键了。我第一次带某高校嵌入式实训班时，A同学前三天反复重焊开发板，第四天换Proteus模板后，当天就调通了键盘输入，下课时他盯着屏幕上跳动的“KEY: 5”笑了十分钟。

2.3 为什么是LCD1602 + 4×4键盘这个“经典搭档”？

LCD1602不是最炫的屏，但它够“诚实”：它没有SPI/QSPI高速总线，不依赖复杂驱动IC，就靠最基础的并行IO口+严格时序（比如E引脚高脉冲必须≥450ns）来通信。4×4键盘也不是最酷的输入设备，但它把“按键抖动消除”“行列扫描”“键值解码”这三个嵌入式必踩坑环节，全浓缩在一个8引脚器件里。这份模板没用中断或DMA，就用最朴素的“查询法”：主循环里先拉低第0行（PA0=0），读PA4~PA7看哪列有低电平，再拉低第1行（PA1=0），再读……直到定位到具体键。整个过程，你能在Proteus里用虚拟示波器，亲眼看到PA0从高变低、PA4从高变低、然后LCD的DB7引脚跟着跳变——每一个电平变化，都对应一行你写的C代码。这种“所见即所得”的反馈，比任何理论讲解都管用。

提示：这份模板基于STM32F103C8T6最小系统，使用标准外设库（STDPeriph），Keil MDK-ARM v5.2x编译环境，Proteus 8.9以上版本仿真。所有文件均为.c/.h/.dsn格式，无加密、无混淆，函数命名直白（如LCD_Init()、KEY_Scan()），变量名不缩写（如row_num而非r_n）。

3. 第一步：下载、解压、打开——5分钟完成环境搭建

3.1 下载与目录结构说明

你拿到的压缩包，解压后是这样一个干净结构：

STM32_LCD_KEY_Template/ ├── Project/ ← Keil工程文件夹 │ ├── STM32F10x_FWLib/ ← 标准外设库（已精简，只含RCC/GPIO/EXTI） │ ├── USER/ │ │ ├── main.c ← 主程序：初始化+主循环 │ │ ├── lcd1602.c/h ← LCD驱动：初始化、清屏、写字符串、写单字符 │ │ └── key4x4.c/h ← 键盘驱动：扫描、去抖、返回键值 │ ├── STM32F103C8T6.uvprojx ← Keil工程文件（双击即可打开） ├── Simulation/ ← Proteus仿真文件夹 │ └── STM32_LCD_KEY.dsn ← 主电路图文件（双击用Proteus打开） └── Docs/ └── README.md ← 快速上手指南（含常见问题速查）

注意：没有额外安装包、没有注册机、没有“破解工具”。Keil和Proteus需你自行安装（官网免费版足够），模板不依赖任何第三方库或插件。

3.2 Keil工程：如何确认它真能编译？

打开Project/STM32F103C8T6.uvprojx，Keil会自动加载工程。重点看三个地方：

1. Target选项卡：确认Device选的是STM32F103C8（不是F103CB或F103ZE）；
2. Output选项卡：勾选Create HEX File（Proteus需要.hex文件加载）；
3. User选项卡：检查Run #1命令是否为：

   copy "$$L" "..\Simulation\STM32F103C8T6.hex"

   这行命令的作用是：每次编译成功后，自动把生成的.hex文件复制到Simulation/文件夹，供Proteus读取。如果没这行，你得手动复制，容易忘。

点击“Rebuild all target files”（锤子图标），等待编译完成。终端窗口应显示：

linking... Program Size: Code=8240 RO-data=480 RW-data=248 ZI-data=728 ← 总共不到10KB，非常轻量 ".\Project\Objects\STM32F103C8T6.axf" - 0 Error(s), 0 Warning(s).

零错误、零警告，且.hex文件已出现在Simulation/目录下——这一步就算通关。

3.3 Proteus仿真：如何让屏幕真正亮起来？

双击打开Simulation/STM32_LCD_KEY.dsn。你会看到一个简洁电路：左侧是STM32芯片（U1），右侧是LCD1602（U2），中间是4×4键盘（K1）。关键操作三步：

1. 右键点击STM32芯片U1 → Edit Properties；
2. 在弹出窗口中，找到Program File字段，点击右侧文件夹图标，选择刚生成的STM32F103C8T6.hex；
3. 点击左下角Play按钮（绿色三角）——此时，LCD1602屏幕左上角应立刻显示HELLO!，同时下方小字显示KEY: NONE。

如果屏幕全黑：检查.hex路径是否正确、Proteus是否识别到该文件（路径名不能含中文或空格）；
如果显示乱码（如方块、横线）：大概率是LCD初始化时序不对，别急，下一章我们专门调它。

注意：Proteus首次加载可能提示“Missing VSM DLL for STM32F103C8”，这是正常现象。点击“Yes”让Proteus自动下载对应模型（需联网），下载完成后重启Proteus即可。此DLL仅用于仿真，不涉及任何实际硬件驱动。

4. 第一个例子：让LCD显示你按下的键值（从“HELLO!”到“KEY: 5”）

4.1 理解主循环逻辑：三行代码，撑起整个交互

打开Project/USER/main.c，找到main()函数末尾的主循环：

while(1) { key_val = KEY_Scan(); // ① 扫描键盘，返回键值（0~15）或0xFF（无按键） if(key_val != 0xFF) // ② 如果有按键按下 { LCD_Clear(); // ③ 清屏 LCD_Write_String(0, 0, "KEY: "); // 在第0行第0列写"KEY: " LCD_Write_Char(0, 5, '0' + key_val); // 在第0行第5列写对应数字字符（0→'0', 1→'1'...） } }

这就是全部核心逻辑。我们逐行拆解：

• KEY_Scan()：调用key4x4.c里的函数，它内部执行“行扫描+列检测+10ms软件延时去抖”，最终返回0~15（对应键盘0~F）或0xFF（无按键）。它不依赖中断，纯靠CPU轮询，所以你能在Keil里单步调试，亲眼看到key_val怎么从0xFF变成5；
• LCD_Clear()：发送清屏指令（0x01）给LCD，让屏幕回归初始状态；
• LCD_Write_String(0, 0, "KEY: ")：0,0表示第0行（0~1）、第0列（0~15），字符串从那里开始写；
• LCD_Write_Char(0, 5, '0' + key_val)：这里有个小技巧——ASCII码中'0'是48，'1'是49，所以'0'+5就是53，即字符'5'。这样就避免了写一堆if(key_val==5) LCD_Write_Char(...'5'...)的冗余判断。

4.2 动手改代码：把“KEY: 5”变成“PRESSED: A”

现在，我们让显示更直观。找到main.c中写字符的那行，替换成：

// 原代码（注释掉） // LCD_Write_Char(0, 5, '0' + key_val); // 新代码：用字符数组映射键值 char key_chars[] = {'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'}; LCD_Write_Char(0, 5, key_chars[key_val]); // 直接取对应字符

保存，重新编译（Keil里点F7），等待.hex更新。回到Proteus，点击Stop（红色方块）→ 再点Play。现在，按下键盘第一行第四个键（标着‘3’的那个），屏幕会显示KEY: 3；按下第三行第一个键（标着‘A’），显示KEY: A。你改的只是两行代码，但效果立竿见影——这就是模板的价值：修改成本极低，反馈速度极快。

4.3 深挖一行：LCD_Write_Char是怎么把一个字符送到屏幕的？

打开lcd1602.c，找到该函数：

void LCD_Write_Char(uint8_t row, uint8_t col, uint8_t data) { uint8_t address; if(row == 0) address = 0x00 + col; // 第0行地址偏移：0x00 ~ 0x0F else address = 0x40 + col; // 第1行地址偏移：0x40 ~ 0x4F LCD_Write_Cmd(0x80 | address); // 发送“设置DDRAM地址”指令（0x80 | 地址） LCD_Write_Data(data); // 发送要显示的ASCII码数据 }

关键点解释：

• LCD1602内部有两块显示内存（DDRAM），第0行地址是0x00~0x0F，第1行是0x40~0x4F。0x80 | address就是告诉LCD：“接下来我要往这个地址写数据”；
• LCD_Write_Data(data)才是真正把data（比如'A'的ASCII码65）写入DDRAM；
• 这个过程需要严格时序：先拉低RS（选数据寄存器）、RW（写模式）、再给E一个高脉冲（≥450ns）。这些细节，LCD_Write_Data()函数里已用Delay_us(1)和IO翻转实现，你不用操心——但要知道，Proteus里那个“E引脚的窄脉冲”，就是这一行代码的物理体现。

5. 避坑指南：新手必踩的5个坑，以及怎么一眼看出问题在哪

5.1 现象：Proteus里LCD全黑，或显示两行方块（■■■■）

→ 原因：LCD初始化失败。最常见是LCD_Init()函数里，LCD_Write_Cmd(0x28)（设置4位模式）之后，少了一个关键延时。LCD刚上电需要至少15ms稳定时间，而Delay_ms(15)必须放在LCD_GPIO_Init()之后、第一条指令之前。
→ 解决：打开lcd1602.c，找到LCD_Init()开头，确认是否有：

Delay_ms(15); // 必须！上电延时 LCD_Write_Cmd(0x28); // 4位数据，2行显示，5×7点阵

如果删掉了这行，补上再编译。Proteus里按Stop→Play重试。

5.2 现象：按键按下，屏幕显示KEY:后面永远是乱码（如@、[）

→ 原因：KEY_Scan()返回的key_val超出了0~15范围，却直接当数组下标用了。比如key_val是255（0xFF），key_chars[255]就访问了非法内存，读到随机值。
→ 解决：在main.c里加保护：

if(key_val != 0xFF && key_val <= 15) { // 严格限定范围 LCD_Write_Char(0, 5, key_chars[key_val]); } else { LCD_Write_Char(0, 5, '?'); // 显示问号提示异常 }

5.3 现象：Proteus里按键能响应，但按一次显示多次（如按‘1’显示KEY: 1111）

→ 原因：键盘硬件去抖没做好。KEY_Scan()函数里虽有Delay_ms(10)，但如果主循环太快（比如没加Delay_ms(50)），就会在一次按键按下期间反复扫描，每次扫到都算一次有效键。
→ 解决：在main.c主循环末尾加延时：

while(1) { key_val = KEY_Scan(); if(key_val != 0xFF) { // ... 显示逻辑 } Delay_ms(50); // 强制每次循环间隔50ms，避开抖动期 }

5.4 现象：Keil编译报错undefined symbol GPIO_SetBits

→ 原因：Keil工程里没添加stm32f10x_gpio.c到编译列表。虽然头文件stm32f10x_gpio.h已包含，但源文件没参与编译，链接器找不到函数实现。
→ 解决：在Keil左侧Project窗口，右键Source Group 1→Add Existing Files to Group...→ 选择Project/STM32F10x_FWLib/src/stm32f10x_gpio.c→ 确认。同理检查stm32f10x_rcc.c是否已添加。

5.5 现象：Proteus里LCD显示正常，但按键完全无反应（始终KEY: NONE）

→ 原因：4×4键盘在Proteus中的模型引脚定义与实物不符。某些版本Proteus的KEYPAD-4X4元件，其行/列引脚顺序是反的（比如标着“ROW0”的引脚实际连的是列线）。
→ 解决：双击键盘元件K1 →Edit Properties→ 查看Pin Mapping。标准接法应为：

• 行线（Row0~Row3）接STM32的PA0~PA3（输出）
• 列线（Col0~Col3）接STM32的PA4~PA7（输入上拉）
  如果发现Row0对应引脚是A4，说明模型错了。此时直接删除K1，从元件库重新拖一个KEYPAD-4X4（确保属性里Model显示KEYPAD-4X4而非KEYPAD-4X4-ALT），再按标准接线重连。

提示：所有避坑方案，都在模板的Docs/README.md里有对应章节编号（如“坑#1”），遇到问题先查它，比百度快十倍。

6. 下一步学什么？从“能跑”到“能改”的三步跃迁路径

6.1 路径一：加一个功能——让LCD第二行显示按键次数

你现在只能显示当前键值，但无法记录“按了多少次”。这是嵌入式里最基础的状态管理需求。动手做：

1. 在main.c顶部定义全局变量：

   uint16_t key_press_count = 0; // 按键总次数

2. 在main()循环里，当检测到有效按键时：

   if(key_val != 0xFF && key_val <= 15) { key_press_count++; // 每次有效按键+1 // ... 原来的显示逻辑 LCD_Write_String(1, 0, "COUNT:"); // 第1行写"COUNT:" LCD_Write_Number(1, 7, key_press_count); // 自定义函数：在第1行第7列写数字 }

3. 实现LCD_Write_Number（参考lcd1602.c里已有的LCD_Write_Char）：

   void LCD_Write_Number(uint8_t row, uint8_t col, uint16_t num) { char buf[6]; // 最大65535，5位数+结束符 sprintf(buf, "%d", num); // 格式化为字符串 LCD_Write_String(row, col, buf); }

   注意：需在lcd1602.c顶部加#include <stdio.h>，并在Keil的Options for Target → C/C++ → Define里添加USE_STDPERIPH_DRIVER（否则sprintf可能不工作）。

完成这一步，你就掌握了状态变量 + 字符串格式化 + 多行显示三个实战技能。下次再加“时间戳”或“历史记录”，思路完全一样。

6.2 路径二：换一种扫描方式——从查询法升级到外部中断

当前KEY_Scan()靠主循环不断轮询，浪费CPU。真实产品中，我们会用外部中断（EXTI）：把键盘的某一根列线接到STM32的EXTI0引脚，当该列有按键按下（电平变低），硬件自动触发中断，CPU立刻跳去执行KEY_IRQHandler()。这样主循环可以去干别的事（比如采集传感器数据），按键响应还更快。
怎么做？

• 硬件上：将键盘的Col0（接PA4）改接到PA0（即EXTI0通道）；
• 软件上：在key4x4.c里写中断服务函数：

  void EXTI0_IRQHandler(void) { if(EXTI_GetITStatus(EXTI_Line0) != RESET) { key_val = KEY_Scan_Once(); // 只扫描一次，非轮询 EXTI_ClearITPendingBit(EXTI_Line0); // 清中断标志 } }

  然后在main()里初始化EXTI：配置PA0为输入、下降沿触发、使能中断。

  这步会逼你搞懂NVIC中断优先级、EXTI线路映射、中断清除机制——全是面试高频考点。但别怕，模板的Docs/里有《EXTI快速接入指南》，照着填5个寄存器就通。

6.3 路径三：迁移到真实硬件——从Proteus到ST-Link下载

当你在Proteus里调通所有功能，下一步就是“真机验证”。这时你会发现：Proteus里完美的延时，在真实芯片上可能快10倍（因为晶振精度、温度影响）。怎么办？

• 第一步：用ST-Link Utility软件，把.hex文件直接烧录到开发板（无需Keil）；
• 第二步：把Delay_ms()函数里的for循环参数，从Proteus仿真的值，调整为实测值。比如原来for(i=0;i<10000;i++)延时1ms，实测只有0.8ms，就改成i<12500；
• 第三步：用万用表测PA0引脚电压，确认按键按下时确实是0V（不是3.3V浮空），排除上拉电阻没焊的问题。

从Proteus到真机，最大的教训不是技术，而是习惯：我从那以后，每次写完一个驱动，都强制在Proteus里用逻辑分析仪抓三次波形——第一次看时序对不对，第二次看电平稳不稳，第三次看中断触发点准不准。哪怕多花五分钟，也比上电后对着黑屏发呆两小时强。

希望帮到你。

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