企业官网建设流程全解析

第六篇了。去年开这个“基于STM32的嵌入式C++编程之旅”系列的时候，我立了个flag：六篇带着大家把STM32从点灯玩到能跑完整项目。现在真写到第六篇，我也得说实话——前面五篇把GPIO、串口、中断、时钟、定时器这些基本功都过了一遍，C++的封装、继承、模板也挨个试过，但你要是现在扔给我一个完整的嵌入式项目，比如一个带温度采集、设备控制和数据上报的控制器，我依然不敢说“稳了”。“哟哟哟，咱们还差活滴”这句标题我不是随便起的，是这几篇写下来最真实的感受：会跑例程和能干活之间，还隔着好大一段路，这篇就想把这段路上最容易被忽略的部分补一补。适合已经跑通过几个STM32小实验、正准备做完整项目或者毕业设计的朋友，也适合想知道“嵌入式C++到底怎么用才不算白学”的人。

1. 第六篇的定位：基础跑通之后，真正的差距在哪儿

1.1 教程逻辑和工程逻辑是两回事

先回忆一个我自己的例子。三年前我刚开始正经玩STM32的时候，跟着教程点亮LED、跑通串口打印、用DHT11读一次温湿度，每一项都很顺利。我当时觉得嵌入式也不过如此，于是兴冲冲去接了一个“智能鱼缸”的小项目：一个水温传感器、一根加热棒、一个气泵、一盏能调光的灯。需求很简单，水温低于22度开加热，高于26度停加热，气泵每开30分钟停10分钟，灯白天亮晚上灭。

结果呢？我把DHT11的例程、LED呼吸灯的例程、按键中断的例程，一个个复制粘贴到main.c里，然后开始改。改到第三天我崩溃了——本来单独跑得好好的代码，拼在一起之后：传感器读着读着就卡住，加热棒动作的日志全混在按键处理里，气泵的状态和灯的状态互相干扰。最后我花了两天才把main.c里的逻辑梳理清楚，发现真正的问题不是“外设不会用”，而是代码的组织方式。

这就是教程逻辑和工程逻辑的区别。教程的逻辑是“一次只讲一个外设”，而真实的嵌入式工程是“一堆外设在互相配合的约束下运行”。你在教程里学到的每个外设，只是一个个乐高零件，把它们拼成一台能跑的机器，靠的是架构和分工。这部分在绝大多数STM32教程里是被跳过的，因为它不性感、不好讲、也不容易出效果。

1.2 “嵌入式C++”不等于“C语言加个类”

再往深一层说，很多转C++的嵌入式开发者，容易陷入一个误区：把struct改成class、把函数改成成员函数，就觉得“我在写嵌入式C++”了。然后代码走了几遍发现，除了语法变了一点，没有任何收益，于是得出一个结论——嵌入式里C++就是个噱头。

我当年也这么想过，直到我把一个设备驱动从“函数集合”重构为“带状态的类”之后，才发现C++对嵌入式真正的价值不止是语法糖。它最有用的东西其实是这么几样：一是RAII，让资源（比如某个定时器通道）在对象构造时申请、析构时释放，出错也不会丢；二是状态封装，把“这个传感器现在处于什么阶段、下一步该做什么”藏进类的内部，外部只看到一个read()接口；三是编译期计算，把查表、算参数这些工作从运行时搬到编译期，省RAM还省时间。

当然，嵌入式C++是有约束的C++，跟PC上的C++完全是两套玩法。不开异常、不开RTTI、不用new和delete，这些规矩我在后面会专门展开。这一篇我打算用五章，先把工程组织讲清楚，再给出实际用过的嵌入式C++代码，然后补上调试和定时器这两个“干活的硬通货”，最后聊聊毕业设计和面试的现实问题。

2. 能干活的第一步：把工程拆成模块，而不是把代码堆进main.c

2.1 三层结构：BSP、驱动、业务，依赖只准往下走

