企业官网建设流程全解析

简介：面向正在准备STM32微控制器毕业设计的嵌入式方向学生，这套资源覆盖硬件电路设计到软件调试的完整路径，帮助初学者快速掌握STM32开发环境搭建、代码编写与程序烧录流程。包内共26个文件，压缩后约8.09MB，目录按模块划分，包含keil工程源码（uvproj、c、hex）、原理图与PCB设计文件（SchDoc/PcbDoc）、元件清单表、参考论文，以及操作视频指引文档，便于对照学习。已有7334人浏览学习，是同类资料中较受关注的资源。通过研读源码可理解寄存器配置、中断机制与库函数调用，借助原理图与PCB可学习电路设计规则及外设交互方式，参考论文则有助于把握低功耗与RTOS等应用方向，这份集合为从理论学习到实际制作提供了清晰路径。

1. stm32 毕业设计合集：从源码到论文的完整链路，先跑起来再改

A 同学拿到这份合集时，连 CubeMX 都还没装好。他花了两个晚上把一个环境监测项目的源码烧进板子，然后只改了 main.c 里的温湿度阈值和 OLED 上显示的标题文字，就交上了能现场演示的初版毕设。这就是这份 stm32 毕业设计合集的价值：它把多个完整可跑的项目源码和相关资料放在一起，拿到手不是逐个看代码，而是先选一个和你的板子匹配的工程，让它跑起来，再基于它做属于自己的改动。适合手里有板子但工程总是建不明白的同学，也适合想从完整项目里快速学会外设驱动写法的开发者。

2. 合集包全景：六个项目按芯片、外设和资料完整度怎么挑

2.1 项目列表：从环境监测到智能小车的覆盖面

先看合集里有什么。解压后能看到十几个独立文件夹，每个文件夹对应一个可以单独用 Keil 打开编译的工程。按常见毕设方向大致可以分成六类：环境监测（温湿度采集加 OLED 显示，带继电器和蜂鸣器告警）、智能家居（多传感器采集加继电器控制，预留无线模块接口）、倒车雷达（超声波测距加蜂鸣器频率提示）、智能小车（红外循迹和蓝牙遥控双模式）、指纹门禁（指纹模块识别加舵机开锁，还有密码备选）、简易电子秤（HX711 压力采集加 LCD 显示和去皮按键）。覆盖了绝大多数本科毕设选题的外设组合逻辑。

不同项目用的主控也做了区分，环境监测、智能家居这类偏交互的数据采集类，优先用 STM32F103C8T6，这是国内平时学习最常见的芯片，资料最多；倒车雷达和智能小车考虑到中断和 PWM 输出，也用 F103 系列；指纹门禁因为要挂指纹模块和 OLED，选的是引脚更多的 STM32F103RCT6；如果项目里带着比较重的显示任务，比如电子秤的 LCD 大屏，那套工程里给的是用 FSMC 接口驱动的方案。选型上基本按“外设数量决定引脚数、任务复杂度决定主频”来安排，这是工程里比较合理的选法。

2.2 标准目录长什么样：源码、论文、原理图、PPT 的分工

每个项目文件夹内部结构大体一致，以其中一套环境监测工程为例：

Project_EnvMonitor/ ├── 源码/ │ ├── Core/Inc/ // 头文件：main.h、gpio.h、i2c.h │ ├── Core/Src/ // main.c、gpio.c、i2c.c、usart.c │ ├── Drivers/ // HAL 库驱动与 CMSIS 启动文件 │ ├── MDK-ARM/ // Keil 工程、调试器配置文件 │ └── README.txt // 接线说明和修改提示 ├── 论文/ │ ├── 毕业论文.docx // 章节结构可以直接套用 │ ├── 开题报告.docx │ └── 任务书.docx ├── 原理图/ │ ├── 原理图.pdf // 引脚分配和电源网络在这里核对 │ └── PCB.pdf ├── PPT/ │ ├── 答辩PPT.pptx │ └── 演示视频.mp4 └── 资料/ ├── 芯片数据手册.pdf └── 传感器数据手册.pdf

