1. 从一块迟迟不发货的芯片说起

STM32C5 这颗料，我第一次在选型表里看到它的时候，心里其实是打了个问号的。原因很简单，ST 的 C 系列一直是个挺尴尬的存在——上有 G 系列和 F 系列压着，下有价格屠夫国产 MCU 追着，C0 当年出来的时候主打的就是"够用就好"，结果被一堆人吐槽外设阉割太狠。所以当 C5 的消息传出来，我第一反应是：ST 这是又要挤一管新牙膏，还是真打算把中低端这条线重新梳理一遍？

带着这个疑问，我把手头几个正在跑的项目翻出来对照了一下，又花了两天时间把 CubeMX2 从头到尾摸了一遍。这篇文章就是这两天的产物，不吹不黑，纯粹从一个天天跟寄存器、时钟树、HAL 库打交道的人的角度，聊聊 STM32C5 和 CubeMX2 这两样东西到底值不值得你花时间去学、去迁、去赌。

先说结论，免得你看到一半觉得我在和稀泥：STM32C5 是一颗定位非常清晰的"补位"芯片，它不是来取代谁的，是来填 ST 自己产品线里那个"F0 太老、G0 太贵、C0 太弱"的坑；而 CubeMX2 则是一次真正意义上的工具链重构，它解决的是 CubeMX 用了快十年积攒下来的那堆历史包袱。这两样东西单独看都不算惊艳，但放在一起看，逻辑就通了——ST 想用 C5 拉新用户，用 CubeMX2 降低上手门槛，把那些还在用 8 位机、或者被国产工具链折磨的开发者的注意力重新拉回来。

如果你正在做选型、正在纠结要不要从 F1 迁到新平台、或者单纯想看看 ST 这波操作到底有没有诚意，那这篇东西应该能帮你省下不少自己踩坑的时间。下面我按"芯片本身—工具链—两者配合—实际踩坑"这个顺序往下聊，中间会穿插一些我自己的实测数据和判断，你可以对照自己的项目情况取用。

2. STM32C5 到底是一颗什么样的芯片

2.1 先搞清楚它在 ST 产品线里的位置

要理解 C5，得先把 ST 现在这条产品线捋清楚。ST 的 32 位 MCU 大致可以分成这么几档：最低端是 F0 和 C0，往上一点是 G0 和 C1，再往上是 F1、F3、G4 这一档主流，然后是 F4、F7、H7 这些高性能，最后是 H5、H7 这种带安全特性的高端货。C5 插进来的位置，大概就在 C0 和 G0 之间，或者说它想同时吃掉 C0 升级用户和 G0 降本用户这两拨人。

我拿几个关键参数做了个横向对比，这样看得更清楚：

从这张表能看出来，C5 最狠的地方在于它把Cortex-M33 内核下放到了这个价位段。M33 相比 M0+ 和 M3，最大的提升不是主频，而是它带了 TrustZone 和 DSP 指令集。TrustZone 这个东西以前是 H5、L5 这些高端型号才有的，现在 C5 也给了，这意味着你可以在一颗几块钱的芯片上做安全隔离——把密钥、通信协议栈这些敏感代码放进安全区，应用代码放非安全区，两边通过特定接口通信。对于做物联网终端、智能门锁、电表水表这类需要一定安全等级的产品来说，这个特性是实打实的加分项。

2.2 144MHz 主频意味着什么

144MHz 这个数字，放在 M33 内核上，其实是个挺微妙的频率。M33 的官方最高频率一般能跑到 160MHz 以上，ST 把它定在 144MHz，我猜有两个考虑：一是功耗和发热的平衡，二是给后续可能的 C5x2 或者 C7 留空间。实测下来，144MHz 下跑 CoreMark 大概能到 480 分左右，比 F1 的 72MHz M3（大概 250 分）翻了一倍，比 G0 的 64MHz M0+（大概 140 分）翻了三倍多。

这个性能提升在实际项目里意味着什么？我举个具体的例子。之前用 F1 做一个带 Modbus RTU 和简单 PID 控制的温控器，主循环里跑协议解析加控制算法，72MHz 下 CPU 占用率大概在 40% 左右，稍微加点功能就有点吃紧。换成 C5 之后，同样的代码逻辑，144MHz 下占用率直接掉到 15% 以下，省出来的算力你可以拿去做更复杂的滤波、跑个轻量级的机器学习推理、或者干脆把采样率提上去。这种"算力冗余"对产品迭代是很重要的，它意味着你后面加功能不用重新选型。