我自己后来整理代码，一直用的是这么一个大原则：把工程分成三层——板级支持包（BSP）、设备驱动（Driver）、业务逻辑（App），而且依赖方向严格向下。BSP只管“这个芯片上有什么”，比如时钟初始化、引脚复用、串口和定时器的底层配置；Driver管“某个外设怎么用”，比如DS18B20的时序、HC-SR04的测量流程；App管“我要拿这些设备干什么”，比如鱼缸的恒温策略、气泵的启停节奏。App可以调用Driver和BSP，Driver可以调用BSP，但Driver和BSP绝对不能反过来知道App的存在。

这个分层之所以重要，是因为嵌入式项目里“改需求”是家常便饭。今天传感器换了个型号，明天控制逻辑加一条规则，如果模块耦合在一起，任何一个小改动都会引起连锁反应。我最初把所有逻辑堆在main.c的时候，改一个温度阈值要全局搜索三处“22”；分层之后，阈值是App层的一个宏或一个变量，驱动层压根就不关心温度是多少。

用鱼缸这个例子来说，模块拆出来大概是这样的：

• bsp_clk.c / bsp_uart.c / bsp_tim.c：管时钟、串口、定时器这些板级资源
• drv_temp.c：负责DS18B20或NTC的时序读写，向上层提供一个干净的float read_temperature(void)接口
• drv_ultrasonic.c：管超声波测距，提供uint16_t get_distance_cm(void)
• drv_heater.c / drv_pump.c / drv_led_pwm.c：各管各的执行器，接口就是on()、off()、set_brightness()这种
• app_fish_tank.c：把所有外围设备的输出组合成控制逻辑，就是这个项目的“大脑”

在C++里，Driver层基本就是一个个类，App层是更高一级的控制器，main函数里只做初始化和启动主循环。这样分完以后，你会发现每个文件都很短、接口都很明确，调试的时候不用在1000行的大文件里翻半天。

2.2 头文件治理：.h放接口，实现细节藏起来

分好层之后，紧接着第二个坑就是头文件。我见过太多新手工程，.h文件里面所有的全局变量都extern一遍，所有的函数都声明一遍，几乎成了“头文件目录大全”。这么做的后果是：一旦变量名改一个字母，全工程编译报错一片；并且读代码的人根本分不清楚哪些是公共接口、哪些是内部实现细节。

我的习惯是这样的：.h文件里只放外部需要的接口——类的公开成员函数、必要的类型定义、常量。凡是只在一个.c里用到的函数和变量，一律用static藏起来，或者放进类里作为private成员。这样编译器在链接的时候也不会把一堆全局符号暴露出来，改内部实现的时候，外部文件根本不需要重新编译。

举个最简单的例子。一个超声波驱动模块，如果按“好头文件”来写，应该是：

// drv_ultrasonic.h #pragma once #include <cstdint> namespace drv { class Ultrasonic { public: Ultrasonic(void* trig_port, uint16_t trig_pin, void* echo_tim, uint32_t echo_ch); void init(); uint16_t measure_cm(); // 阻塞测距，返回单位cm private: void send_trig_pulse(); void* trig_port_; uint16_t trig_pin_; void* echo_tim_; uint32_t echo_ch_; }; }

至于send_trig_pulse内部到底是怎么拉高拉低GPIO的、测距封装在哪个定时器里，全部放在.cpp里面。外部使用者根本不需要知道，也不应该知道。这不是为了藏私，是为了让好用的人觉得好用，让维护的人觉得省心。你想想，如果一个传感器驱动内部从GPIO翻转变成了输入捕获，接口完全不变，App层的代码一行都不用动——这个就叫可维护性。

2.3 环境配置：VSCode给STM32工程搭一条趁手的调试链路

