企业官网建设流程全解析

STM32C5这个新系列出来之后，问我的人一直不少。它和常见的F系列、G系列最明显的区别，就是内核换成了Cortex-M33，主频拉到150MHz，还带了TrustZone和硬件加解密，起步价格又压得比较低。对做便携设备、工业传感器、智能家居网关的开发者来说，这颗芯片确实值得认真看一眼。这篇就把我实际开发C5的过程完整串一遍：从搭环境、用CubeMX生成工程，到外设初始化、低功耗设计，再到最后调试踩坑，全流程过一遍。适合刚开始接触C5的人，也适合想从F系列迁移过来的朋友做个横向参考。

1. 先搞清楚C5是什么定位，再决定要不要用它

1.1 C5和F系列、G系列到底差在哪

我最早看到C5的资料时，第一反应是“这不就是G系列换个内核吗”，但实际用下来发现并不是简单升级。它最大的变化是内核从Cortex-M4换成了Cortex-M33，主频最高可以到150MHz，双精度浮点、DSP指令都有。M33和M4相比，多了TrustZone安全扩展，也就是说这颗芯片天生就支持安全世界和非安全世界的隔离，这在中低端MCU里是个挺重要的卖点。

另一个关键差异是硬件加解密。C5系列集成了AES等加密模块，做安全通信、固件签名校验时，不再需要外挂一颗安全芯片，单颗MCU就能把加解密跑完。对成本敏感又需要一定安全等级的物联网设备来说，这是实打实的优势。存储方面，最高1MB Flash、512KB SRAM，这个容量区间覆盖了大多数传感器节点、电机控制、简单网关类应用。

外设配置也比较全，U(S)ART、SPI、I2C、ADC、DAC、比较器、LPTIM、FD-CAN、USB FS、SDMMC都有，几个常用封装也保留了足够的引脚数量。我拿它做过一个带CAN总线和以太网扩展口的小网关，资源和引脚都够用。

1.2 C5适合做哪类项目

我实际试下来，C5最适合的场景有三类。

第一类是电池供电的传感器节点。它提供了多种Stop模式，搭配LPTIM低功耗定时器，可以在微安级待机电流下定时唤醒采集数据。配合DSP指令，做一些简单的传感器滤波算法也不用开一颗DSP芯片。第二类是安全启动、固件加密敏感的设备，比如表计类、支付外设、加密通信网关。TrustZone可以把关键密钥放在安全世界里，非安全世界被攻破了也拿不到核心秘密。第三类是成本控制严格的工业现场板卡，需要CAN、UART等现场总线，又需要一定算力和安全能力，一颗C5基本能包圆。

当然它也不是万能的。如果你要做人机界面类产品，需要大容量Flash跑图形库，C5的资源还是会吃紧；如果你完全不需要安全特性和低功耗，那老F系列可能是更便宜的选择。我的建议是：先拿最小系统板跑一个外设全开的工程，测一下实际资源占用和功耗，再决定要不要全量迁移。

2. 开发环境搭建：从CubeMX到下载器连接

2.1 工具链选型，新手别一上来就纠结

C5的开发工具链其实很成熟了，主流的几套都能完美支持。我从实际体验出发，说说我自己的选择逻辑。

如果之前没用过STM32，或者只是个人做点小项目，强烈建议直接用官方那套基于Eclipse的IDE，名字就是STM32CubeIDE。它最大的好处是把CubeMX图形化配置、GCC编译链、调试器集成在一起，一个软件解决全部问题，不用自己折腾编译环境。打开软件，选芯片、配引脚、点生成代码，然后再回到同一个IDE里写逻辑、编译、下载，流程一气呵成，对新手特别友好。

如果之前主力是Keil MDK，也完全没问题，C5的Device Pack已经支持得很好。Keil的调试体验确实做得不错，在一些老工程师手里顺手度很高。还有IAR，在代码密度和优化方面一直口碑不错，量产经验也多。三套我都用过，最终日常开发我留在了CubeIDE，理由是省事，尤其团队协作时，工程文件格式统一，环境配置成本低。

提示：无论选哪个IDE，都建议把CubeMX装好。C5的引脚复用、时钟树配置、外设初始化代码生成，靠手写效率太低，出错的概率也大。

2.2 CubeMX配置C5的四个关键步骤