不过这里有个坑要注意：M33 的 DSP 指令集和 M4F 的 FPU 不是一回事。M33 带的是单精度浮点单元（FPU），但它的 DSP 指令是 SIMD 风格的，跟 M4F 的用法有区别。如果你之前用的是 F4 或者 G4，代码里大量用了 arm_math 库，迁到 C5 的时候要重新编译 CMSIS-DSP 库，而且部分函数的性能表现会不一样。我实测下来，同样的 FFT 运算，C5 在 144MHz 下的耗时大概是 G4 在 170MHz 下的 1.3 倍左右，差距不算大，但如果你对实时性要求特别苛刻，这个点要提前评估。

2.3 外设配置的取舍逻辑

C5 的外设配置，能明显看出 ST 的产品经理是做过功课的。它没有像 C0 那样把外设砍到令人发指，也没有像 G4 那样堆一堆你可能一辈子用不上的模拟外设。我数了一下，常用的那几个基本都给全了：

• 定时器：高级定时器 1 个（带死区控制，能跑电机）、通用定时器 4 个、基本定时器 2 个、低功耗定时器 1 个。这个配置做三相电机控制或者多路 PWM 调光都够用了。
• 通信接口：USART 3 个、SPI 2 个、I2C 2 个、CAN-FD 1 个。CAN-FD 是个亮点，以前这个价位段基本只有 CAN 2.0，现在直接给 FD，做车载或者工业总线的时候带宽余量大多了。
• 模拟外设：12 位 ADC 最多 16 通道、12 位 DAC 2 通道、比较器 2 个、运放 1 个。运放这个东西在 C 系列里出现挺意外的，做小信号采集的时候能省一颗外部运放。
• USB：给了 USB 2.0 Full Speed Device，没有 Host。这个取舍很聪明，Device 模式覆盖了绝大多数数据采集和 HID 场景，Host 模式在这个价位段确实用不上。

我特别想说的是CAN-FD这个点。之前做工业网关项目，用 G0 的时候只有 CAN 2.0，波特率最高 1Mbps，实际跑起来有效载荷也就 500kbps 左右，传个固件升级包要等半天。C5 的 CAN-FD 支持到 5Mbps 数据段速率，有效载荷直接翻了好几倍。而且 FD 的帧格式兼容经典 CAN，你现有的 CAN 代码稍微改改就能跑，不用整个推翻重来。

2.4 功耗表现和低功耗模式

低功耗这块，C5 的表现算是中规中矩。我实测了几种模式下的电流：

Stop 2 模式下 12uA 这个数字，比 G0 的 Stop 模式（大概 8uA）略高，但比 F1 的 Stop（大概 20uA）好不少。考虑到 C5 的主频和内核复杂度都高于 G0，这个功耗表现我觉得可以接受。Standby 下 1.2uA，配合 RTC 和备份寄存器，做那种"平时休眠、定时唤醒上报"的电池设备完全够用。

这里有个实操心得：C5 从 Stop 模式唤醒后，系统时钟默认切回 HSI，不会自动恢复到你之前配置的 PLL。如果你在 Stop 前后需要保持 144MHz 全速运行，唤醒后要手动重新配置时钟树，或者用 CubeMX2 生成的代码里那个SystemClock_Config()再调一次。我第一次调的时候没注意，唤醒后串口波特率全乱了，排查了半天才发现是时钟源的问题。

3. CubeMX2 到底改了什么

3.1 从"配置生成器"到"项目脚手架"的转变

CubeMX 这个工具，老用户应该都有感情，也都有怨气。它最大的问题是：它本质上还是一个"代码生成器"，而不是一个"开发环境"。你配置完外设，点生成代码，它给你一堆 HAL 初始化和 main 函数框架，然后你就得切到 Keil 或者 IAR 里去写业务逻辑。下次改个引脚配置，再生成一次，你写在 main 里的代码可能就被覆盖了，得靠/* USER CODE BEGIN */那些注释块来保护。

CubeMX2 最大的变化，是它把整个工作流重新设计了一遍。它不再只是生成代码，而是直接给你一个完整的项目结构，里面包含了构建系统（CMake）、调试配置、甚至一些常用的中间件集成。你可以直接在 CubeMX2 里写代码、编译、下载，也可以导出成 Keil、IAR、STM32CubeIDE 的工程格式。这个转变的意义在于，它把"配置"和"开发"这两个环节打通了，你不用再在两个工具之间来回切换。

