前言
说句实话，做嵌入式C++开发的人不少，但真正把C++用出味道来的不多。很多人写STM32项目就是换了一副马甲的C语言——类不会写、RAII不用、模板不敢碰，最后代码跟早期的寄存器版C代码没什么区别。我这个系列一路写到第6篇，前5篇分别聊了环境搭建、GPIO的基础封装、状态机思路、定时器与PWM、中断与事件驱动，核心器件和基础框架都齐了。这篇标题叫“哟哟哟，咱们还差活滴”，说白了就是在收尾——一个正经的嵌入式项目，光有点灯、按键、定时器这些基本功还不够，还差几块真正能“干活”的东西。
本篇文章我准备把项目最后的三块硬骨头啃掉：第一是OLED屏幕显示模块，让设备长眼睛；第二是片内Flash的数据持久化存储，让设备长记忆；第三是串口通信协议，让设备能跟外部对话。这三块做完，我们这个基于STM32的C++小型环境监测站才算真正能拉到现场跑起来。适合正在学STM32和嵌入式C++的朋友参考，也适合那些已经用C写过一遍、想看看C++怎么做嵌入式的人对比着看。如果你连工程都还没建起来，可以先翻翻这个系列前面的文章，把基础框架搭好再回来看这篇，效果会好很多。
1. 先盘一盘：这个项目还差哪些"活"
1.1 从点灯到产品的距离
前几篇文章搭好了一套能响应的框架：GPIO的C++封装、按键状态机、定时器PWM输出，顶多算是一块会眨眼的开发板。可一个真正能拉到现场跑的设备，至少要满足三个条件：有交互界面、掉电不丢数据、能和外部通信。这三个条件分别对应显示、存储和通信接口。我见过很多新手写STM32项目，功能一大堆，但一断电全没，现场要改参数只能重新烧固件，这在实际工程里是完全不可接受的。
所以我们这个系列的项目，实际是一个小型环境监测站。它做什么事情呢？用ADC读取温湿度传感器的输出电压，把结果换算成实际温度；用PWM控制一个小风扇，根据温度自动调速；然后把这些数据实时显示在OLED屏幕上，同时每隔一段时间把最新的一批记录写入片内Flash，防止断电丢失。现场如果想查看历史数据或者修改报警阈值，就通过串口发指令给设备。到这一步，它才勉强算一个“产品原型”，而不只是“开发板代码”。
1.2 三块“活”的核心难点
这三块活各自都有坑。OLED屏幕最坑的地方是时序和初始化序列，网上抄来的驱动代码往往是C风格的全局变量满天飞，你想把它整合进C++工程就得做真正的面向对象重构。Flash存储最坑的地方是擦写寿命和写保护机制，不知道原理就很容易把芯片写废或者写完读出来全是0xFF。串口通信最坑的地方是粘包、丢包和帧格式解析，新手最容易犯的错误就是直接按字节读一个处理一个，结果数据稍微一多就乱套。
这篇文章我会把每一块的类设计思路、关键代码、背后原理全部讲透。不用MDK那种图形化配置工具，代码全部手写寄存器加HAL库混合方式，重点展示C++的封装能力和资源管理思想。编译器还是沿用前几篇用的arm-none-eabi-gcc加CMake这套，环境搭建方法在系列第1篇里写过，这里不再重复。
2. OLED显示模块的C++类封装方案
2.1 为什么选用IIC接口的OLED
市面上的0.96寸OLED屏有两种主流接口，SPI版本刷新快但占引脚多，IIC版本只需要两根线。我们这个环境监测站，数据更新频率其实很低——温度传感器本身一秒也采不了几次，屏幕显示内容也不是动态视频，IIC的带宽绰绰有余，省下来的引脚正好给其他外设用。
我当时选型的时候其实还纠结过要不要上SPI，后来算了一笔账：写一帧屏幕大约需要1024字节（128x64分辨率的SSD1306控制器，页模式下每页8像素），IIC标准模式下传输速度约100kbps，也就是一帧数据要约90ms，SPI接口下这个时间能压到10毫秒以内。但我们的刷新频率只有每秒1次，90ms完全够用，换成SPI纯属浪费引脚。如果你的项目需要高频刷新动图或者做仪表盘指针，再考虑SPI版本不迟。
2.2 OLED类设计：从裸函数到对象封装
这里直接上代码，看看我是怎么把SSD1306的驱动封装成C++类的。头文件我命名为ssd1306.hpp，类的核心接口是这样设计的：
#pragma once #include <cstdint> class SSD1306 { public: enum class Color : uint8_t { Black = 0, // 灭 White = 1, // 亮 Invert = 2 // 反色 }; explicit SSD1306(I2C_HandleTypeDef* hi2c, uint8_t addr = 0x78); virtual ~SSD1306() = default; // 禁止拷贝，屏幕资源不允许复制 SSD1306(const SSD1306&) = delete; SSD1306& operator=(const SSD1306&) = delete; bool init(); void display(); // 把显存刷新到物理屏幕 void clear(Color color = Color::Black); void drawPixel(uint8_t x, uint8_t y, Color color); void drawChar(uint8_t x, uint8_t y, char c, Color color = Color::White); void drawString(uint8_t x, uint8_t y, const char* str, Color color = Color::White); private: bool writeCommand(uint8_t cmd); bool writeData(const uint8_t* data, size_t len); void setAddress(uint8_t page, uint8_t col); I2C_HandleTypeDef* _hi2c; uint8_t _addr; uint8_t _buffer[128 * 64 / 8]; // 1KB显存 };几个设计点我要重点解释一下。第一点是拷贝构造和赋值运算符显式delete掉，这是RAII思想的体现——一个OLED设备对象对应一个物理外设，如果允许拷贝，两个实例同时操作同一个I2C地址，很容易出现异常的时序交叉。第二点是I2C的实例用指针保存，而不是直接对象嵌入。这么做是为了在构造时不依赖具体IIC初始化顺序，可以在main函数中先初始化HAL的I2C外设，再把句柄传给OLED对象，保持C++对象生命周期和硬件外设生命周期解耦。
2.3 关键实现与初始化序列详解
初始化序列是SSD1306最折腾人的地方。不同厂家屏幕的初始化命令大同小异，但有几条命令的顺序错了屏幕就白屏。下面是我的初始化函数核心部分：
bool SSD1306::init() { // 显示器关闭（稳定电源） writeCommand(0xAE); // 设置显示时钟分频因子/振荡器频率 writeCommand(0xD5); writeCommand(0x80); // 设置多路复用比，0.96寸的是64行 writeCommand(0xA8); writeCommand(0x3F); // 设置显示偏移 writeCommand(0xD3); writeCommand(0x00); // 设置显示起始行 writeCommand(0x40); // 设置电荷泵使能，这是关键！ writeCommand(0x8D); writeCommand(0x14); // 设置内存寻址模式为页模式（水平模式也行，看需求） writeCommand(0x20); writeCommand(0x00); // 设置列地址范围 writeCommand(0x21); writeCommand(0x00); writeCommand(0x7F); // 设置页地址范围 writeCommand(0x22); writeCommand(0x00); writeCommand(0x07); // 对比度设置为最大 writeCommand(0x81); writeCommand(0xCF); // 预充电周期 writeCommand(0xD9); writeCommand(0xF1); // 设置COM引脚硬件配置 writeCommand(0xDA); writeCommand(0x02); // 设置VCOMH取消选择电平 writeCommand(0xDB); writeCommand(0x40); // 设置显示全亮 writeCommand(0xA4); // 设置显示模式为正常 writeCommand(0xA6); // 开启显示 writeCommand(0xAF); clear(Color::Black); display(); return true; }这里有一个我踩过的坑必须提一下。电荷泵命令0x8D 0x14如果漏了，屏幕是彻底不亮的，因为SSD1306内部升压电路没有使能，OLED面板根本没有驱动电压。另一个坑是页地址模式下的坐标换算：很多人直接按像素坐标算显存偏移，结果显示出来的字符东倒西歪。页寻址模式下，显存被分成8页，每页是一个128字节的行，覆盖8个像素高度。画一个点的时候，需要先算出它属于第几页、该页的第几位，然后对显存字节做按位或操作。我封装了drawPixel来处理这个问题：
void SSD1306::drawPixel(uint8_t x, uint8_t y, Color color) { if (x >= 128 || y >= 64) return; uint16_t index = (y / 8) * 128 + x; uint8_t bit = 1 << (y % 8); switch (color) { case Color::White: _buffer[index] |= bit; break; case Color::Black: _buffer[index] &= ~bit; break; case Color::Invert: _buffer[index] ^= bit; break; } }这里我把x和y单独做了边界判断。初学者很喜欢忽略这种防御性写法，但在C++嵌入式里，越界访问是一个静默的灾难——它不会立刻崩，而是悄悄篡改相邻变量的值，查错的时候能让你怀疑人生。显存_buffer是1KB的数组，边界不检查，坐标一跑偏，可能把状态变量或者中断标志位给改了。
2.4 显示刷新策略：局部刷新和整帧刷新怎么选
OLED还有一个和LCD不一样的地方，它不需要持续扫描刷新。LCD如果时序不对会闪烁，OLED只要选通矩阵并保持驱动电压，它会一直显示整个帧缓冲区的内容。这也是为什么我们要维护一个1KB的_buffer——你要改哪个像素，直接改缓冲里对应的字节，最后调display()把整块缓冲发过去就行，屏幕不会闪。
但在低配IIC上，整帧刷新确实慢。实测下来，128x64的整屏数据加上控制头，总计约1063字节，标准模式100kbps下全刷一次要95毫秒左右。所以如果你的UI要做一个进度条动画或者数字频繁跳动，建议做一个“脏矩形”机制：记录哪些区域的数据变了，只更新那几页的字节。SSD1306支持设置列地址和页地址范围，我们可以只传输变化的那部分显存。我在drawString和drawChar上面没做这么复杂的优化，因为环境监测站一秒刷一次完全够用，但如果你要做小游戏或者示波器，这个局部刷新就很有必要了。
3. Flash数据存储模块：掉电不丢的关键
3.1 为什么选择片内Flash而不是外挂EEPROM
这个项目的数据量不大，每一帧记录可以压缩到一个结构体里，大概16字节。一天存1440条（一分钟一条），才23KB左右。STM32F103系列芯片的Flash容量从64KB到512KB不等，我们用的中容量芯片有64KB主Flash，其中足够存放固件、字库，还能剩余将近30KB给我们做数据存储。这就没必要外挂一块IIC的AT24C02或者SPI的W25Q64了。
但片内Flash有一个致命限制：擦写寿命。STM32F103的Flash擦写次数标称1万次，数据保留时间20年。如果每秒钟写一次，不到3小时就寿命耗尽。所以直接用片内Flash做高速数据记录是绝对不行的，必须做“磨损均衡”——把写入分散到不同的扇区，让每个扇区的擦写次数大致均匀。
3.2 小容量平台的磨损均衡策略
我采用的方案是双扇区交替存储加RAM缓存。STM32F103的Flash扇区大小不一，小容量芯片的扇区通常1KB，但我们选用的中容量芯片每页是1KB（64KB版本分成64页）。实际操作上，我把最后8页（8KB）划分成两个逻辑存储区，每区4KB，分别标记为A区和B区。每条记录是一个固定长度的结构体，带CRC校验，一个存储区可以存大约256条记录。
写入策略是这样的：数据先累积在RAM环形缓冲里，凑满一批（比如32条）再一次性写入当前活跃区。活跃区写满后，把最新数据放到另一个区，并把旧区整体擦除。下次再写满新区时，再擦除另一个区。这样每个扇区实际擦写次数就减少了一半。配合批写，平均下来每天的擦写次数大约在60次左右，理论上可以用好几年，完全应付这个项目的生命周期。
3.3 存储结构体的C++序列化处理
C++里直接写结构体到Flash是很爽的事情，但有两个坑：一是对齐问题，二是端序问题。先看代码：
struct SensorRecord { uint32_t timestamp; // Unix时间戳 float temperature; // 温度 float humidity; // 湿度 uint16_t fanDuty; // 风扇占空比百分比 uint8_t state; // 设备状态位 uint8_t reserved[3]; // 保留字段，对齐填充 uint32_t crc32; // 校验 }; static_assert(sizeof(SensorRecord) == 24, "记录结构体大小必须是24字节！");我显式地把reserved[3]这个填充字节加进去，然后用static_assert在编译期卡死结构体大小。这是嵌入式C++的一个很实用的小技巧——编译期就知道结构体有没有被编译器悄悄对齐，不至于烧录之后才发现读出来跟写进去的对不上。
浮点数存储在这里没有做字节序转换，因为STM32是ARM小端，自写自读不存在端序问题。但如果有一天你要把数据导出到PC上解析（x86也是小端），可以不做转换；如果要发到网络或者转成大端平台，就得写一个htonf之类的函数处理了。
3.4 Flash写入操作的C++封装
Flash操作最重要的原则是：擦除前必须解锁，写完必须加锁，且不能在执行Flash操作时响应中断里的Flash读写请求。看一下代码：
class FlashStorage { public: enum class Status { Ok, WriteError, EraseError, Busy }; FlashStorage(uint32_t baseAddr, size_t sectorSize); Status appendRecord(const SensorRecord& rec); Status eraseBank(uint8_t bankId); size_t readRecords(SensorRecord* outBuf, size_t maxCount); uint8_t activeBank() const; private: Status unlock(); Status lock(); bool isBusy() const; uint32_t _baseAddr; size_t _sectorSize; uint8_t _active; uint16_t _recordCount; };关键在unlock和lock两个私有方法：
FlashStorage::Status FlashStorage::unlock() { while (isBusy()) return Status::Busy; FLASH->KEYR = 0x45670123; FLASH->KEYR = 0xCDEF89AB; return Status::Ok; } FlashStorage::Status FlashStorage::lock() { FLASH->CR |= FLASH_CR_LOCK; return Status::Ok; }STM32F103的Flash解锁序列是固定两个密钥字，顺序反了或者中间插入其他写操作都会导致总线错误。另一个必须牢记的是擦除操作不能断在中间——如果擦除过程中又来了一个中断，中断代码也去做Flash操作，那这个芯片就真的废了。实际工程中最简单的做法是：在擦除和编程期间，把对外设的中断标志位屏蔽掉，或者干脆用一个全局互斥量拦住所有可能触发Flash操作的路径。
3.5 掉电保护机制值得做的两个细节
这个模块我额外做了两个保险。第一个是CRC校验：每24字节记录后面跟着4字节CRC32，读取的时候先校验再解析。这在平时感觉不到用处，直到有一次我故意在测试中让板子写数据写到一半直接断电，恢复供电后读出来的记录里有一条CRC错误，被完整跳过，其他数据全部完好。有了CRC，掉电损坏只是丢一条坏记录，而不是让整个数据库不可用。
第二个是存储区头部标记。每个区前16字节不存业务数据，而是存一个魔数0xA5A5A5A5、区ID、当前记录条数、以及最后一次写入序号。设备上电时通过对比两个区的写入序号来选择活跃区：序号大的说明是最新的。如果没有这个序号机制，双区交替存储很容易出现“最新数据在哪个区”的混淆，到时候恢复出旧数据就麻烦了。
4. 串口通信协议：让设备开口说话
4.1 帧格式设计：为什么不用裸发
串口通信最忌讳的就是裸发。你直接printf("temp=25.3")，PC端看着是挺顺眼，但是回传指令怎么处理？字符串解析容易出错，中文编码问题、变长字段问题都是坑。更规范的做法是设计一套二进制帧协议。
我用的帧格式很简单，总共6字节固定头加变长载荷，加2字节CRC16校验：
| 0xAA | 0x55 | LEN | CMD | DATA[LEN] | CRC16_L | CRC16_H |0xAA 0x55是帧头，用于同步LEN是DATA段的字节数，最大255CMD是命令码，例如0x01表示读取当前状态，0x02表示设置报警阈值DATA是参数区，长度由LEN决定- CRC16校验整个帧（含LEN和CMD），防止数据错误被当成有效指令
选0xAA 0x55做帧头是有讲究的——这两个字节的二进制模式分别是10101010和01010101，在串口空闲线上很容易识别，误码撞上的概率低。实际调试发现，偶尔数据线上有个毛刺，收到的会是0xAA 0xAA，第二个字节不匹配直接丢弃，容错很好。
4.2 环形缓冲区加状态机的接收解析
串口接收端不能“收一个字节处理一个字节”，否则一个帧被调度器分成两段到达，程序就傻眼了。正确的做法是：中断服务函数只把字节塞进一个环形缓冲区，主循环里再跑状态机解析。
先看环形缓冲区的实现，这个类很简单，但是嵌入式串口的基础设施：
template <typename T, size_t N> class RingBuffer { public: bool push(const T& item) { if (isFull()) return false; _buf[_head] = item; _head = (_head + 1) % N; return true; } bool pop(T& item) { if (isEmpty()) return false; item = _buf[_tail]; _tail = (_tail + 1) % N; return true; } bool isEmpty() const { return _head == _tail; } bool isFull() const { return (_head + 1) % N == _tail; } private: T _buf[N]; size_t _head = 0; size_t _tail = 0; };用模板实现的好处是，未来如果要用SPI或者CAN接收缓冲区，可以复用同一份代码，提高工程复用率。这里我取的是256字节的容量，串口115200波特率下能缓冲约22毫秒的数据，完全足够主循环空闲时消化。
解析状态机我用了枚举加switch的模式，这样可读性比一长串if-else强很多：
enum class FrameState : uint8_t { WaitHead1, WaitHead2, WaitLen, WaitCmd, WaitData, WaitCrcLow, WaitCrcHigh }; FrameState _state = FrameState::WaitHead1; uint8_t _cmdBuf[256]; uint8_t _lenBuf = 0; uint8_t _dataIdx = 0; uint8_t _crcRecv[2]; bool FrameParser::parseByte(uint8_t byte) { switch (_state) { case FrameState::WaitHead1: if (byte == 0xAA) _state = FrameState::WaitHead2; break; case FrameState::WaitHead2: _state = (byte == 0x55) ? FrameState::WaitLen : FrameState::WaitHead1; break; case FrameState::WaitLen: _lenBuf = byte; _dataIdx = 0; _state = FrameState::WaitCmd; break; case FrameState::WaitCmd: _cmdBuf[_dataIdx++] = byte; _state = (_lenBuf > 0) ? FrameState::WaitData : FrameState::WaitCrcLow; break; // ... 数据位按_lenBuf逐个接收，然后进入CRC校验位 } return false; // 一帧完整接收时返回true }这个状态机的优势在于：不会因为中间错一个字节就全盘崩溃。数据段有噪声，CRC校验会兜底；CRC坏了这一帧被丢弃，状态机留在WaitHead1继续找下一帧的帧头，不需要复位。
4.3 在C++里做命令分发的技巧
帧解析出来之后，要根据CMD分发给不同的处理函数。这里又是个体现C++优势的地方。如果用C语言，就是一堆switch-case；用C++我们可以做命令注册表，类似路由器按指令码查表调函数。
using CommandHandler = std::function<void(const uint8_t* data, uint8_t len)>; class CommandDispatcher { public: void registerHandler(uint8_t cmd, CommandHandler handler) { _handlers[cmd] = std::move(handler); } bool dispatch(uint8_t cmd, const uint8_t* data, uint8_t len) { auto it = _handlers.find(cmd); if (it == _handlers.end()) return false; it->second(data, len); return true; } private: std::map<uint8_t, CommandHandler> _handlers; };使用std::function虽然比裸函数指针多一些开销（堆分配和类型擦除），但换来的是可以用Lambda表达式注册，比如这样：
cmdDispatcher.registerHandler(0x01, [](const uint8_t* data, uint8_t len) { // 读取当前温度并返回 float temp = sensor.getTemperature(); uint8_t reply[4]; memcpy(reply, &temp, 4); uart.sendFrame(0x81, reply, 4); });在STM32F103这种Cortex-M3上，std::function+容器确实会带来Flash占用增大和栈开销增加的问题，所以我实际项目里做了一个取舍：只对命令分发用std::function，环形缓冲用模板，其他地方尽量不用STL容器。整个工程编译下来Flash占用约58KB，RAM占用约11KB，对这个64KB Flash的芯片来说已经是极限操作了。你要是觉得紧张，可以把分发表改成静态函数指针数组，效果类似但代码会更C风格一些。
4.4 串口状态反馈与断线重连处理
串口通信不仅要能收，还要能判断链路是否正常。我做了一个简单的双向心跳机制：设备每秒发送一个0x10心跳帧，如果PC端连续5秒没有回应，设备就把通信状态置为离线，OLED屏幕上显示一个警告图标。如果设备连续3秒没有发心跳（异常复位或死机），PC端也会弹出提示。
这个心跳的实现在代码里其实就是定时器中断服务里置一个标志，主循环查标志然后发送帧。不复杂，但我提出来是因为很多初学者做完通信模块就以为万事大吉，没有考虑链路异常状态，导致现场调试时一头雾水——板子明明烧好了，为什么收不到数据？很可能是串口线断了，或者USB转串口芯片没装驱动，而设备闷不吭声，你根本不知道哪里出了问题。有了心跳机制，至少能在UI上直观看到通信断没断。
5. 联调阶段的高频问题与排查实录
5.1 OLED白屏问题：电荷泵和初始化顺序
我联调第一天就栽在OLED上。断电重上电后，屏幕完全白屏，没有任何显示。排查过程如下：
先用逻辑分析仪抓I2C波形，确认有数据在传输，地址也是0x78，说明通信本身是通的。然后对比我手里的SSD1306 datasheet，发现我初始化时漏了电荷泵使能。这个命令必须在显示开启0xAF之前发送，且两条命令之间不能插入其他命令（部分芯片手册明确要求连续发送）。修正后屏幕正常点亮。
另一个白屏原因是逻辑电源不稳定：IIC上拉电阻没接或者阻值太大。STM32的IIC引脚是开漏输出，必须外部上拉到3.3V才能产生高电平。忘了接上拉电阻时波形根本抬不起来，逻辑分析仪上看到的是乱码一样的毛刺。我一次性踩了这两个坑，在这里啰嗦一遍，就是为了让看文章的朋友少走弯路。
5.2 串口乱码与波特率漂移
第二个高频问题是串口乱码。现象很经典：设备启动时打印一堆正常日志，过几分钟后乱码，重启又好了。最后查出来是晶振问题——我的板子用了内部RC振荡器HSI，频率漂移在2%左右，115200波特率的误差容忍度大约是±2%，一开始凑合能用，温度一上来RC漂移加速，直接超过容限，串口就乱了。
解决办法是切换到外部8MHz晶振HSE，并把串口波特率从115200降到57600，留足余量。降低波特率是为了给协议解析更多时间，但这会牺牲传输速度。实际项目中测温数据的传输量很小，每秒几帧，57600完全够。如果你也有类似情况，建议先量一下实际波特率再考虑换晶振，别一上来就怪代码。
5.3 Flash写入后读出来全是0xFF
这类问题多半是地址对齐或者没有先擦后写。STM32的Flash只能把1擦成0，不能单独把0写成1。你要更新一个字节，必须先整块擦除再重新写入。如果写之前没有擦，写入操作执行了但实际没成功，读出来还是0xFF。
另外，有些型号Flash需要半字（16位）对齐写入。我用的是HAL库的HAL_FLASH_Program，如果传入的地址偏了1个字节，它不会报错，但写入的数据会落到错误的地址上，读出来自然不对。解决方法是所有Flash地址全部对齐到4字节，结构体大小也设计成4的倍数。我的SensorRecord是24字节，刚好整除。
5.4 中断优先级引发的数据丢失
串口丢帧还有一个隐蔽的杀手——中断优先级配置。STM32的NVIC中断优先级分组如果配置不当，串口中断可能会被定时器中断长时间打断。我的定时器每1毫秒触发一次，中断服务里做了不少浮点运算（温度换算），耗时接近100微秒。115200波特率下接收一个字节的时间约87微秒，如果定时器中断刚好在串口字节到达时触发，且优先级更高，串口中断会被推迟，硬件接收寄存器可能被下一个字节覆盖，字节就丢了。
排查过程很痛苦：一开始偶尔丢帧，我把串口波特率降下来，现象减轻但偶尔还会出现。后来用示波器对比了串口接收引脚和定时器触发信号，终于看到了中断抢占的时间窗口。解决办法：把串口接收中断的抢占优先级调到最高（0），定时器中断设为1，确保没有其他中断能延迟串口字节接收。这个坑特别推荐大家提前规避，用CubeMX配置NVIC时，UART接收中断优先级的设置一定要高于一切非关键中断。
5.5 温湿度传感器读取值与手边仪表对不上
这个问题其实不是代码问题，但属于联调阶段必然遇到的。传感器输出的电压和温湿度的换算曲线，芯片手册上给的是近似公式，实际每个传感器个体都有偏差。我做了一个简单的软件校准：用冰水混合物和沸水做两个标准温度点，分别读ADC初始值，然后做线性插值。具体做法是在Sensor类里增加两个校准系数字段，通过串口命令在线更新，更新后写入Flash保存。
class Sensor { public: void setCalibration(float offset, float scale) { _offset = offset; _scale = scale; } float readCelsius() { float raw = _adc.readVoltage(); return (raw - _offset) * _scale; } private: float _offset; float _scale; };这套方法虽然不是高精度计量级的方案，但对环境监测这种应用来说足够了。校准系数存Flash里，这样换板子也不用重新烧固件，对量产和维护非常友好。
6. 从工程角度再聊几句：C++嵌入式项目的组织心得
6.1 内存分配策略：只在初始化时new
C++的new和delete在嵌入式环境里是危险操作。频繁堆分配会导致碎片化，长时间运行系统内存越来越少，最终malloc失败，程序崩溃。我的策略是整个系统只在启动时做一次堆分配，把传感器对象、存储对象、通信对象全部用new创建一次，之后永不释放。本质上做的是“启动即定型”的静态对象池思路，跟C语言的静态变量异曲同工，但保留了C++的构造和析构逻辑，代码更清晰。
如果你实在需要动态分配，强烈建议实现一个固定大小的内存池，或者使用嵌入式C++里常用的pmr多态分配器思想，把std::vector的分配器指定成一块静态数组空间。这样虽然不能完全避免碎片化，但至少可控。
6.2 把状态机、回调、配置分离
整个工程入口函数现在长这样：
int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); MX_USART1_Init(); SSD1306 display(&hi2c1); Sensor tempSensor(&hadc1); FlashStorage storage(FLASH_DATA_BASE, 4096); UartProtocol proto(&huart1); AppConfig config; config.loadFrom(storage); proto.registerHandler(0x02, [&](const uint8_t* data, uint8_t len) { config.setThreshold(data[0]); storage.saveConfig(config); }); while (1) { proto.processIncoming(); tempSensor.update(); float t = tempSensor.readCelsius(); if (t > config.threshold() && !config.fanRunning()) { config.fanRunning(true); } display.drawString(0, 0, "Temp: "); // ... 省略界面组装代码 display.display(); LL_mDelay(100); } }这种组织方式的优点是“每一行都知道自己在干嘛”。配置对象隔离出来，业务逻辑只跟配置打交道，不直接操作Flash和串口。后续要加个Wi-Fi模块或者蓝牙，只改UartProtocol和命令分发部分，传感器、存储、显示层完全不用动。
6.3 编译选项和警告等级
最后说一下编译工程设置。我用CMake管理工程，编译选项如下：
target_compile_options(${PROJECT_NAME} PRIVATE -mcpu=cortex-m3 -mthumb -Os -ffunction-sections -fdata-sections -Wall -Wextra -Wshadow -Wconversion -Wunreachable-code -fno-exceptions -fno-rtti )-fno-exceptions和-fno-rtti是嵌入式C++的标准操作——异常支持和运行时类型识别会显著增加代码体积和栈开销，在一个64KB Flash的芯片上没必要开。-Wconversion强制检查隐式类型转换，能提前抓出一堆浮点转整数的溢出问题。-Os优化为了代码体积，配合-ffunction-sections让链接器把未使用的函数剥掉，最终固件体积可以压缩很多。
这套组合拳打完之后，编译输出没有任何warning，这很重要。我见过很多人在嵌入式工程里无视warning，结果一个隐蔽的符号截断问题在生产现场炸了。在资源受限的MCU上，每个warning都值得认真对待，因为它们往往意味着未定义行为或数据溢出。
收尾的一点经验之谈
到这里，这个基于STM32的C++小型环境监测站就完整了：从传感器的模拟量采集，到数据处理和阈值判断，再到OLED显示、Flash持久化、串口通信，整个链路打通，设备已经具备基本的现场运行能力。实事求是地说，前5篇的框架加上这一篇的三块功能，前后大概花了一个多月的业余时间，中间踩的坑数量比预期多不少，但每一步踩坑都对应一个真实的工程经验。
我个人操作下来最大的体会是：C++在嵌入式里的价值不是语法花哨，而是“边界清晰”。类的封装把硬件初始化和业务逻辑隔离，状态机关在类内部，外部根本不需要知道协议怎么解析；RAII把资源所有权管起来，避免了一个指针到处飞的野路子。这套代码如果改用C写，大概率会退回到一堆全局变量加散落各处的中断处理函数，调试时心智负担会重很多。
最后再分享一个小技巧：联调阶段务必用逻辑分析仪或者示波器，不要只盯着串口调试助手里的字符串猜。I2C波形、UART波形、中断抢占时序，这些用眼睛肉眼确认一次，比在代码里加一千行printf都有用。工具到位，调试效率翻倍。后续如果还想继续扩展，这个框架可以往LoRa组网方向走，传感器数据上云也别急着换Linux板子，单片机加个4G模块照样能干，前提是你把存储和通信这两层抽象做好。
