Awes0meE / 66CCFF LabXJTLU Undergraduate西交利物浦大学本科生
Back to notes返回笔记

2026-05-06

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

Notes on reorganizing the external unit firmware into App, Service, BSP, Core, CMake, VSCode, OpenOCD, and release artifacts.STM32 外机固件整理笔记:压缩机、电子膨胀阀、NTC、DHT22、OLED、编码器和按键逻辑分层,并补齐 CMake、VSCode、OpenOCD 和发布说明。

STM32FirmwareCMakeBSP
Related Project相关项目Juanyun Thermal Management Hardware and Firmware Archive卷云科技热管理硬件与固件开发档案

Starting Point起点

At first glance, the external-unit firmware looked like a typical STM32 project: CubeMX generated a Core folder, then features slowly accumulated in the main loop. The problem was that once enough functions were added, the main loop would turn into a large knot. Compressor logic, FG speed sensing, electronic expansion valve control, NTC, DHT22, OLED, encoder, and keys can run for a short while if they are all mixed together, but they are hard to maintain for long.

外机固件这部分一开始看起来就是典型 STM32 工程:CubeMX 生成一堆 Core,然后主循环里慢慢加功能。问题是功能一多,主循环就会变成大杂烩。压缩机、FG 测速、电子膨胀阀、NTC、DHT22、OLED、编码器、按键,如果全部糊在一起,短期能跑,长期一定难维护。

它更像一套联调用的 STM32 平台:要能烧录,要能看懂任务节拍,要能改接口和显示内容。很多逻辑还不到最终产品的细致程度,但已经足够暴露一个问题:如果没有分层和简单文档,换台电脑或换个人维护都会很痛苦。

Layering分层

The project was organized into Core, App, Service, and BSP_drivers. This was not for architectural vanity; it was to prevent future debugging from becoming a file search. Low-level drivers stay low-level, scheduling stays in the application layer, and UI refreshes or sensor updates should not contaminate one another.

工程被拆成 CoreAppServiceBSP_drivers 几层。这样做不是为了显得架构高级,而是为了防止以后找代码找疯。底层驱动归底层,业务调度归业务,UI 刷新和传感器更新也不要互相污染。

为什么还要折腾 VSCode + CMake + OpenOCD,CubeIDE 不能用么?

CubeIDE 当然能用,但只依赖一个 IDE 会让工程交接很脆弱。换一台电脑、换一个人、换一个工具链,可能就又要从零开始。CMake、OpenOCD、README、PINOUT 和 release notes 的意义很直接:把“怎么编、怎么烧、引脚在哪、改过什么”写出来。

Task Rhythm任务节拍

The firmware also needed a visible timing rhythm, because each peripheral has a different 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 page only records the firmware structure and debugging direction. The README, PINOUT, .ioc, release notes, and .c sources stay in the private archive for now and are not offered as website downloads.

页面只写固件结构和调试思路。README、PINOUT、IOC、release notes 和 .c 源码暂时留在私有归档里,不从网站提供下载。

Notes To Add Later后面要补

The most useful follow-up 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. Compared with simply saying "I can use STM32," these small records show how the firmware was actually brought up.

这条线后面最该补烧录截图和调试日志,比如 OpenOCD 连接、OLED 刷新前后、DHT22 读取失败时的处理、电子膨胀阀步进节拍。比起只写“会 STM32”,这些小记录更能说明固件到底怎么被调起来。