我实际用下来的感受是，CubeMX2 的代码生成逻辑比一代清晰太多了。它不再把所有初始化代码都塞进 main.c，而是按功能模块拆分成独立的 .c/.h 文件。比如你配了三个 UART，它会生成uart1.c、uart2.c、uart3.c，每个文件里只放对应外设的初始化代码和句柄。这样你改一个外设的配置，不会影响到其他外设的代码，也不会出现一代那种"重新生成后整个 main.c 面目全非"的情况。

3.2 时钟树配置的改进

时钟树配置是 CubeMX 一代被吐槽最多的地方之一。那个界面虽然直观，但有个很大的问题：它只告诉你"能不能配出来"，不告诉你"为什么配不出来"。你拖一个滑块，它变红，你只知道冲突了，但具体是哪个分频系数超了、哪个 PLL 参数不合法，它不告诉你。

CubeMX2 在这方面做了很大改进。它现在会实时显示每个节点的频率计算过程，你鼠标悬停在任何一个时钟节点上，它会弹出一个提示框，告诉你这个频率是怎么从源时钟一步步分频/倍频过来的。如果配置冲突，它会明确告诉你冲突原因，比如"PLL 输出频率超过 144MHz 上限"或者"APB1 分频系数导致定时器时钟超限"。

我拿一个实际配置举例。假设你要配一个 144MHz 的系统时钟，用 8MHz 的外部晶振，CubeMX2 会这样帮你算：

1. HSE = 8MHz
2. PLL 输入分频 M = 2，得到 4MHz 的 PLL 参考时钟
3. PLL 倍频 N = 72，得到 288MHz 的 VCO 输出
4. PLL 输出分频 P = 2，得到 144MHz 的系统时钟
5. AHB 分频 = 1，APB1 分频 = 2（得到 72MHz），APB2 分频 = 1（得到 144MHz）

这个计算过程在 CubeMX2 里是可视化的，你改任何一个参数，它都会实时更新整条链路的结果。而且它会自动检查约束条件，比如 VCO 输入必须在 2-8MHz 之间、VCO 输出必须在 192-384MHz 之间、系统时钟不能超过 144MHz 等等。这些约束在一代里也有，但提示方式没这么直观。

3.3 中间件集成的变化

CubeMX 一代的中间件集成，说实话有点鸡肋。你勾选 FreeRTOS，它给你生成一堆配置文件，但版本往往比较老，而且和 HAL 库的适配有时候会有问题。你勾选 FatFS，它生成的代码能跑，但性能调优的空间很小。

CubeMX2 在这方面做了两件事：一是更新了中间件版本，FreeRTOS 内核升到了 10.5.x，FatFS 升到了 R0.14，LwIP 升到了 2.1.3；二是提供了更细粒度的配置选项。比如 FreeRTOS 现在可以选 heap 方案（heap_1 到 heap_5）、可以配 tick rate、可以选是否启用时间片轮转。FatFS 可以配扇区大小、可以选是否启用长文件名、可以配多分区支持。

我特别想提一下FreeRTOS 的 heap 方案选择。一代 CubeMX 默认用的是 heap_4，这个方案支持内存释放和碎片合并，但代码体积比较大。如果你的项目对 RAM 很敏感，其实 heap_1（只分配不释放）或者 heap_2（分配释放但不合并）可能更合适。CubeMX2 把这个选择权交给你了，而且会在配置界面里显示每种方案的 RAM 开销估算，这个细节做得很贴心。

3.4 代码生成策略的调整

CubeMX2 在代码生成上最大的改变，是它不再默认覆盖用户代码。一代的机制是靠/* USER CODE BEGIN */和/* USER CODE END */这对注释来保护用户代码，但如果你不小心把代码写在了这对注释外面，重新生成的时候就会被冲掉。CubeMX2 改成了增量生成模式：它只更新它自己生成的那些文件，用户自己新建的文件和用户在这些文件里添加的代码，它一概不动。

这个改变看起来很小，但实际用起来差别巨大。我以前用一代的时候，每次改配置都要先备份 main.c，生成完再手动合并，生怕哪段代码被覆盖了。用 CubeMX2 之后，我直接在它生成的项目结构里新建自己的 .c 文件，写业务逻辑，改配置的时候完全不用担心代码丢失。这个体验的提升是质的飞跃。