用CubeMX配置C5，流程上和其他STM32差不多，但有四个地方值得特别注意。

首先是型号选择。安装C5的固件包后，在CubeMX的MCU型号列表里可以按系列筛选。注意看型号后缀，不同的后缀对应不同的封装、Flash大小和引脚数。比如你看中的是48脚封装，还是64脚封装，直接从型号后缀和引脚图确认。我曾经因为没注意后缀，以为选了个64脚型号，实际拿到的是48脚，引脚规划全乱了。

第二步是时钟树配置。这是C5工程的灵魂。双击时钟树页面，可以看到RCC模块。如果要追求低功耗和精度，外部低速晶振LSE一定配上，它同时服务于低功耗定时器和RTC。外部高速晶振HSE按板上的实际频率填写，比如常见的8MHz。然后配置PLL参数，让系统时钟SYSCLK到150MHz。CubeMX会自动计算合法性，比如PLLM、PLLN、PLLP的值，它会用红色提示非法组合，你只要看着调就行。

第三步是外设和引脚规划。C5的引脚复用比老系列复杂一些，串口、定时器、ADC的通道映射要多对照几遍。比如我把USART1放在PA9/PA10，ADC通道放在PC0，LPTIM1的输入引脚也顺手配好。配置完引脚后，记得在GPIO设置里确认每个引脚的工作模式、上下拉、速度等级，这些直接影响外围电路表现。

第四步是生成工程前的设置。在Project Manager页面里选好IDE类型，设置堆栈大小。C5如果开了TrustZone，工程会细分为安全工程和非安全工程，这个后面单独说。默认情况下，先不开TrustZone，按普通MCU生成一个最小工程，把点亮LED这一步先跑通，后面再加安全特性。

2.3 下载调试时的接线和常见坑

C5的调试接口就是标准SWD，四根线：SWDIO、SWCLK、GND、3V3。ST-LINK是最省事的调试器，兼容性好，价格也便宜，个人开发完全够用。J-Link我也用过，稳定性和速度更好，如果做量产级调试，预算允许的话可以上。

接线这个环节看着简单，但踩坑的人特别多。一个常见问题是用杜邦线长距离连接调试器，超过10厘米就容易出现信号干扰，导致下载失败。我吃过不少亏，后来习惯把SWD线控制在5厘米左右，如果必须延长就用屏蔽线或者加粗线。

下载如果报找不到芯片，第一件事不是换调试器，而是检查芯片供电是否正常、复位引脚是否被外部电路拉住。还有一个很典型的坑：如果你写了一段程序，把SWDIO引脚复用成普通GPIO，第二次下载就会连不上芯片。这时候用CubeProgrammer或IDE里的Connect Under Reset选项，在芯片复位瞬间抢先把SWD连接抓住，然后执行整片擦除，就能恢复。具体操作就是在下载设置里勾选“Connect under Reset”，按住板子复位键不放，点击下载，等连接成功后再松开复位。

注意：拿到一块全新的C5板子，焊好后先别急着写代码，直接用CubeProgrammer连一下芯片，能读到Device ID就说明焊接和电源没问题，这能省掉后面一大半排查时间。

3. 开发前必须理解的三个核心细节

3.1 时钟路径和PLL计算，别等出了问题再补

很多从F系列转过来的人，会直接沿用老的时钟配置思路，这在C5上行不通。C5复位后默认运行在内部MSI振荡器上，这个MSI频率可调，但精度一般。要用串口、定时器这类对时序敏感的外设，最好切换到外部晶振或PLL锁相环出来的高频时钟。

时钟切换的逻辑其实不复杂，就是配置PLL分频倍频链路，把低频率的HSE放大到目标系统时钟。举个实际例子：如果板子上有8MHz外部晶振，想让SYSCLK跑到150MHz，可以设置PLLM=1（8MHz除以1），PLLN=150（倍频到1200MHz内部VCO），PLLP=8（再除以8，输出150MHz）。CubeMX会自动帮你验算这个组合是否在PLL的物理限制范围内。要理解的点是：PLL内部VCO有一个允许工作的频率范围，倍频过高或过低都会报错，CubeMX会提示，配置时跟着提示调整即可。

