前言说句实话做嵌入式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也就是一帧数据要约90msSPI接口下这个时间能压到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但我们选用的中容量芯片每页是1KB64KB版本分成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(temp25.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::functionvoid(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::mapuint8_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占用约58KBRAM占用约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 内存分配策略只在初始化时newC的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 -mcpucortex-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模块照样能干前提是你把存储和通信这两层抽象做好。