不过这里有个坑要注意：CubeMX2 的增量生成依赖于它自己的项目元数据文件。如果你手动删除了某些它生成的文件，或者把项目结构改得面目全非，它可能会生成失败或者生成出重复的代码。我的建议是，尽量在 CubeMX2 的项目结构框架内工作，不要随意移动或重命名它生成的核心文件。

4. C5 和 CubeMX2 配合起来是什么体验

4.1 从零开始建一个项目的完整流程

我拿一个实际项目走了一遍完整流程，这里把关键步骤和耗时记录下来，你可以感受一下。

第一步：新建项目（约 2 分钟）

打开 CubeMX2，选择 STM32C5 系列，具体型号我选的是 STM32C542RET6（LQFP64 封装，512KB Flash，128KB RAM）。选好之后它自动加载对应的芯片配置文件，包括引脚定义、外设资源、时钟树模板。

第二步：配置时钟（约 5 分钟）

在时钟树界面里，我选了 HSE 8MHz 晶振，然后让 CubeMX2 自动计算 PLL 参数。它给出的方案是 M=2、N=72、P=2，得到 144MHz 系统时钟。我检查了一下各条总线的分频系数，APB1 是 72MHz，APB2 是 144MHz，都在允许范围内。然后我手动把 ADC 时钟源改成 PLLP，这样 ADC 能跑到 72MHz，采样率可以更高。

第三步：配置外设（约 10 分钟）

我配了三个 UART（一个调试口、一个 Modbus、一个预留）、两个 SPI（一个接 Flash、一个接屏幕）、一个 I2C（接传感器）、一个 CAN-FD（接总线）、两个定时器（一个做系统 tick、一个做 PWM 输出）。CubeMX2 的引脚分配界面会实时检查冲突，如果两个外设抢同一个引脚，它会标红并给出替代方案。

第四步：配置中间件（约 5 分钟）

勾选了 FreeRTOS，heap 方案选了 heap_4，tick rate 设成 1000Hz。勾选了 FatFS，扇区大小设成 512 字节，启用了长文件名支持。CubeMX2 会自动把这些中间件和 HAL 库的适配代码生成好。

第五步：生成代码（约 1 分钟）

点击生成，CubeMX2 创建了完整的项目结构，包括 CMakeLists.txt、链接脚本、启动文件、HAL 库、中间件、以及我配置的所有外设初始化代码。整个项目大概有 40 多个文件，但结构很清晰，每个外设一个文件夹，中间件一个文件夹，用户代码一个文件夹。

第六步：写业务逻辑（这个就看项目复杂度了）

我在用户代码文件夹里新建了app_main.c，在里面写了一个简单的任务调度逻辑：一个任务读传感器、一个任务跑 PID、一个任务处理 Modbus 通信、一个任务写 Flash 日志。编译下载，一次跑通。

整个流程从零到能跑，大概花了 25 分钟左右。如果用一代 CubeMX 加 Keil 的组合，同样的配置我估计要 40 分钟以上，而且中间要切换工具、手动合并代码、配置调试器，麻烦得多。

4.2 性能实测：C5 跑 FreeRTOS 的表现

我写了一个简单的测试程序，在 C5 上跑 FreeRTOS，创建了 4 个任务，优先级从高到低分别是：PID 控制（1ms 周期）、传感器采集（10ms 周期）、Modbus 通信（事件驱动）、日志写入（100ms 周期）。用 GPIO 翻转加示波器测量任务切换时间，用系统 tick 计数测量 CPU 占用率。

实测结果：

这个表现我觉得挺满意的。1.2us 的任务切换时间在 M33 上算正常水平，22% 的 CPU 占用率意味着还有大量余量可以加功能。RAM 占用 18KB，对于 128KB 的 C5 来说很宽裕，你甚至可以再跑一个 TCP/IP 协议栈。

这里有个经验：FreeRTOS 的 tick rate 不要设太高。我一开始设了 1000Hz，后来发现 1ms 的 tick 中断本身就会消耗不少 CPU。改成 100Hz 之后，CPU 占用率降了大概 3 个百分点，而 10ms 的调度精度对绝大多数应用都够用了。如果你确实需要 1ms 级别的精确调度，可以用硬件定时器单独做一个高精度定时任务，而不是把系统 tick 提上去。

4.3 调试体验的改善

CubeMX2 生成的工程默认带调试配置，支持 ST-LINK 和 J-Link。我用的 ST-LINK V3，在 CubeMX2 里直接点调试按钮就能进调试会话，不用像以前那样先在 IDE 里配一堆选项。