这个结构里我一般建议先看的不是代码，而是三样东西：README.txt、原理图 PDF 和论文。README 告诉你开发板上的线怎么接，原理图是硬件连接的唯一依据，论文帮你把这套东西如何写进毕业设计搞清楚，这三样对齐之后再看代码，心里就有底。

2.3 挑第一个跑的项目：芯片型号、外设类型、资料完整度

拿到合集别急着从第一个文件夹开始编译，先按三个标准筛一遍。第一，主控芯片是否能和手上的板子对上。手里是 F103C8T6 就选标注了 C8T6 的工程，如果工程用的是 RCT6，引脚数量都不一样，强行移植要改启动文件和链接脚本，对新手来说没必要。第二，外设是否常见、是否容易出问题。OLED、按键、蜂鸣器、继电器这些模块接线简单、驱动成熟，适合第一跑。像 GSM 模块、SIM 卡通信这类，容易因为物联网卡没费、信号不稳定卡住半天，建议放到后期有经验了再碰。第三，资料完整度看有没有原理图 PDF 和论文 Word。一套工程如果只有源码而没有硬件连接说明，跑起来跟猜谜差不多，出了问题也不知道是软件还是硬件。

选项目时还有一个很普遍的经验：把文档里的功能需求和你论文题目对一下，如果项目里已经有 80% 的功能基础，剩下 20% 比如换个传感器或者改个显示界面，恰好是你能动手改出来的。比从零写一个功能少很多坑。合集里每个项目都有这种改基础，这也是我推荐优先把环境监测或智能家居作为第一个项目跑通的原因，它们的传感器、显示、告警三个环节拆得比较干净，适合一步步从看懂到改懂。

3. 拆解一个典型项目：环境监测系统的工程生成与启动流程

这一章拿环境监测示例工程开刀，完整走一遍从工程怎么搭起来到代码怎么跑起来的过程。

3.1 从 CubeMX 到 Keil MDK：工程是怎么生成的

先说明一下工程的来源：这套代码是先用 STM32CubeMX 图形化配置生成的。你在 CubeMX 里选择芯片型号，勾选需要的引脚和外设，比如 I2C1、USART1、一个按键 GPIO、一个蜂鸣器 GPIO，再在时钟树里设好 72MHz 主频，它就能生成一个包含初始化代码的 Keil 工程。生成出来的代码结构是标准 HAL 库风格：Core 目录放 main.c 和初始化函数，Drivers 目录放 HAL 库和 CMSIS。

这里最需要注意的是 CubeMX 在生成代码时留下的用户代码保护区：

/* USER CODE BEGIN Includes */ #include "sht20.h" #include "oled.h" /* USER CODE END Includes */

USER CODE BEGIN 和 USER CODE END 之间的内容，在 CubeMX 重新生成工程时会被保留。写在保护区之外的代码，下次一重新生成就被覆盖掉。这个特性既是保护也是坑：很多人直接在自动生成的初始化函数里加自己的逻辑，后来想加个外设重新生成一次工程，改动全部消失，心态直接崩。我一般会在第一次生成工程后，把所有自己写的功能代码拆分到独立的 sht20.c、oled.c 里，在 main.c 里只留函数调用，这样 CubeMX 怎么重新生成都不影响业务代码。

CubeMX 生成工程之前还要有一个软件环境准备，就是安装对应的芯片固件支持包，也就是常说的固件包插件。没有它你在芯片目录里选不到 F103，这个动作在 CubeMX 的 Help 菜单里加载即可。固件包版本会影响生成代码的 HAL 库版本，如果生成之后换一个不同大版本的固件包重新生成，个别 API 的入参类型会变，遇到这种问题别急着改代码，先看生成出来的头文件版本号。

时钟树配置是另一个容易埋雷的点。典型的 F103 工程里，外部晶振 HSE 是 8MHz，经过 PLL 倍频 9 倍得到 72MHz 主频。这个配置在 CubeMX 里自动算好，但在代码里对应这几行：

