简介：STM32 HAL库与机智云对接项目源码包，面向物联网嵌入式开发者及学习STM32+云端通信的初学者。基于STM32F1系列HAL库，工程展示了如何修改串口配置（如波特率、数据位、校验方式与中断处理）以及调整定时器分频、自动重载或PWM模式，从而满足机智云平台的指令收发与周期性状态上报需求。包内同时提供机智云协议处理逻辑，可参考理解报文构造、解析及与云端交互的实现细节。压缩包共206个文件，以.c/.h源码为主，辅以Keil工程文件（uvprojx/uvoptx）、可视化配置描述（ioc/mxproject）以及编译生成的axf/hex固件，整体8.6MB，结构清晰，可直接打开工程查看配置或烧录验证。工程组织规范，代码注释清晰，方便参照修改或移植到其他STM32型号。已有426人学习下载，适合希望快速掌握HAL库串口定时器改造、接入机智云的开发者参考。 最近在折腾机智云接入，用的是STM32F103C8T6加HAL库，遇到一个几乎每个做嵌入式物联网开发的工程师都会碰上的问题：机智云自动生成的工程里，串口和定时器资源分配跟自己的板子对不上。比如默认串口是USART1，但你的WiFi模块接在USART2上；又比如默认定时器周期是5ms，但你希望改成10ms再上报一次数据。这类“修改串口和定时器”的需求，看着简单，实际操作时却很容易被协议栈封装、中断回调、时钟配置这些细节绊住。
这篇内容主要讲清楚一件事：基于STM32 HAL库的机智云工程，如何安全地把默认串口换到目标串口，以及如何把定时器周期调成自己需要的值。我会按照实际动手顺序来写，先讲为什么默认资源会这样分配，再讲串口和定时器分别怎么改、改完怎么验证，最后分享几个我踩过之后才明白的坑。适合刚接触机智云、想在现有工程基础上调整底层资源的同学，也适合那些想搞明白HAL库串口和定时器底层关系的朋友。
1. 为什么要修改机智云工程里的串口和定时器
1.1 机智云默认工程里的资源分配逻辑
机智云的MCU开发方案一般会提供一个代码生成器，你选好MCU型号、定义好数据点之后，它会生成一个HAL库基础工程。这个工程里包含了协议解析、数据上报、串口通信等核心代码。为了让你拿到就能跑，工具会默认选择一些通用外设资源：通信串口多半选USART1，时间基准可能用SysTick，周期任务可能用TIM2或者TIM3。这套默认配置在官方评估板上是没问题的，但一旦换到自己的板子，冲突就来了。
我记得第一次用的时候，板载USB转串口芯片占用了USART1，而机智云需要的WiFi模块串口却在USART2，两个串口绑在一起，调试信息直接发到了WiFi模块那里。如果不去修改，整个系统看起来就像“没反应”，实际上协议已经在乱跳了。所以，搞清楚默认资源如何分配，是修改的前提。
1.2 修改前必须搞清楚的三个关键因素
在动手改代码前，我先理清单，否则后面容易越改越乱。
- 硬件串口映射：打开原理图，确认目标串口的引脚有没有被其他外设占用，是否需要复用功能重映射。
- 波特率一致性：MCU和WiFi模块之间通信波特率必须一致，机智云默认模板常见的是9600或115200，具体看模组厂商要求。
- 定时器用途：区分“系统节拍”和“用户周期任务”。系统节拍往往挂在SysTick上，
HAL_GetTick()和HAL_Delay()都依赖它，不能随便改；用户周期任务可以改到任意一个基本定时器上。
这三个点对应了修改串口和定时器时最容易踩的坑：引脚错了、波特率不对、SysTick被改了导致所有延时异常。先确认再动手，能省很多debug时间。
2. 串口修改实操：把USART1换成USART2的完整流程
2.1 硬件连接和引脚复用检查
先说硬件。STM32F103上，USART1默认是PA9（TX）、PA10（RX），USART2默认是PA2（TX）、PA3（RX）。如果你要把通信串口从USART1改到USART2，最常规的接法是：PA2接到WiFi模块的RX，PA3接到WiFi模块的TX，注意交叉连接。还有个容易忽略的点：有些板子上的PA2、PA3已经被当做其他用途，比如接DAC输出或者LED，那就要换串口或者改板子。
除了引脚本身，还要检查是否开启了复用时钟。HAL库在HAL_UART_MspInit中会开启GPIO时钟和UART时钟。如果手动改工程，这一块特别容易漏。我建议能进CubeMX就在CubeMX里重新选一下引脚，让它自动生成MspInit初始化代码，而不是手写。
2.2 CubeMX重新生成初始化还是手动补代码
如果你手头有这个工程对应的CubeMX文件，流程很简单：在Pinout视图里把USART1引脚释放，重新选中USART2的TX/RX引脚，配置波特率、中断，然后重新生成代码。如果没有CubeMX文件，只能手动改。
手动改的第一步是增加USART2的初始化函数，可以参考原有USART1的写法：
static void MX_USART2_UART_Init(void) { huart2.Instance = USART2; huart2.Init.BaudRate = 115200; huart2.Init.WordLength = UART_WORDLENGTH_8B; huart2.Init.StopBits = UART_STOPBITS_1; huart2.Init.Parity = UART_PARITY_NONE; huart2.Init.Mode = UART_MODE_TX_RX; huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE; huart2.Init.OverSampling = UART_OVERSAMPLING_16; if (HAL_UART_Init(&huart2) != HAL_OK) { Error_Handler(); } }同时在HAL_UART_MspInit里加上USART2的时钟和引脚初始化，否则外设没有时钟就无法工作。如果你对HAL库的MspInit机制还不太熟，记住一个原则：外设初始化是“两层”的，HAL_UART_Init负责配置寄存器，MspInit负责配置底层时钟、引脚和中断。只写Init不写MspInit，外设依然起不来。
2.3 让机智云协议栈使用新的串口句柄
初始化做完，真正的重点来了：机智云协议栈的收发函数必须从huart1切到huart2。在生成的工程里，串口收发一般会封装在类似gizwits_product.c、uart_user.c或者wifi_module.c的文件里，搜索huart1、USART1、HAL_UART_Transmit这些关键词就能定位。
发送方向很好改，把HAL_UART_Transmit(&huart1, ...)改成HAL_UART_Transmit(&huart2, ...)即可。接收方向有个常见坑：HAL库的串口接收中断回调只会提供一个入口HAL_UART_RxCpltCallback，如果工程里同时用了多个串口，必须在回调函数内部判断是哪个串口产生的中断。例如：
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART2) { // 处理从WiFi模块收到的数据 HAL_UART_Receive_IT(&huart2, &rx_data, 1); } }不要直接删除原来的判断逻辑，而是检查里面有没有遗漏其他串口。机智云协议栈接收数据一般是单字节中断，每次收到一个字节，处理完立刻开启下一次接收。如果回调里没有重新调用HAL_UART_Receive_IT，接收就会停住，设备会表现为“不上报、不响应”。
2.4 修改串口后如何自测
我习惯在改完串口后，先不接WiFi模块，用USB转TTL模块把目标串口接到电脑，打开串口调试助手发数据。第一步先看MCU能不能收到数据，用调试器在HAL_UART_RxCpltCallback里打断点，发一个字节，看能不能停住。第二步看MCU能不能发送数据，可以直接在初始化后调一次HAL_UART_Transmit发一个测试串，串口助手里能看到就说明底层正常。
自测通过后再接WiFi模块，这样能区分是硬件问题还是协议栈问题。如果一上来就接WiFi模块，很容易出现“两边都不说话”的情况，排查起来非常难受。
3. 定时器修改实操：把5ms周期改成10ms
3.1 定时器在机智云工程里到底干什么
很多同学以为定时器只是用来做延时的，其实在机智云工程里，定时器的主要作用是生成一个稳定的“时基信号”。比如协议栈需要用定时器来判断一个完整的数据包是否接收超时，每1ms或5ms扫描一次接收缓冲区；数据上报可能也是定时触发，到了设定的时间就调用一次gizwitsReport把当前数据发给WiFi模块。
如果你改动定时器周期，相当于改了“心跳节奏”。代码里所有依赖这个定时器累加的变量，比如超时计数、按键消抖计时、上报周期，都会跟着变。所以改周期之前，先搜索一下当前定时器回调里都做了什么，不要只改一个初始化值。
3.2 定时器周期计算的底层逻辑
以STM32F103的TIM2为例，它挂在APB1总线上，当APB1预分频系数不是1时，定时器时钟是PCLK1的两倍。很多人在计算定时器周期时忘了这个倍频，导致结果差一半，这是特别经典的一个坑。
假设系统主频72MHz，APB1预分频为2，那么PCLK1是36MHz，但定时器时钟源会自动变成72MHz。如果要定时10ms，可以这样算：
- 定时器时钟频率：72MHz
- 预分频PSC+1：72，得到1MHz的计数频率
- 自动重装值ARR+1：10000，计数器从0计到9999，耗时10ms
代码中对应参数就是：
htim2.Init.Prescaler = 71; htim2.Init.Period = 9999;如果你要改成5ms，只需要把Period改成4999。这里需要注意，Prescaler和Period都是寄存器值，实际生效的分频比是“写进去的值加1”。新手最容易在这里把自己绕晕，直接把Prescaler写成72，结果实际变成73分频，周期就偏了。
3.3 修改代码时如何同时调整回调逻辑
定时器初始化改完，启动方式也要确认。HAL库中定时器有三种启动方式：HAL_TIM_Base_Start（不使能中断）、HAL_TIM_Base_Start_IT（使能中断）、HAL_TIM_Base_Start_DMA（配合DMA）。机智云工程里通常使用中断方式，所以必须调用HAL_TIM_Base_Start_IT，同时使能TIM中继中断和NVIC中断。
如果原来是5ms中断一次，改成10ms后，回调里的累加值含义也变了。比如原来有一个变量，每次中断加1，加到200就认为过了1秒；改成10ms周期后，仍然加到200就是2秒。这个逻辑必须一起调整，否则协议超时时间会翻倍。常见的做法是用一个全局变量timer_cnt，中断里timer_cnt++，主循环里判断：
if (timer_cnt >= 100) // 周期从5ms改成10ms后，100次就是1s { timer_cnt = 0; // 执行周期性任务 }这个判断要根据实际周期重新算一遍，不能想当然。
3.4 修改定时器后如何验证周期
最简单的验证方式是在定时器中断回调里翻转一个GPIO，用示波器或者逻辑分析仪看波形周期。没有示波器的话，可以在回调里让一个LED闪烁，眼睛看大致频率，但精度只能当参考。如果手头有串口调试助手，也可以让定时器每秒通过串口打印一个计数，看每秒打印次数是否和预期一致。
我实际调试时发现，光看代码很难发现倍频问题，用逻辑分析仪一看波形，周期正好是预期的一半，立刻就能定位到是定时器时钟源倍频没算对。这种问题如果靠肉眼观察串口打印，可能要绕不少弯路。
4. 常见问题与排查技巧实录
4.1 改了串口，数据却还是从旧串口出来
原因基本只有一个：底层还有遗漏的huart1或USART1没有被替换掉。机智云工程里的串口封装可能不止一层，有的文件叫gizwits_product.c，有的在gagent_hal.c里，甚至有的在WiFi模组移植层里。建议在编译环境里全局搜索USART1、huart1、HAL_UART_Transmit，一个个核对过去。还有一个隐蔽点：接收中断可能是在中断服务函数里用huart1开启的，搜索HAL_UART_Receive_IT，确认所有的接收启动都用了新的句柄。
4.2 定时器周期和预期差一半
绝大多数情况是定时器时钟树配置问题。STM32F1的定时器时钟不是简单的“APB1时钟”，APB1预分频不为1时，定时器时钟会加倍。这也是为什么用CubeMX生成工程时它自动帮你算好的原因——它知道当前时钟树配置。手动改代码时，不要直接用APB1频率计算，要先看RCC_ClkInitTypeDef里的配置，或者参考CubeMX时钟树页面。
4.3 串口收到乱码
先看波特率是否一致，再看两边电平是否一致。MCU的UART一般是TTL电平，WiFi模块如果直接引出TTL接口就可以直连，但如果是RS232电平就必须加转换芯片。另外，如果你的串口调试助手买的模块带的是CH340芯片，要注意CH340驱动是否安装正常，Windows下容易因驱动问题出现乱码，这个跟STM32代码关系不大。
4.4 定时器中断进不去或者系统卡死
进不去中断，先检查三处：HAL_TIM_Base_Start_IT是否调用、HAL_TIM_IRQHandler是否在中断服务函数里调用、NVIC中断优先级是否配置。很多人在写TIM2_IRQHandler时直接写自己的逻辑，没有调用HAL库的HAL_TIM_IRQHandler(&htim2)，就会导致中断标志没有被HAL库及时清除，进一次中断后再也不进。这个在HAL库工程里属于老生常谈，但确实很容易漏。
系统卡死则要小心定时器回调里是否做了耗时操作。中断服务函数里敲个几个微秒的操作还好，如果直接在里面调用HAL_UART_Transmit发送一长串数据，会占用大量中断时间，导致主循环被饿死，看上去就像“跑飞了”。正确的做法是中断里只置标志位或简单计数，把耗时的协议处理放到主循环中。
4.5 多个外设共用回调函数的冲突
HAL库的HAL_UART_RxCpltCallback和HAL_TIM_PeriodElapsedCallback都是全局的，工程里同时用多个串口、多个定时器时，所有外设都会进同一个回调函数。如果只针对某个实例写代码，其他外设中断就会“无处安放”，通常表现为其中一个功能正常，另一个完全没反应。
我在工程里会统一写成这样：
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART2) { // 机智云串口接收处理 } else if (huart->Instance == USART1) { // 调试串口接收处理 } }定时器回调也是同理，按htim->Instance区分。这样以后加新外设，只需要往对应的判断分支里补充逻辑，不用再回过头改旧代码。
5. 一点实操建议
改完串口和定时器后，先别急着接完整系统，我习惯做两轮验证。第一轮用串口调试助手直接和MCU通信，确认被动收发都正常。第二轮用逻辑分析仪测定时器中断输出的波形，确认周期精确。两轮都通过，再接WiFi模块连机智云，这时候如果还有问题，基本就能确定是协议栈层面的问题，和底层外设无关。
另外，我强烈建议在工程里保留一个调试宏，比如：
#define GIZWITS_UART huart2 #define GIZWITS_TIM htim2所有代码都用这个宏代替实际句柄，以后要从USART2改成USART3，只改这一处就行。第一次移植时我偷懒没有这么做，结果全局替换替换漏了好几个地方，花了几乎一个下午排查。现在我做任何涉及外设资源调整的移植，都会先把这类“资源别名”定义好，再开始动手。
本文还有配套的精品资源，点击获取