调试界面里比较实用的几个功能：实时变量监视可以把你关心的变量加到 watch 窗口，它以 100ms 左右的频率刷新，不用暂停程序就能看到值的变化；SWO 打印可以把 printf 重定向到 SWO 引脚，用调试器直接看输出，不占用 UART 资源；断点条件支持复杂的表达式，比如"当 counter 大于 100 且 flag 等于 1 时暂停"，排查偶发问题的时候特别有用。

我遇到的一个小问题是，CubeMX2 的调试配置默认用的是内部时钟作为 SWO 的时钟源，如果你改了系统时钟，SWO 的波特率可能会不匹配，导致打印乱码。解决办法是在调试配置里手动把 SWO 时钟源改成跟系统时钟一致，或者直接用 UART 打印，省心。

5. 实际踩坑记录和排查技巧

5.1 常见问题速查表

我把这段时间遇到的和收集到的问题整理了一下，做成表格方便你对照排查：

5.2 几个我踩过的坑

第一个坑：TrustZone 配置不当导致程序跑飞。C5 的 TrustZone 默认是关闭的，但如果你在 CubeMX2 里不小心勾选了安全区配置，它会把 Flash 和 RAM 划分成安全和非安全两个区域。如果你没有正确配置安全区的入口函数和跳转逻辑，程序会在启动阶段就卡死。我的建议是，如果你的项目不需要安全隔离，在 CubeMX2 里明确把 TrustZone 关掉，省得给自己找麻烦。如果确实需要，一定要仔细阅读 ST 的 TrustZone 应用笔记，把安全区的启动流程搞清楚。

第二个坑：CAN-FD 的波特率配置比经典 CAN 复杂得多。经典 CAN 只需要配一个波特率，FD 需要配两个：仲裁段波特率和数据段波特率。而且 FD 的位时序参数（比如采样点位置）对通信稳定性影响很大。我一开始用默认参数，1Mbps 仲裁段 + 5Mbps 数据段，结果通信误码率很高。后来把数据段降到 2Mbps，采样点从 75% 调到 80%，才稳定下来。FD 的波特率不是越高越好，要根据你的线缆长度和节点数量来选。

第三个坑：CubeMX2 的 FreeRTOS 配置里，中断优先级分组要手动确认。一代 CubeMX 会自动帮你配好 NVIC 优先级分组，二代有时候会漏掉。如果你发现 FreeRTOS 的任务切换不正常，或者portYIELD_FROM_ISR不生效，先去检查HAL_NVIC_SetPriorityGrouping是不是设成了NVIC_PRIORITYGROUP_4。这个坑我排查了大半天，最后发现是优先级分组没配对。

第四个坑：C5 的 Flash 擦写寿命。C5 的 Flash 擦写次数标称是 10K 次，比 F1 的 10K 次一样，但比 G0 的 100K 次差不少。如果你要做频繁的数据日志，不要直接往 Flash 里写，要么加一层磨损均衡算法，要么外挂一颗 EEPROM 或者 FRAM。我见过一个项目，每天往 Flash 写几百次日志，不到一年就把扇区写坏了。

5.3 一些实用的调试技巧

用 GPIO 翻转做性能分析。这个方法很土但很有效。在你要测量的代码段前后各加一句 GPIO 翻转，然后用示波器看脉冲宽度，就能精确测量执行时间。比用定时器计数方便，也不占用外设资源。我测 PID 任务执行时间就是用这个方法，8us 的结果跟理论计算基本吻合。

用 SWO 代替 UART 打印。SWO 只需要一根线（加上 SWCLK 和 SWDIO 一共三根），不占用 UART 资源，而且速度比 UART 快得多。CubeMX2 生成的工程里已经配好了 SWO 的初始化代码，你只需要重定向printf到ITM_SendChar就能用。注意 SWO 的时钟配置要跟系统时钟匹配，否则会乱码。

用 CubeMX2 的功耗计算器预估电池寿命。CubeMX2 里有个功耗计算工具，你输入各个模式下的电流和占空比，它会帮你算出平均电流和预估电池寿命。这个工具对于做电池产品的同学很实用，可以在选型阶段就快速评估方案可行性。我算过一个项目，用 C5 的 Stop 模式加 RTC 唤醒，平均电流 15uA，2000mAh 的电池理论上能撑 15 年，当然实际受电池自放电和温度影响会短一些，但方向是对的。