RCC_OscInitTypeDef RCC_OscInitStruct = {0}; RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState = RCC_HSE_ON; RCC_OscInitStruct.HSEPredivValue = RCC_HSE_PREDIV_DIV1; RCC_OscInitStruct.PLL.PLLState = RCC_PLLSTATE_ON; RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL9; HAL_RCC_OscConfig(&RCC_OscInitStruct);

参数说明：HSEState 置为 ON 表示打开外部高速晶振；HSEPredivValue 是 HSE 预分频系数，这里 DIV1 表示不分频；PLLSource 选择从 HSE 取信号而不是内部 HSI；PLLMUL 是倍频系数，8MHz 乘以 9 等于 72MHz，也就是 F103 的标准主频。如果把 PLLMUL 从 MUL9 改成 MUL12，主频会跑到 96MHz，超出了数据手册标称的 72MHz 上限，系统可能短暂能跑但串口波特率会莫名其妙偏。如果你的板子实际焊接的是 12MHz 晶振，这里必须同步改成 MUL6，否则整个系统时钟偏差 50%，UART 输出必然乱码，这也是后面避坑章节里串口乱码的根源。

3.2 外设初始化顺序：按键、OLED、I2C 与串口谁先谁后

CubeMX 生成的主函数通常长这样：

int main(void) { HAL_Init(); // 1. 设置系统时基，初始化 Flash 接口 SystemClock_Config(); // 2. 配置 72MHz 主频 MX_GPIO_Init(); // 3. 按键输入、蜂鸣器输出、继电器输出 MX_I2C1_Init(); // 4. I2C1 用于 OLED 和温湿度传感器 MX_USART1_Init(); // 5. 串口 1 用于调试输出 oled_init(); // 6. 清屏并点亮 OLED printf("[BOOT] system start\r\n"); // 7. 串口打印启动信息 while (1) { loop_key_handle(); // 处理按键菜单切换 loop_sensor_update(); // 定时读取温湿度 loop_display_refresh(); // 刷新 OLED 显示内容 loop_alarm_check(); // 检查阈值并控制蜂鸣器/继电器 HAL_Delay(50); // 主循环节拍，50ms } }

这个顺序是有讲究的。HAL_Init 在最前面，它决定了系统 tick 中断的时间基准，后面的 HAL_Delay 全部依赖它。SystemClock_Config 必须在任何外设初始化之前，因为 I2C 和串口的波特率都是基于系统时钟算出来的，时钟没起来就初始化外设，寄存器配置大概率是错的。GPIO 初始化放在 I2C 和串口之前，是因为有些板子的 I2C 引脚在复位后是高阻态，先配成开漏输出并带上拉，能避免总线悬空干扰。

OLED 的初始化放在 HAL_Delay 可用之后也很重要。OLED 模块上电之后需要一个短暂复位时间，主控上电后立刻对 OLED 发送初始化序列，有时候屏幕会因为时序冲突导致白屏，稳妥的做法是在 oled_init 内部先延时 50ms 再开始发送配置命令。这是我踩过坑之后才养成的习惯：所有刚从外部供电的模块，初始化之前都先延时一点等电源稳定。

主循环里的四个 loop 函数，各自承担一个职责。loop_sensor_update 里通过 I2C 读取传感器数据，loop_display_refresh 根据当前模式把数据刷到 OLED，loop_alarm_check 做阈值比较，loop_key_handle 轮询按键状态。50ms 的循环节拍在 OLED 场景下既不会让人眼觉得卡顿，也不会因为频繁刷新而让 I2C 总线过载。如果你改到 20ms 以下，OLED 刷新会出现可见的花屏闪烁，因为整屏写入 1024 字节需要时间，刷新本身比业务周期还长，主循环会失衡。

3.3 第一次烧录：Keil 配置项逐个核对

工程编译通过并不等于能烧录成功，第一次烧录前的配置检查基本能决定你接下来三小时的顺利程度。打开 Keil 的魔术棒选项卡，先看 Debug 这一页，把下拉框从默认的 Simulator 切到 ST-Link Debugger 或 J-Link，如果用的开发板自带 ST-Link 就选 ST-Link，点旁边的 Settings，确认里面读出来的芯片型号和你的开发板一致，并且 Port 选的是 SW 而不是 JTAG。这里选错的话，连接时大概率报 No target connected。

再看 Flash Download 这一页。这里的 Programming Algorithm 必须和芯片容量匹配。STM32F103C8T6 是 64KB Flash 的 medium density 芯片，算法应该选 STM32F10x Med-density；如果工程默认带的是 High-density 512KB，点下载时虽然也能写，但很多时候会卡在校验阶段，下载完一校验就报错。所以这里要手动去除多余的算法，只保留对应的一项。

最后还需要在 Output 页勾选 Create HEX File，这样每次编译会在工程目录生成 hex 文件，方便串口下载软件做备用烧录方式。整个下载流程中常见的报错有几种：有的板子 BOOT0 跳线帽被拨到 1，芯片每次上电都进入系统加载器而不是应用 Flash，SWD 调试器会连不上；有的板子复位电路设计得比较敏感，下载时总是失败，解决办法是先按住复位，点下载瞬间松手，或者用调试器的复位引脚连接到板子的复位信号，让调试器控制复位时序。这一套检查完再烧录，基本能避开“为什么点不了下载”这种新手期体验。

4. 核心代码走读：传感器读取、OLED 刷新与告警联动的实现

这一章把上一章主循环里的三个核心函数拆开讲，可以直接抄进自己的项目。

4.1 I2C 读取 SHT20 温湿度：测量命令、数据拼接与公式换算

环境监测项目里最核心的数据来源是 I2C 接口的 SHT20 温湿度传感器。读取它的流程分三步：发送测量命令，等待测量完成，然后读取 3 个字节的数据，其中前两个字节是 16 位原始值，第三个字节是 CRC，代码里一般忽略 CRC 校验直接取前两个字节。核心函数长这样：

// sht20.c - 读取温湿度 // SHT20 的 7 位 I2C 地址是 0x40，HAL 库要求传入 8 位地址，所以左移一位 #define SHT20_ADDR (0x40 << 1) #define SHT20_CMD_TEMP 0xF3 #define SHT20_CMD_HUMI 0xF5 uint8_t sht20_read(float *temp, float *humi) { uint8_t cmd = SHT20_CMD_TEMP; // 1. 触发温度测量 HAL_I2C_Master_Transmit(&hi2c1, SHT20_ADDR, &cmd, 1, 200); HAL_Delay(100); // 温度最大测量时间 85ms，留 100ms 余量 // 2. 读取 3 字节：高位、低位、CRC uint8_t buf[3] = {0}; HAL_I2C_Master_Receive(&hi2c1, SHT20_ADDR | 0x01, buf, 3, 200); // 3. 拼接 16 位原始值并按数据手册公式换算 uint16_t raw = (buf[0] << 8) | buf[1]; *temp = -46.85f + 175.72f * raw / 65536.0f; // 4. 同样的流程测量湿度 cmd = SHT20_CMD_HUMI; HAL_I2C_Master_Transmit(&hi2c1, SHT20_ADDR, &cmd, 1, 200); HAL_Delay(50); // 湿度最大测量时间 30ms，留 50ms 余量 HAL_I2C_Master_Receive(&hi2c1, SHT20_ADDR | 0x01, buf, 3, 200); raw = (buf[0] << 8) | buf[1]; *humi = -6.0f + 125.0f * raw / 65536.0f; return 0; }

这里有几个关键点要展开。第一，地址为什么要移位：HAL 库的 I2C 函数要求传入的是 8 位地址格式，也就是把 7 位设备地址左移一位，最低位用于区分读写方向，所以发送用 0x40<<1，接收用 0x40<<1 再或上 0x01。如果你在其他地方看到的驱动里直接写 0x80、0x81，那也是一样的道理。第二，延时时间不是随便给的，SHT20 的温度测量典型时间在 85ms 以内，湿度在 30ms 以内，延时不足会读到上一轮残留的数据，表现为温湿度值变化迟钝甚至跳变。第三，raw 拼接那里要看清楚字节序，先读到的高字节要左移 8 位，不能反过来拼，否则数据完全是乱码级别的偏差。

公式换算用的是数据手册里给出的标准线性关系：温度是 -46.85 加 175.72 乘以 raw 除以 65536，湿度是 -6.0 加 125.0 乘以 raw 除以 65536。你在自己写驱动时可能看到别的传感器公式，比如 DHT11 是用整数查表加小数估计，方法完全不同，所以换传感器时公式一定要同步换掉。这段代码里我特意没有做 CRC 校验，实际产品可能要加，毕设演示场景下偶尔的校验失败不会影响效果，但如果读取多次都是同一个明显错误的值，先去检查接线和地址，不要怀疑代码公式。

4.2 OLED 刷新策略：整屏缓冲与局部刷新的取舍

OLED 屏幕这块，项目里用的是常见的 128x64 SSD1306 驱动。SSD1306 的内部显存是 128x64 位，也就是 1024 个字节的缓冲区，每个字节控制一列上的 8 个像素。工程里常见的做法是维护一块同样大小的内存缓冲 oled_buf，业务代码往内存里写，最后统一刷到屏幕：

// oled.c - 整屏刷新 void oled_refresh(void) { uint8_t page, col; for (page = 0; page < 8; page++) { OLED_WR_CMD(0xB0 + page); // 设置页地址，范围 0x00~0x07 OLED_WR_CMD(0x00); // 列地址低 4 位清零 OLED_WR_CMD(0x10); // 列地址高 4 位清零 for (col = 0; col < 128; col++) { OLED_WR_DATA(oled_buf[page * 128 + col]); } } }

这个刷新函数里，页地址 0xB0 到 0xB7 对应屏幕从上到下的 8 个页，每页 8 个像素高。OLED_WR_CMD 是带 RS 引脚电平判断的命令写入宏，OLED_WR_DATA 是数据写入宏，在很多 SSD1306 驱动代码里都有类似定义。整屏刷新一次要连续写 1024 个数据字节，对 I2C 接口来说会占用几个毫秒的通信时间，所以刷新频率不能过高，这也是主循环节拍设为 50ms 的原因之一。

整屏缓冲的好处是绘制逻辑简单，想画什么就直接改 buffer 里的位，最后统一刷新，不会有撕裂感。但如果你做一个从左往右跑的进度条动画，每次移动一列都整屏刷新，整个画面会看到明显的闪烁。我一般会为这种场景加一个局部刷新函数：先记录上一帧的起点页和列，把清除和重绘限定在几页几列里，其余区域不写。OLED 的写入是按页列坐标点写的，你甚至可以把进度条两侧之外的屏幕区域当成静止画面完全不去触碰它。毕设演示时如果评委注意力放在动画效果上，局部刷新这个细节会明显提升整体完成度。

4.3 阈值告警：继电器与蜂鸣器的防抖动联动

环境监测系统的告警逻辑不复杂，但参考代码里用了一个小技巧，值得展开说明。先把阈值判断和硬件动作分成两层：

// alarm.c - 阈值告警与继电器联动 #define RELAY_ON() HAL_GPIO_WritePin(RELAY_GPIO_Port, RELAY_Pin, GPIO_PIN_SET) #define RELAY_OFF() HAL_GPIO_WritePin(RELAY_GPIO_Port, RELAY_Pin, GPIO_PIN_RESET) #define BEEP_ON() HAL_GPIO_WritePin(BEEP_GPIO_Port, BEEP_Pin, GPIO_PIN_SET) #define BEEP_OFF() HAL_GPIO_WritePin(BEEP_GPIO_Port, BEEP_Pin, GPIO_PIN_RESET) void alarm_check(float temp, float humi) { // 任一条件越界则触发告警 uint8_t alarm = (temp > 30.0f) || (temp < 18.0f) || (humi > 80.0f); static uint8_t last_alarm = 0; if (alarm && !last_alarm) { RELAY_ON(); // 打开继电器，可用于控制风扇或加热器 BEEP_ON(); // 蜂鸣器拉响 last_alarm = 1; printf("[ALARM] temp=%.1f humi=%.1f\r\n", temp, humi); } else if (!alarm && last_alarm) { RELAY_OFF(); BEEP_OFF(); last_alarm = 0; printf("[INFO] alarm cleared\r\n"); } }

这个写法里最重要的不是阈值判断本身，而是 static 变量 last_alarm 的使用。它记录的是上一次的告警状态，只有状态发生边沿变化时才改变 IO 输出。你可能会问：为什么不每次循环都直接 if (alarm) 就开、else 就关？因为如果项目里驱动的是继电器，频繁在临界值附近抖动会导致继电器触点不断吸合释放，电气寿命会快速消耗，试想温度在 29.9 和 30.1 之间来回波动时，继电器会疯狂咔哒响。加上 last_alarm 相当于给告警加了一个软件层面上的变化检测，只有真正越过阈值那一次才动作。

我还想提醒一点：蜂鸣器如果是 5V 有源蜂鸣器，用一个三极管驱动比较稳妥，GPIO 推挽输出直接接蜂鸣器容易出现电流不足驱动不响或者反向感应电压损坏引脚的情况。继电器线圈也必须经过三极管或 ULN2003 驱动，不能由 MCU 引脚直驱。原理图 PDF 里通常画出了这部分驱动电路，跑工程之前建议先核对一下继电器驱动引脚有没有和传感器共用，曾经见过一个项目把继电器引脚设成和 I2C 时钟复用，跑起来之后传感器读取时断时续，排查了半小时才发现问题出在引脚复用上。

4.4 串口调试口：printf 重定向到串口与 MicroLIB

项目里几乎每个工程都开了串口调试输出，代码实现的套路是把标准库的 fputc 重定向到 USART 发送函数。有了这层，调试时就能直接用 printf 打印传感器值、告警状态和系统运行时长，不用打断点浪费时间：

// 重定向 printf 到串口1 // Keil 工程必须勾选 Use MicroLIB，否则标准库版 printf 会卡在半主机模式 #include <stdio.h> int fputc(int ch, FILE *f) { (void)f; HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }

这里有两个参数需要解释。HAL_UART_Transmit 的第四个参数是超时时间，单位是毫秒，0xFFFF 是十六进制的 65535，表示接近无限等待，这样打印速度慢时不会因为超时中断掉输出。如果写成 100，在高速持续打印大段日志时，偶尔会因为总线阻塞导致发送失败，日志就丢了。(void)f 那行是告诉编译器 f 参数我们用不上，避免编译警告，这在嵌入式代码里是个常见习惯。

关于 MicroLIB，这是 Keil 自带的一个精简版 C 运行库。标准库的 printf 默认支持半主机模式，也就是 printf 会尝试通过一个调试通道把字符发到上位机，这在单片机上会导致程序停在 BKPT 指令上，表现为代码跑到 printf 之后就不再执行任何东西。勾选 MicroLIB 之后 printf 不再走半主机，而是在我们重定向的 fputc 里工作，这是 stm32 调试串口最常见的一套配置。如果你换到 IAR 或 GCC 环境，处理方式不同，IAR 里用 __write 重定向，GCC 用 _write 系统调用，原理一样，细节不一样。

5. stm32 毕设避坑记录：烧录、乱码、白屏和 ADC 采样的排查思路

写代码只是毕设的一部分，把工程从别人手里搬到你自己板子的过程才是最容易翻车的阶段。这里记录四条我实际见过的踩坑经历，每一条都按现象、原因、解决来写，遇到同类问题可以照着定位。

5.1 烧录失败 No target connected：先量电源再查 BOOT0

现象：Keil 点 Download 弹出 No target connected 或者 Error: Flash Download failed，有时甚至打开调试器的一瞬间就报找不到设备。原因按概率排序是这样：目标板压根没进调试模式，常见是 BOOT0 跳线帽被拨到 1，芯片每次复位都进入引导加载程序而不是用户 Flash，SWD 引脚此时不响应调试器；其次是电源问题，开发板外部供电了但调试器没给目标板供电，两边地没共地，SWD 信号没有参考电平；再往下是驱动问题，调试器插入电脑后设备管理器里显示黄色感叹号，大多是电脑装过其他调试器驱动，两个驱动打架。解决步骤：先量目标板 VCC 和 GND 之间是否有稳定的 3.3V，再确认 BOOT0 是低电平，最后拔插一次调试器看设备管理器状态。如果还是连不上，把调试器和板子之间的杜邦线全部换掉，SWD 线里最容易松的是时钟线，因为调试器是时钟同步工作的，时钟线接触不良的表现就是时好时坏，偶尔能连上但一下载就断。从那以后我每次换板子都先拧紧接线端子再上电。

5.2 串口打印乱码：HSE_VALUE 与板载晶振不一致

现象：printf 输出到串口助手，显示的是一堆菱形问号，偶尔能看到几个英文字母。原因：串口波特率和实际时钟不匹配。代码里默认外部晶振是 8MHz，但某些开发板为了节省成本焊的是一颗 12MHz 晶振。系统时钟按 8MHz 算出来是 72MHz，实际却是 108MHz，串口外设按这个错误总线时钟去分频波特率，收发双方频率对不上，自然乱码。解决：看板子背面晶振丝印，标着 8.000 的就保持默认，标着 12.000 的就把 HSE_VALUE 宏改成 12000000，并且把 PLL 倍频系数从 9 改成 6，让主频回到 72MHz。判断的时候有一个实用技巧：把串口助手波特率从 115200 改成 9600 试试，如果乱码情况明显变化，基本可以确定不是串口助手的问题而是系统时钟，因为波特率偏移是成比例的。反过来，如果 115200 下完全正常，说明时钟配置和晶振是匹配的，接下来再怀疑杜邦线干扰等物理因素。

5.3 OLED 白屏或花屏：I2C 地址、上拉电阻与总线速度

现象：OLED 屏幕不显示任何内容，背光亮但全白，或者每次刷新时闪一下显示又消失。原因通常是三个里挑一个：I2C 地址写错，SSD1306 在 0.96 寸 OLED 模块上默认地址是 0x3C，但有的模块背面有地址选择电阻，改过之后变成 0x3D，代码里写死 0x3C 就会导致所有命令都发给了错误的设备；第二个原因是 I2C 总线上没有上拉电阻，部分最小系统板的 I2C 引脚没有接外部上拉，STM32 内部的上拉驱动能力很弱，总线信号上升沿过慢，通信不稳定；第三个原因是飞线太长，I2C 在杜邦线超过 15cm 时会出现波形失真，SSD1306 对时序要求比普通 EEPROM 严格，波形差一点就不应答。解决：先抓 SDA 和 SCL 两根线，确认应答位是低电平，如果一直为高说明地址不对或总线上根本没有设备上电；再把屏幕模块上的地址电阻补焊好，让它回到 0x3C；最后把 I2C 时钟从 400kHz 降到 100kHz，软件里改一下 I2C_InitStruct 的 ClockSpeed 字段即可。OLED 这种显示外设对速率不敏感，降低频率换来稳定，非常划算。

5.4 ADC 采样值到不了满量程：参考电压与采样周期

现象：用滑动变阻器分压给 ADC 采集，把电压调到接近 3.3V，读到的值却停在一个很低的数字，或者最大值是 2047 而不是 4095。原因：一是采样时间太短，STM32 的 ADC 内部采样电容没有充满电就开始转换，高速采样时高阻信号源特别明显，读出来的值会偏低且波动；二是参考电压问题，某些板子的 VREF+ 引脚没有直接连接 VDD，而是通过跳线帽选择外部基准源，跳线帽没插时 ADC 参考电压缺失，读数的满量程对应关系就乱了；三是部分工程在初始化 ADC 时把分辨率配置错了，F103 的 ADC 是 12 位，如果把数据寄存器不小心配成了 10 位或 8 位格式，最大值就会变成 1023 或 255。解决：把 ADC 的采样时间设置为最大档，比如 239.5 周期或 479.5 周期，再重新生成代码，同时检查板子原理图确认 VREF+ 引脚有电。如果项目要求连续采样，比如采集一个动态波形，只靠软件读会很吃力，要改成 ADC 加 DMA 模式，让硬件把数据搬运到内存数组，主循环直接取平均值。DMA 在这里不是高级用法，而是处理 ADC 数据最基本的姿势，毕设里只要涉及音频或光照波形分析，都用得上。

6. 二次开发思路：把合集项目改造成你自己的毕业设计

最后一章说怎么把别人的工程变成“你自己”的项目，不只是换一个名字那么简单。顺着下面的思路改，论文里的系统设计部分也能跟着写清楚。

6.1 换传感器与换屏幕：驱动文件的替换点

想把环境监测改成植物养护系统，思路是保留原有的 OLED、按键、告警框架，只替换温湿度传感器为土壤湿度探头，再加一个光照传感器。替换传感器时关注三个地方：初始化函数、读取函数、换算公式。比如土壤湿度模块是模拟输出，那就把 I2C 读取的部分换成 ADC 采集加滑动平均值；数据变化频率不高，主循环里 500ms 读一次都行。换屏幕时优先选分辨率一致或者驱动芯片一致的型号，如果换成 1.3 寸 OLED 或 TFT 彩屏，显示驱动文件的接口要重新实现，但只要上层显示接口做得干净，主逻辑的改动并不会伤筋动骨。

6.2 把按键菜单改造成手机 App 控制：串口透传接入点

合集里的按键逻辑是轮询式，每次循环读 GPIO 判断电平。想改成手机 App 控制的话，物理按键保留作为本地备用，另外引入串口命令解析层。蓝牙模块透传的字符串到达串口中断后，放进一个环形缓冲区，主循环空闲时解析。这样一个简单解析函数就能衔接两种输入方式：

// cmd.c - 串口命令解析 // 用法：蓝牙透传 "MODE" 即切换显示模式，等同按键按下 void uart_cmd_parse(char *cmd) { if (strstr(cmd, "MODE")) { display_mode = (display_mode + 1) % 3; } else if (strstr(cmd, "SET_HIGH")) { temp_upper = 35.0f; // 把高温阈值临时调高 } else if (strstr(cmd, "RELAY_TOGGLE")) { relay_toggle(); } }

这段代码的关键是 strstr 匹配而不是精确相等，因为蓝牙透传的数据末尾可能有回车换行或者多余字符，用子串匹配可以忽略这些干扰。解析函数只做逻辑层的事情，硬件动作仍然调用告警模块里的函数，这样无论输入来源是按键还是手机，行为都一样。如果你的毕设题目是“基于 stm32 的远程环境监控系统”，这个改动基本就是核心功能。

6.3 每改一步强制复跑一遍，记录到底动了什么

二次开发最容易失控的点不是改代码，而是改完不验证。拿到合集后我的习惯是：先在原工程上编译烧录一遍，确认开发板和工程是匹配的；然后每次只改一个驱动文件或一个功能文件，烧录后跑一遍相关功能；最后才做界面和文案的改动。每改一次，在工程根目录新建一个 CHANGE.log 文本文件记录一行，例如“把 SHT20 替换成 ADC 土壤湿度采集”。听起来繁琐，但到交论文前，你要向老师解释系统设计时，这个日志就是最可靠的依据，能精确说出哪些功能是自己动手改的。这套流程看着笨，实际能帮你省掉大量回退重查的冤枉路。我以前做项目时习惯先把所有代码一次性重写完再烧录，结果每次都是连环翻车，从那以后我拿到任何别人的工程，都强制自己先原样跑一遍，再开始动手改，一次只动一个文件。希望帮到你。

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