另一个容易被忽视的是Flash读取等待周期。内核频率高了之后，Flash访问速度跟不上，必须插入等待周期，否则程序会随机卡死甚至跑飞。CubeMX生成代码时会根据目标主频自动配好，但如果你在后续开发里手动改了PLL参数，记得重新去看一下Flash等待周期配置。我在调试一个I2C通信异常时，排查了半天，最后发现是改完主频后Flash等待周期没同步更新，导致指令偶尔取错，那个问题极其隐蔽。

时钟配置完成后，还有一个容易忽略的点：各个总线预分频关系。C5的AHB、APB1、APB2各自有最大允许频率，APB1通常比APB2低。定时器时钟在某些分频组合下会翻倍，比如APB1分频不为1时，定时器时钟是APB1频率的2倍。计算定时器溢出时间和PWM频率时，用错时钟频率会让整个设计都错位，所以我开发时习惯先把时钟树截图打印出来贴在工位上，对着写定时器代码。

3.2 TrustZone安全分区，对代码结构的影响比想象中大

C5的TrustZone是这颗芯片最具差异化的一点，但也是新手最容易翻车的地方。通俗点说，TrustZone就是把芯片内部的世界分成两个：安全世界和非安全世界。安全世界的代码可以访问所有外设和内存，非安全世界则只能访问被标记为非安全的区域。

如果开发时不需要安全特性，可以直接在CubeMX里不开启TrustZone，那C5就是一颗普通的M33芯片，开发体验和传统MCU没有区别。但如果开启了TrustZone，工程结构会变成多个工程：一个安全工程、一个非安全工程、一个描述分区配置的工程。安全工程编译出的固件负责启动、密码运算、安全存储等；非安全工程编译出的固件跑应用逻辑，但它不能直接访问安全外设和内存区域。

这个架构在实际开发中意味着什么？举个例子，你在安全世界里做好了一个AES加密函数，非安全世界想在通信时调用它，不能直接跳过去，而是要通过指定的非安全可调用的接口函数，并且这个函数要经过特殊编译和属性声明。中断向量表也会被拆分，安全中断和非安全中断各有各的向量。启动过程更复杂，先启动安全工程，再由安全工程跳转到非安全工程。

我个人的建议非常明确：第一步，先用非TrustZone模式把全部功能跑通，确认所有外设工作正常；第二步，再开启TrustZone，把安全需求细化，把密钥、加解密、安全标志这类内容抽到安全工程里。千万不要一开始就双工程模式开发，否则你连串口打印都可能被安全属性挡住，排查起来相当痛苦。我记得第一次开启TrustZone后，程序卡在某个外设初始化，报错提示是“访问未授权”，当时对安全属性不熟悉，查了一整天才明白那个外设默认还是安全属性，非安全代码根本碰不到。

3.3 HAL库还是LL库，C5上的选择策略

关于用HAL库还是LL库，开发社区里争论一直挺多。C5系列官方主推HAL库，CubeMX生成的代码也是HAL为主，但它在底层也提供了LL库的类似接口。我的看法是：HAL库是主开发路径，但低功耗和中断实时性要求高的地方，直接抄起寄存器或者LL接口来打补丁。

HAL库的优势是外设初始化逻辑完整，CubeMX生成后就能跑，出问题也好排查，因为它把大部分寄存器操作封装成了语义明确的函数。比如UART、ADC、定时器的初始化，HAL代码可读性明显好于寄存器操作。缺点是函数调用层级深，实时性差点，在频繁进出的低功耗场景里，HAL的功耗管理接口有时会显得“太重”。

C5的低功耗控制是个典型场景。HAL_PWR_EnterSTOPMode这类函数内部要做一系列检查，中断使能、时钟开关顺序、寄存器锁存，代码流程很长。如果你希望进入Stop模式的延时尽量短，这个延时可能就是百微秒级别和几十微秒级别的差别。这时候直接操作PWR寄存器和RCC寄存器，或者用LL库提供的轻量接口，会更直观高效。

我的做法是：工程主体用HAL，但在三个地方切到底层接口：一是低功耗模式进出切换，二是LPTIM唤醒配置，三是临界区的关中断保护。代码里用宏把底层操作封一下，看起来也不会乱。这样既保证了开发效率，又不牺牲关键性能。

4. 实战：做一个低功耗环境传感器节点

4.1 需求拆解和引脚规划