聊完怎么看工程，顺手补一个跟“干活”强相关的话题：开发环境。我接触过两种主流玩法——Keil MDK和VSCode + ARM GCC + OpenOCD。Keil胜在开箱即用、仿真器支持好，很多STM32教程和毕业设计都用它，用Keil的同学注意一下C51和STM32两套环境分开装，别互相覆盖就行。VSCode方案的优势是免费、跨平台、对C++工程的编辑体验好，而且调试时能直接看寄存器。顺带解答一个经常被问的“芯片第一脚怎么确认”问题：芯片表面丝印的小圆点或半圆缺口对应的就是1脚，对照数据手册的封装图再确认一下方向，基本上不会错。

如果你想把VSCode这套配置跑起来，关键就两个文件。第一个是tasks.json，里面写编译命令，核心就是调arm-none-eabi-gcc，把include目录、宏定义、优化等级都传进去；第二个是launch.json，里面告诉调试器用哪块芯片、哪条调试器、连多少端口。这里要特别提一个容易被忽略的东西：SVD文件。有了SVD文件，调试器就能把芯片所有外设的寄存器按名字显示出来，比如GPIOA的ODR、TIM2的CNT，在调试面板里一目了然，比裸看内存地址高不知道哪里去了。

{ "version": "0.2.0", "configurations": [ { "name": "STM32 Debug", "cwd": "${workspaceRoot}", "device": "STM32F103C8", "serverpath": "/usr/local/bin/openocd", "interface": "swd", "svdFile": "${workspaceRoot}/STM32F103xx.svd", "type": "cortex-debug", "request": "launch" } ] }

我第一次配VSCode调试的时候，光是launch.json就折腾了一晚上，最后发现问题出在interface写成了"jtag"而我的调试器是SWD。这个教训是：报错一定是某个细节没对，不是工具本身不行。环境搭建这种事，一次配好之后后面全是舒服的。

3. 嵌入式C++里真正值得用的特性，和我实际敲过的代码

3.1 先立规矩：不开异常、不开RTTI、不用new

这章聊代码。但聊之前必须先把规矩立住，不然你照着PC上那套C++写，写出来的东西在嵌入式里又大又慢。

嵌入式C++的通用做法很简单：

• 编译期关掉异常支持。用-fno-exceptions，异常处理在嵌入式里开销太大，而且大多数场景用不到；错误处理用错误码和返回值，不靠throw。
• 关掉RTTI。用-fno-rtti，运行时类型识别在这个内存受限的环境里基本没什么用，关掉能省不少ROM。
• 不用new/delete做动态内存管理。嵌入式里一怕碎片化，二怕分配失败没地方处理。对象用静态分配，编译时就把地址定好，运行时的确定性和可预测性是嵌入式最看重的。

这三个规矩不是我拍脑袋定的，你去翻各种嵌入式C++编程规范基本都是这三板斧。定完规矩之后你会发现，C++在嵌入式里剩下的特性其实都是好东西——封装、namespace、enum class、constexpr、模板、重载，全都不会引入运行时开销。

还有两个C/C++混编的关键字要提一下。一个是extern "C"，当你需要在C++里调用HAL库这种C语言写的库时，必须在include之前包一层：