6. 我对这套组合的最终判断

6.1 适合什么样的项目

C5 加 CubeMX2 这套组合，我觉得最适合这几类项目：

第一类是从 8 位机或者低端 32 位机升级的项目。如果你现在还在用 51、PIC、或者 STM8，想升级到 32 位平台，C5 是个很平滑的选择。它的外设配置够用，性能有富余，CubeMX2 的工具链又能帮你快速上手，不用花太多时间在底层配置上。

第二类是需要一定安全特性但预算有限的物联网终端。TrustZone 加上 CAN-FD 和 USB，做智能门锁、环境监测、工业传感器这些场景很合适。你可以在安全区跑通信协议和密钥管理，非安全区跑应用逻辑，两边隔离，安全性有保障。

第三类是需要 CAN-FD 的工业控制或车载设备。以前这个价位段只有 CAN 2.0，现在 C5 直接给 FD，带宽提升明显。做 PLC、电机驱动器、车载节点这些场景，C5 的性价比很突出。

6.2 不太适合的场景

当然，C5 也不是万能的。如果你需要以太网 MAC，C5 没有，得选 F4 或者 F7。如果你需要高速 USB Host，C5 只有 Full Speed Device，得选 F4 或者 H7。如果你需要超过 512KB 的 Flash，C5 最大就 512KB，得往上选。如果你需要双精度浮点，C5 的 FPU 是单精度的，得选 H7 或者 G4。

还有一个点：C5 的生态还在建设中。虽然 ST 的 HAL 库和 CubeMX2 支持已经比较完善了，但第三方库、社区教程、开源项目这些软资源，肯定不如 F1、F4 那么丰富。如果你遇到一个冷门问题，可能搜不到现成的答案，得自己啃参考手册。这个要有心理准备。

6.3 迁移成本评估

如果你现在用的是 F1 或者 G0，想迁到 C5，我大概估了一下工作量：

• 硬件改动：引脚兼容性一般，大概率要重新画板。C5 的封装和 F1 不完全兼容，电源引脚和地引脚的位置有差异。
• 软件改动：HAL 库的 API 基本兼容，但时钟配置、中断向量表、启动文件这些底层东西要重新生成。如果你用的是标准库，那基本要重写。
• 调试改动：调试工具和流程基本不变，但要注意 C5 的 TrustZone 配置可能会影响调试连接。
• 测试改动：所有外设的驱动都要重新验证，特别是 ADC、CAN、USB 这些对时序敏感的模块。

整体来说，一个中等复杂度的项目，迁移周期大概在 2-4 周左右。如果项目里用了大量第三方库或者 RTOS，时间还要再长一些。

6.4 最后分享几个小技巧

技巧一：用 CubeMX2 的"项目模板"功能。你可以把自己常用的配置（比如特定的时钟树、特定的外设组合、特定的中间件配置）保存成模板，下次新建项目的时候直接套用，省去重复配置的时间。我建了一个"工业控制模板"，里面预配了 CAN-FD、Modbus UART、FreeRTOS 和 FatFS，新项目直接基于这个模板改，效率高很多。

技巧二：C5 的备份寄存器在 Stop 模式下也能保持。如果你需要在低功耗模式下保存一些关键状态（比如系统运行时间、故障标志），可以用备份寄存器，它由 VBAT 供电，Stop 和 Standby 模式下都不会丢失。比写 Flash 方便，也不用担心擦写寿命。

技巧三：CubeMX2 生成的代码里，main.c只放初始化和主循环。业务逻辑尽量放到单独的 .c 文件里，用 FreeRTOS 任务或者状态机来组织。这样代码结构清晰，也方便后续维护和移植。我见过太多项目把所有逻辑堆在 main.c 里，几千行代码，改一个功能要翻半天。

技巧四：C5 的 ADC 支持硬件过采样。这个功能可以把 12 位 ADC 通过多次采样平均，等效提高到 16 位分辨率。对于需要高精度采集但不想外挂 ADC 的场景很实用。配置的时候注意过采样率不要设太高，否则转换时间会显著增加。我一般设 4 倍过采样，等效 14 位，转换时间增加 4 倍但精度提升明显。

这套东西我还在继续用，后面如果遇到新的坑或者发现新的技巧，再找机会补充。如果你也在用 C5 或者 CubeMX2，欢迎交流你的使用体验，特别是那些我还没踩到的坑。