这部分用一个可以实际跑起来的案例来说话。我做一个电池供电的环境传感器节点，功能很简单：每10秒采集一次光照和温度，通过串口上报给网关，其他时间全部进入低功耗模式，尽量省电。

硬件上，C5最小系统板一块，一个模拟光敏传感器接到ADC引脚，一个数字温湿度传感器走I2C，还有一个USB转串口模块用于调试。正常情况下，温湿度传感器是I2C接口，接到C5的I2C1上，这里注意I2C引脚需要外部上拉电阻，板上没有的话要自己加两颗4.7K的电阻。

引脚规划是这样的：ADC1的通道分配到PC0，读取光敏电阻分压后的电压；I2C1放在PB6和PB7；USART1放在PA9和PA10；LPTIM1的输入引脚直接复用为内部时钟模式，不需要额外占用引脚。如果没有硬件I2C传感器，也可以用ADC加一个NTC热敏电阻来读温度，但代码写法会完全不一样。整个规划里，核心思想是：尽量让能工作的外设数量最少，并且优先使用支持低功耗的外设。

4.2 外设初始化和数据采集代码骨架

打开CubeMX，按上面的规划配置完引脚后，生成代码，然后开始往工程里填充业务逻辑。以下代码是主程序的核心骨架，执行流程很清楚：上电初始化系统时钟和所有外设，然后进入主循环，每轮循环里做一次采集，把数据通过串口发出去，最后进入Stop模式睡到下一次唤醒。