extern "C" { #include "stm32f1xx_hal.h" }

另一个是volatile，它告诉编译器“这个变量的值可能在任何时刻被硬件修改”，所以每次使用都必须老老实实去内存读，不能把它优化进寄存器缓存。硬件寄存器、中断和主循环共享的标志位，没有volatile修饰极容易出诡异Bug。这个点同时也是嵌入式面试的高频题，后面会再提。

3.2 一个实际的驱动类：别让超声波模块的时序裸奔

光讲规矩没意思，直接上一个我实际用过的例子。之前我提到超声波模块HC-SR04，把它封装成一个类，是理解嵌入式C++非常合适的小例子。先看时序：TRIG引脚给一个10微秒以上的高电平触发，然后ECHO引脚会输出一个高电平脉冲，脉冲宽度和前方障碍物的距离成正比。

在裸机裸寄存器开发时，初始化、触发、等待回波这个流程散落在main函数里，代码又长又容易错。封装成类之后，整个驱动对外只有三个接口：构造、初始化、测一次距离。

namespace drv { class Ultrasonic { public: Ultrasonic(void* trig_port, uint16_t trig_pin, void* echo_tim, uint32_t echo_ch) : trig_port_(trig_port), trig_pin_(trig_pin), echo_tim_(echo_tim), echo_ch_(echo_ch) {} void init() { // 拉低TRIG引脚，确保初始状态；开启输入捕获中断 HAL_GPIO_WritePin(reinterpret_cast<GPIO_TypeDef*>(trig_port_), trig_pin_, GPIO_PIN_RESET); HAL_TIM_IC_Start_IT(reinterpret_cast<TIM_HandleTypeDef*>(echo_tim_), echo_ch_); } uint16_t measure_cm() { HAL_GPIO_WritePin(reinterpret_cast<GPIO_TypeDef*>(trig_port_), trig_pin_, GPIO_PIN_SET); HAL_Delay(1); // 至少10us；这里用1ms保证触发稳定 HAL_GPIO_WritePin(reinterpret_cast<GPIO_TypeDef*>(trig_port_), trig_pin_, GPIO_PIN_RESET); // 等待回波并计算距离的逻辑由定时器捕获中断完成， // 这里先返回上一次测量的缓存值 return last_distance_cm_; } void on_echo_rising() { rising_tick_ = __HAL_TIM_GET_COUNTER( reinterpret_cast<TIM_HandleTypeDef*>(echo_tim_)); } void on_echo_falling() { uint32_t falling_tick = __HAL_TIM_GET_COUNTER( reinterpret_cast<TIM_HandleTypeDef*>(echo_tim_)); uint32_t width_tick = (falling_tick >= rising_tick_) ? falling_tick - rising_tick_ : (65535 - rising_tick_) + falling_tick; // 经典换算：脉宽(us)/58 ≈ 距离(cm) last_distance_cm_ = static_cast<uint16_t>(width_tick / 58); } private: void* trig_port_; uint16_t trig_pin_; void* echo_tim_; uint32_t echo_ch_; uint16_t last_distance_cm_ = 0; uint32_t rising_tick_ = 0; }; }

来说说这个类设计想说明的三件事。第一，状态全在类里面，last_distance_cm_和rising_tick_被封装为私有成员，外部永远没有机会误改内部状态。第二，构造函数在对象初始化时就把引脚和定时器绑定好，这比散落各处的“Init函数清单”清晰得多。第三，成员函数的命名和职责单一，外部调用measure_cm()返回距离，开发者在App层完全不用感知时序细节。C++在嵌入式里的价值不是把代码变成面向对象的奇技淫巧，而是让外设的“使用契约”一目了然。

3.3 编译期计算：把查表搬进constexpr，运行时零开销

最后一个想展开的是C++11之后特别香的一个特性：constexpr。嵌入式里经常要算CRC校验表、正弦表、各种协议查表。传统写法是在初始化函数里跑一个for循环生成表，费时间不说，如果忘了调初始化函数，表就是空的。constexpr函数能让你在编译期完成这些计算，生成的二进制里直接就是完成态的表格，运行时不用干任何事情。

最简单的例子，计算一个CRC-8查找表：

#include <cstdint> constexpr uint16_t kTableSize = 256; constexpr uint8_t crc8_table(uint16_t index) { uint8_t crc = static_cast<uint8_t>(index); for (int i = 0; i < 8; i++) { crc = (crc & 0x80) ? static_cast<uint8_t>((crc << 1) ^ 0x07) : static_cast<uint8_t>(crc << 1); } return crc; } struct Crc8Table { uint8_t data[kTableSize]; constexpr Crc8Table() : data{} { for (uint16_t i = 0; i < kTableSize; i++) { data[i] = crc8_table(i); } } }; constexpr Crc8Table kCrcTable;

注意最后的constexpr Crc8Table kCrcTable;——这个对象放在全局静态区，编译时就被填好了，程序启动后读到的就是一张完整的表。你用传统的“运行时初始化”方案时，芯片上电要先花几百微秒甚至更多的CPU时间在循环赋值上；用constexpr方案，这部分时间彻底归零。在电池供电的设备里，这种细微的启动时间差异可能就决定了能不能在预算时间内出门。类似的还有正弦波查表、PID参数拟合表，全都适用。

4. 让Bug现形：调试思维和日志系统

4.1 一次超声波测距数值跳变的完整排查链路

好了，代码组织讲了，C++特性也讲了，接下来聊一个实际干活绕不开的事：调试。这个话题必须用真实案例来讲，不然全是空话。

有一次我在一个项目里用HC-SR04测距离，现象是这样的：测量结果绝大多数时候是准的，比如墙在30厘米，测回来29、30、31厘米跳来跳去，这个都能接受；但每隔几十次，会突然蹦出一个80多厘米的离谱值，过一会儿又恢复正常。这玩意儿放在稳定运行的设备里绝对不行，我得把原因揪出来。

我的排查过程是这样的。第一步，不猜，先加日志。在原驱动里把原始脉宽值（就是ECHO高电平持续的tick数）直接打印出来，看81厘米那个值对应的脉宽到底是多少。打印结果让我确定了：不是距离计算错了，是输入捕获捕获到的宽度真的变宽了。第二步，再看这些异常值有没有规律。我记录异常脉冲出现的时间，发现它大多集中在我发送trigger之后的某一段间隔内，而且附近正好有个电机启动的动作。

这时候我初步怀疑是EMI干扰——电机启动瞬间产生的高频噪声，被ECHO引脚当成回波信号给捕获下去了。于是我在硬件上给ECHO引脚加了一颗几十pF的下拉电容做滤波，重新跑测试。异常值从“每隔几十次一次”变成了“基本看不到”，但因为项目里电磁环境比较差，这种靠hope的修复我不放心。

第三步，我决定彻底放弃在中断里用“GPIO电平翻转加计时器读数”的组合，改用定时器输入捕获的两个独立通道，一个捕获上升沿，一个捕获下降沿。这样测量到的脉宽是硬件级精确的，不受CPU进中断的抖动影响。改完以后结合软件上的“超量程保护”——如果脉冲宽度超过对应最大距离的阈值，直接丢弃并重测——这个跳变就彻底消失了。

为什么要把这个完整的排查链路写出来？因为我见过太多人遇到Bug第一反应是“百度一下这个模块是不是有问题”，然后换一个模块重试。排查Debug的正确姿势是：从现象反推数据，从数据缩小范围，从范围找到根因，最后用可复现的方式验证。日志在这里就是你的眼睛，没有日志的嵌入式调试就是摸黑走路。

4.2 状态机：让程序流程“可推理”

排查完具体Bug，再讲一个能让Bug从源头上变少的设计方法：状态机。嵌入式程序跟PC程序很大的一个区别是，它要跟真实世界的东西打交道，而真实世界是有“状态”的——加热棒现在是在加热还是待机？气泵是正在运行还是在休息周期？如果你把这些状态用一堆if...else去表达，多分叉几层之后就很难推理了；但用状态机来表达，每种状态做什么、什么条件下跳转到哪个状态，是清清楚楚的。

拿恒温控制来说，一个简单的加热器状态机可以这么写：

enum class HeaterState : uint8_t { kIdle, // 待机 kHeating, // 加热中 kOvershoot // 已超温，等待降温 }; class HeaterController { public: void update(float current_temp) { switch (state_) { case HeaterState::kIdle: if (current_temp < kTargetLow) state_ = HeaterState::kHeating; break; case HeaterState::kHeating: if (current_temp >= kTargetHigh) state_ = HeaterState::kOvershoot; break; case HeaterState::kOvershoot: if (current_temp < kTargetLow) state_ = HeaterState::kIdle; break; } // 每个状态下决定执行器动作 bool heater_on = (state_ == HeaterState::kHeating); heater_.set(heater_on); } private: HeaterState state_ = HeaterState::kIdle; static constexpr float kTargetLow = 22.0f; static constexpr float kTargetHigh = 26.0f; };

这个模式一旦用熟了，你会发现系统在任意时刻都处于一个明确的状态，出问题的时候只要问一句“它现在是什么状态、在什么条件下跳到这里的”，排查路径马上短一半。很多工程师以为状态机是个高深的东西，其实它就是“把程序的流程画成一张有向图，然后照着图写代码”。

4.3 日志分级和断言：别把所有信息都怼到一个printf里

最后是日志。你肯定注意过HAL库里有个assert_param(expr)宏，参数校验失败会报错。这个思路很好——嵌入式程序必须有“大声失败”的能力，而不是默默带病运行。我自己会在工程里加一个更简单的断言宏：

#define ASSERT(expr) \ do { \ if (!(expr)) { \ log_error("ASSERT failed: %s, line %d\n", #expr, __LINE__); \ while (1); \ } \ } while (0)

碰上明确不该发生的情况，直接断言、停在原地、打印上下文。别跟我说“这不优雅”，在单片机里，正确、可发现、可定位的失败，比优雅重要得多。

日志本身也要分级。我一般分四级：ERROR、WARN、INFO、DEBUG。ERROR是一定要输出的，WARN是需要注意但不影响主流程的，INFO是运行状态的关键节点，DEBUG是调试期间的明细信息。编译的时候可以通过宏把DEBUG日志整体关掉，只保留ERROR和WARN，这样量产版本既不怕刷屏，也不怕信息太多。日志的载体在开发阶段用printf重定向到串口或者SWO调试口，配合重定向函数，一行代码就能调通。但注意一点：半主机模式（semihosting）在连接调试器时好用，脱离调试器单独运行就会被卡死，做产品代码千万别用它。

5. 定时器不是延时器：PWM、输入捕获和量程计算

5.1 从认识PSC、ARR、CNT、CCR开始

虽然前五篇里定时器已经出现过，第六篇我还是想把它单拎出来再讲透一层，因为定时器是STM32里最容易被“低配使用”的外设。新手最常见的操作就是拿定时器做HAL_Delay，完全没把它的输入捕获、输出比较、PWM、编码器这些硬件能力用起来。实际上，定时器就是一个独立的硬件计数器，它不占CPU，一边数数一边触发各种事件，你只要把它配好，它自己在那儿干活。

一个定时器涉及四个关键东西：

• PSC（预分频器）：把定时器时钟分频到计数频率，决定了一个tick代表多长时间。
• ARR（自动重装载值）：计数器数到这个值时溢出或清零，决定了定时器周期。
• CNT（计数器）：当前计到哪了。
• CCR（捕获/比较寄存器）：PWM模式下决定占空比，捕获模式下用来存捕获的时间戳。

四者的关系可以用一个很俗但好记的比喻：PSC是秒针的刻度粗细，ARR是钟表走多久回一次零，CNT是表盘指针现在的位置，CCR是你设定的闹钟时间点。比如说系统时钟是72MHz，想让计数器频率变成1MHz（即每tick是1微秒），那PSC就设成71，因为72MHz/(71+1)=1MHz。想让这个定时器每10毫秒溢出一次，那ARR设为9999，因为(10000×1us)=10ms。

5.2 超声波测距的工程实现：用输入捕获，别再用GPIO掐表

关于超声波HC-SR04，前面也提到了，这里把定时器用法说完整。测量逻辑很简单：TRIG引脚先拉高10微秒以上触发，之后ECHO引脚会输出一个高电平宽度正比于距离的脉冲。标准计算公式是：距离(cm)=脉宽(us)/58，也就是声速340m/s下脉冲往返时间的换算。

很多教程教你一种实现方法：GPIO轮询看ECHO电平变化，同时用定时器计时。这种办法最大的问题是精度受CPU中断影响——万一在等待回波时来了一个优先级更高的中断，你的计时就被拉长了。好一点的做法，也是我在实际项目里用的，就是把这个时序交给定时器硬件去完成：

1. 配置ECHO引脚对应的定时器通道，开启上升沿捕获中断。
2. 上升沿到来时，在中断里记录当前的CNT值，然后把捕获极性切换成下降沿。
3. 下降沿到来时，再记录一次CNT值，两次记录之间的差值就是脉宽（tick单位）。
4. 用脉宽除以58得到厘米数。

这个方案的精度不依赖CPU是否及时进中断——因为捕获事件是定时器硬件在电平翻转的瞬间记录CNT的，事后CPU再去读即可。测量值稳不稳，硬件说了算，软件只是把结果搬出去。这也是为什么我在前面的排查案例里坚决把“GPIO掐表”改成输入捕获，效果立竿见影。

伪代码层面，捕获中断大致是这样：

/* TIMx_IRQHandler 里 */ if (LL_TIM_IsActiveFlag_CC1(TIM2)) { if (in_echo) { /* 下降沿，脉宽结束 */ width_tick = LL_TIM_GetCompare1(TIM2) - rising_tick; in_echo = 0; } else { /* 上升沿，脉宽开始 */ rising_tick = LL_TIM_GetCompare1(TIM2); /* 把捕获极性切换成下降沿 */ in_echo = 1; } }

5.3 量程和安全边界：先算清楚，再写代码

定时器配置还有个特别容易翻车的点：量程。我见过有人随便把ARR设成65535，然后把超声波模块接到60多米开外，结果测量值反复横跳。问题就出在计数器溢出上——如果回波在计数器转了一整圈之后才回来，你就没法区分这个脉宽到底是一个周期内还是跨了两三个周期。

算一下就有数了。假设PSC=71，计数频率1MHz，ARR=65535，那么脉宽最多能容纳65535个tick，也就是65.535毫秒。声速取340m/s，这65.535毫秒对应的往返距离约22.3米，单程约11.1米。也就是说这个配置下能稳定测量的最大距离大概在11米左右。你要测的量程只有2米，那回波脉宽最长也只是(2×2)/340≈11.8毫秒，远小于65毫秒的溢出周期，不会绕圈，这时候配置是安全的。反过来，如果你的量程是30米，就必须重新设计PSC和ARR，并处理溢出中断。

这类计算在嵌入式里属于“开工之前五秒钟算一算”的事，但很多项目都是写完全部代码之后，在实测阶段才被发现量程不够。我吃过这个亏，所以现在任何和物理量挂钩的配置，我都会先在草稿纸上把频率和量程的关系写出来，再敲代码。

5.4 定时器中断里别干的事

顺手记一个嵌入式新手最容易犯的错：在中断回调里做耗时操作。比如在定时器中断里直接调用printf、HAL_Delay或者一个几百毫秒的传感器读取过程。这会带来两个问题：一是中断服务时间过长，高优先级中断无法抢占，实时性崩了；二是如果在printf输出过程中又来了同一个中断，这就是一个潜伏的重入风险，轻则丢数据，重则进HardFault。

我在实际项目里的习惯是：中断回调里只做“记录标志+搬运少量数据”，所有真正的业务处理放到主循环里判断标志位后再做。比如超声波捕获中断里只更新rising_tick和falling_tick，计算距离的活儿在主循环里干。现在回想起来，很多“程序跑着跑着就死机”的Bug，追到底都是中断里干了太多不该干的活。

6. 从会调到能交付：毕设、开源项目和面试的实话

6.1 毕业设计最常见的坑，其实是“最大的工程就是main.c”

第六篇写到这儿，前面讲的都是方法论和代码技巧。最后这章我想聊聊一个很现实的应用场景：毕业设计。每年都有人拿STM32做毕设，不外乎智能小车、环境监测、鱼缸控制器这几类。我看过不少本科生的代码，最大的通病就是——一整个项目的代码全堆在一个main.c里，加上几十个全局变量，改一个功能牵一发而动全身。评审老师看代码如果是要找茬的，这种情况下基本是一击致命。

把毕设代码做好，说实话不需要什么高深技巧，就是把这篇讲的工程拆分、头文件治理落到实处。哪怕是一个只有三个模块的智能小车：电机控制、传感器避障、串口调试。你把它拆成drv_motor.c、drv_ultrasonic.c、app_car.c，再配一个清晰的README，就比90%的同学强了。毕设答辩的时候，老师问“你这个工程结构是怎么设计的”，你就可以理直气壮地讲依赖关系、讲数据流，而不是语无伦次地说“反正就是能用”。

6.2 怎么读一个陌生的STM32工程：从启动文件到外设配置

说完写，再说读。来找一个开源项目或工作交接的STM32工程来读的时候，很多人是懵的，因为第一次见可能.map文件、.sct文件、.ld脚本、startup_xxx.s汇编文件，完全不知道先看哪里。我的阅读顺序是这么来的：

先看启动文件和链接脚本，确定芯片型号、Flash和RAM大小，知道代码跑在什么资源上限里；然后看系统时钟配置，SystemInit()和HAL_RCC_*那一段，搞清楚外设总线上的时钟是48MHz还是72MHz；再看外设初始化代码，一个外设一个外设地过初始化里的参数（模式、中断、DMA）；最后才是看应用逻辑。这个顺序之所以重要，是因为外设时钟和初始化决定了硬件能干什么，跳过这两层直接看业务代码，你会看到一堆看不懂的函数调用，越读越懵。

读代码和写代码是两件事，写的时候要求自己逻辑清晰，读的时候要学会“抓主干”。一个STM32工程的主干通常就是：初始化硬件→初始化外设→进入主循环→主循环里轮询或等待事件→处理事件。你按这个主干去回填细节，整个工程很快就会从一堆陌生符号变成一张看得懂的地图。

6.3 C++嵌入式面试的几个高频题：volatile、static、extern "C"、中断

最后聊一下求职。我在面试嵌入式岗位的时候经常问C++相关的知识点，这里列几个高频点，大家自己查漏补缺。第一个是volatile，前面已经讲过，它跟硬件寄存器、中断共享变量强相关。第二个是static，在C语言里修饰局部变量、全局变量、函数分别是什么含义，很多人在这个点上翻车。第三个是extern "C"，主要考混合编程时C和C++符号名mangle的问题。第四个是中断处理函数不能做什么，我在定时器那一节已经讲过了。还有一个常见题是C++的构造函数和析构函数在嵌入式里是怎么被调用的；如果你用了全局对象，它的构造发生在main函数之前，这点在编译链接顺序里要注意。

这些题其实都不难，难的是在面试时把每个知识点跟实际项目关联起来。你回答volatile的时候能顺手举一个刚才排查超声波干扰时用volatile修饰共享变量的例子，面试官听你讲跟背答案讲，完全是两个印象。所以这一章的忠告是：知识点可以背，但每个知识点最好都有“我做过的项目里的一个真实场景”来背书。

说回到这一篇的开头那句话——咱们还差活滴。差在哪？无非就是工程组织、C++落地、调试能力、定时器这些硬邦邦的实战细节。把这些补齐了，你手里的STM32才真正从一个“能跑例程的芯片”，变成一个“能承载完整项目的平台”。至于嵌入式实时操作系统、网络协议栈那类更进阶的内容，那是第七篇以后的事了，到时候咱们再说。