STM32 External Unit FirmwareSTM32 外机固件整理笔记

Starting Point起点

外机固件一开始看起来就是典型 STM32 工程：CubeMX 生成 Core，然后功能一点点往主循环里加。压缩机逻辑、FG 测速、电子膨胀阀、NTC、DHT22、OLED、编码器、按键，全都能先用最直接的方法塞进去，但时间一长主循环就会变成一团线。

At first glance, the firmware looked like a normal STM32 project: CubeMX generated Core, then functions accumulated in the main loop. Compressor logic, FG speed sensing, electronic expansion valve stepping, NTC, DHT22, OLED, encoder, and keys can all be added directly, but the loop quickly becomes tangled once several of them run together.

这条线更像一套联调用的 STM32 平台：要能烧录，要能看懂任务节拍，要能改接口和显示内容。很多逻辑还在早期阶段，但已经暴露了一个很实际的问题：如果没有分层和说明，换台电脑或换个人维护都会很痛苦。

This line felt like a bring-up platform. It needed flashing, readable task timing, interface changes, and display changes. Even before the logic became polished, it already showed why layering and short documents matter when the project moves across machines or people.

Layering分层

The project was organized into Core, App, Service, and BSP_drivers. The point was simple: low-level drivers stay low-level, scheduling stays in the application layer, and UI refresh or sensor update logic should have a place to live.

工程被拆成 Core、App、Service、BSP_drivers 几层。目的很直接：底层驱动归底层，任务调度归应用层，UI 刷新和传感器更新都要有自己的位置。

VSCode + CMake + OpenOCD 这一套也有类似作用。它把“怎么编译、怎么烧录、引脚在哪里、这个版本改过什么”写在 IDE 之外。CubeIDE 当然能跑，但只靠一个 IDE 的工程状态，交接和复现会变脆。

VSCode, CMake, OpenOCD, README, PINOUT, and release notes make the workflow visible outside one IDE. They record how to build, flash, find pins, and understand what changed between versions.

Task Rhythm任务节拍

The firmware needed a visible timing rhythm because each peripheral has its own natural update rate.

• 1 ms task: electronic expansion valve step control.
• 10 ms task: FG maintenance, encoder/key scanning, and UI input.
• 100 ms task: NTC temperature update.
• 500 ms task: OLED refresh.
• 2000 ms task: DHT22 temperature-and-humidity read.
• Skip OLED refresh when the content has not changed to reduce I2C traffic and unnecessary formatting.
• Change the NTC lookup from linear search to binary search; periodic tasks should waste less work wherever possible.

• 1 ms 任务用于电子膨胀阀步进控制。
• 10 ms 任务用于 FG 维护、编码器按键扫描和 UI 输入。
• 100 ms 任务用于 NTC 温度更新。
• 500 ms 任务用于 OLED 刷新。
• 2000 ms 任务用于 DHT22 温湿度读取。
• OLED 内容不变时跳过刷新，少一点 I2C 传输和无意义格式化。
• NTC 查表从线性搜索改成二分搜索，周期任务里能少耗一点就少耗一点。

File Handling文件处理

This note explains the firmware structure and debugging direction. The README, PINOUT, .ioc, release notes, and .c sources stay in the private project archive for now.

页面只写固件结构和调试思路。README、PINOUT、IOC、release notes 和 .c 源码暂时留在私有项目归档里。

Notes To Add Later后面要补

The most useful follow-up records would be flashing screenshots and debugging logs: OpenOCD connection, OLED refresh before and after optimization, DHT22 read-failure handling, and the stepping rhythm of the electronic expansion valve.

这条线后面最该补烧录截图和调试日志，比如 OpenOCD 连接、OLED 刷新前后、DHT22 读取失败时的处理、电子膨胀阀步进节拍。

Looking back, the lesson here is practical: firmware structure starts to matter as soon as several slow and fast tasks share one board. If the rhythm is clear, later debugging has something to hold onto.

现在回头看，这条线给我的提醒很实际：只要快慢不同的任务开始共用一块板，固件结构就会变重要。节拍写清楚，后面调试才有东西可抓。