int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); MX_ADC1_Init(); MX_I2C1_Init(); MX_LPTIM1_Init(); uint32_t last_wake_time = 0; while (1) { // 人工让出CPU，等待片上外设或中断唤醒 HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI); // 唤醒后恢复系统时钟 SystemClock_Config(); // 执行一次数据采集 uint16_t light = ReadLightByADC(); uint16_t temp = ReadTemperatureByI2C(); // 封装上报帧 uint8_t buf[8]; buf[0] = 0xAA; buf[1] = (light >> 8) & 0xFF; buf[2] = light & 0xFF; buf[3] = (temp >> 8) & 0xFF; buf[4] = temp & 0xFF; HAL_UART_Transmit_DMA(&huart1, buf, 5); // 等待发送完成，再准备睡下一个周期 while (HAL_UART_GetState(&huart1) != HAL_UART_STATE_READY) {} } }

实际开发中，CubeMX生成的代码会替你完成大部分初始化工作。你只需要关注业务层的几件事：定时唤醒源怎么配置，唤醒后如何快速恢复，传感器读取函数如何封装。这里有个容易被忽略的点：ADC做的是单次转换，每次唤醒后要重新启动ADC转换，等待转换完成。如果用连续转换模式，会让芯片在睡眠期间也保持高功耗，完全违背设计初衷。所以我在CubeMX里把ADC配置成了单次扫描模式，规则通道使能，并且软件触发转换。

还有I2C通信时钟速度也值得注意。传感器节点这种场景，I2C跑100kHz标准模式就足够了。把I2C速度调到400kHz快速模式看起来快，但同时也引入了更大的上拉电流和通信时序裕量问题，在长导线连接传感器时，可靠性反而下降。

4.3 用LPTIM实现10秒定时唤醒，参数怎么算

低功耗定时的核心是LPTIM（低功耗定时器），它和普通定时器的区别在于：在MCU进入Stop模式后，它依然可以利用LSE或LSI时钟继续走，并且到点后能把芯片唤醒。C5的很多外设都支持异步工作，但LPTIM是定时唤醒的标配。

LPTIM的时钟源我选LSE外部32.768kHz晶振，精度高，温度漂移小。LPTIM1的计数器是16位的，最大值只有65535。如果直接用32.768kHz时钟计数，1秒需要32768个脉冲，这个数刚好在16位范围内，但10秒需要327680个脉冲，远超65535，计数器会溢出。所以必须用预分频器把频率降下来。

我的配置方法是：预分频器设置为128分频，也就是LPTIM的计数时钟变成32.768kHz除以128，等于256Hz。这时候每个计数脉冲的周期约为3.9毫秒。要产生10秒定时，需要的计数值是10秒乘以256Hz，等于2560。2560这个数远小于65535，完全在16位计数器能力范围内，到点后LPTIM产生比较匹配事件，触发唤醒中断，MCU从Stop模式醒来。

// LPTIM1配置关键参数（CubeMX生成的简化示意） // 时钟源: LSE // Prescaler: 128 // Compare value: 2560

实际在CubeMX里配置时，你只需要填好预分频值和脉冲计数初值，代码生成后，启动LPTIM中断的函数会在初始化里自动调用。需要自己写的是中断回调函数，在回调里放一个标志位，让主循环知道该起床干活了。我踩过的坑是，配好了LPTIM计数和比较值，但忘了使能LPTIM的中断，导致定时器一直在走，唤醒事件从不触发，芯片睡死过去。查这类问题最有效的办法是先在正常运行模式下开LPTIM，看能不能产生中断，确认中断链路没问题再进低功耗模式。

4.4 低功耗模式切换和唤醒恢复的细节

C5的低功耗模式分为多个等级，包括Sleep、Stop0/1/2、Standby和Shutdown等，数字越大功耗越低，但唤醒路径也越复杂。我这款传感器节点用的是Stop模式。进入Stop模式的入口函数是HAL_PWR_EnterSTOPMode，第一个参数传低功耗调节器，第二个参数用WFI指令等待事件。

唤醒恢复是很多人忽略的重点。从Stop模式唤醒后，系统时钟会回到复位时的状态，也就是很慢的MSI时钟。如果你没有在唤醒后重新调用SystemClock_Config()，直接跑主循环，会发现CPU明显变慢，定时器频率全部不对，串口波特率也乱了。所以我在代码里唤醒后的第一件事就是重新配置系统时钟，然后再做外设操作。

还有外设状态的问题。Stop模式下，一些外设的配置可能会丢失，特别是需要外部时钟的模块。我的经验是：数据采集相关的ADC和I2C，每次唤醒后重新初始化一次更稳妥。这个开销其实很小，因为初始化函数执行时间在微秒级，相比10秒的睡眠周期可以忽略不计。串口的话，我一般保留DMA配置，但唤醒后检查一下DMA状态，如果上一个周期发送还没结束就被睡眠打断，需要清一下标志再重新启动。

低功耗调试本身也有讲究。如果你开着调试器，芯片连在ST-LINK上，进Stop模式时调试器会尝试暂停内核，看起来就像芯片卡死或者功耗异常。初次调试低功耗时，先断开调试器，用串口打印或者GPIO电平来观察运行状态，等逻辑确认没问题了，再接上调试器看细节。

5. 常见问题与排查心得（踩坑实录）

5.1 SWD下载失败：最常见的原因和处理顺序

下载失败是C5开发里出现频率最高的问题，我自己也碰到过好几次。按优先级排查，第一看电源，第二看复位，第三看BOOT引脚，第四看SWD引脚是否被程序复用。

电源问题，核心是检查C5的VDD引脚电压是否稳定在手册要求范围内，供电电流是否够大。有的开发板用LDO从5V降到3.3V，如果LDO的压差不够或者输出电容不匹配，电压会在下载瞬间跌落，芯片直接电压异常复位。第二是复位引脚，如果外部电容过大，复位时间过长，下载器还没连上芯片就自己复位了，也会报错。

最麻烦的一种情况是SWD引脚被复用。程序里如果不小心把PA13和PA14（标准SWD引脚）配置成了普通GPIO输出，下载器就再也没法通过SWD连接芯片。解决办法是让芯片启动时不对SWD引脚做复用，最简单的就是先让芯片进入BootLoader模式。C5支持通过BOOT引脚配置进入系统BootLoader，把BOOT0引脚电平拉高，上电后芯片执行的是出厂固件，SWD引脚恢复为调试功能，这时候用CubeProgrammer连上，直接执行整片擦除。擦除后BOOT0复位回低电平，芯片恢复正常开发状态。

注意：批量生产时，如果下载接口不够稳定，优先查供电和接线，不要以为是芯片坏了。我遇到过一整批板子下载失败，结果是定制电源模块的输出纹波太大，加上线缆压降导致芯片供电不足，和芯片本身毫无关系。

5.2 HAL_Delay卡死和Tick中断的坑

HAL_Delay看起来人畜无害，但其实它是依赖SysTick中断的。SysTick每毫秒产生一次中断，HAL_Delay在循环里不断查询一个tick计数值，如果SysTick中断停了，HAL_Delay就会永远卡在while循环里。

在C5的工程里，这种情况最容易出现在两个时机。第一个是刚进主函数还没来得及配置中断优先级调度时，SysTick中断被其他更高优先级中断打断或屏蔽了。第二个是在低功耗模式唤醒后，SysTick恢复不及时，HAL_Delay异常。排查时，先用调试器看程序卡在哪个函数，如果停在HAL_Delay的循环里，就查SysTick中断是否正常触发，SysTick的优先级是否被设置成了低于某个频繁触发的中断。

如果项目里有两个需要独立计时的地方，或者SysTick用起来很别扭，可以考虑不用SysTick做HAL tick，而是改用任意一个基本定时器。CubeMX里在配置选项卡中可以改HAL的时间基准源。我有个项目因为使用了RTOS，RTOS需要SysTick，HAL tick就改用TIM7，两种tick互不干扰，HAL_Delay也正常工作。改了基准源之后记得扩展HAL_IncTick函数，定时器中断里喂一下。

5.3 DMA接收数据错位和丢失的排查逻辑

DMA看似省心，但踩坑的细节也最多。C5的UART DMA接收常见的问题是：用定长缓冲接收不定长数据，或者DMA中断一触发就读取缓冲，但数据还没收全，导致错位。

我的处理方式是采用DMA加串口空闲中断（IDLE）的做法。串口每收到一帧数据，在最后一个字节后会产生空闲事件，中断里用__HAL_DMA_GET_COUNTER函数读出DMA还剩下多少字节没搬完，从而推算出实际接收长度。这个值是进行过程中动态变化的，要立刻保存，否则缓冲区指针一旦被下一次传输改写，数据就找不回来了。

在低功耗场景下，DMA还有个更隐蔽的问题：如果芯片在DMA传输过程中进入Stop模式，DMA可以保持状态，但唤醒后主机软件层面可能已经把缓冲区覆盖了。我一般宁可让串口接收在普通运行态彻底完成再睡，也不赌DMA在睡眠边缘的完整性，否则丢数据问题会让你欲哭无泪。

5.4 功耗实测和理论对不上，问题出在哪

很多人在开发板上测C5低功耗，发现电流怎么都降不下来，和手册上写的微安级数字差了几十倍。这不是芯片虚标，而是测量方法和外围电路的问题。

先检查测量方法。万用表串到电源回路直接读电流，这个方法没错，但要注意芯片从唤醒到睡眠之间的瞬时电流变化。如果万用表响应速度慢，读到的平均电流和期望值会有偏差，这时候用示波器电流探头或者支持记录功能的精密功耗分析仪更靠谱。我的土办法是：在电源回路里串一个1欧姆精密电阻，用示波器测电阻两端电压波形，换算成电流。这个波形还能清晰显示每个工作阶段的电流变化，特别适合排查哪个环节耗电异常。

然后再看外围电路。我遇到几次功耗偏高，最后都是外部电路在漏电。比如光敏电阻和分压电阻一直挂在电源上，即使在睡眠模式下也在消耗电流；I2C传感器的供电引脚没有用GPIO控制，传感器一直在工作；某些GPIO配置成浮空输入，引脚上电压不定，内部上拉或下拉电路在反复开关消耗电流。解决办法是：不用的GPIO统一配置成模拟模式或者拉低输出，传感器的电源用MOS管切换，睡眠模式下彻底断电。

一个容易忽略的细节是调试器连接本身。ST-LINK在芯片睡眠时会尝试访问调试接口，导致芯片无法真正进入低功耗。测量功耗时一定把调试器的数据线断开，只用外部电源供电。

最后说几句实在话

C5这个系列，我整体用下来是满意的，但它确实有自己的脾气。最深的感受是：别一上来就开TrustZone，那个安全分区架构的学习曲线很陡，先把普通模式玩熟，再逐步加安全特性，才不会把自己绕晕。低功耗项目也是一样，别光看手册理论值，把电流表串进去看一眼真实数字比什么都管用。另外，如果你做的是量产产品，固件读保护和加密校验最好在开发初期就规划好，等要出货了再补，改代码和重验证的成本都太大了。手头有C5开发板的朋友，强烈建议先拿这个低功耗采集例程跑一遍，跑通了再谈功能扩展。