普冉（PUYA）单片机开发进阶：通用定时器中断与UART协同实战-CSDN博客

1. 从点亮LED到协同作战：为什么需要定时器与串口联手？

大家好，我是老李，一个在嵌入式圈子里摸爬滚打了十多年的老码农。今天咱们不聊那些高深的理论，就说说在普冉（PUYA）的PY32F003这颗小单片机上，怎么把两个最常用的“劳模”——通用定时器和UART串口——给撮合到一块儿，让它们既能各司其职，又能默契配合。你可能已经照着官方例程，成功让定时器中断闪起了LED，也实现了串口收发数据。但当你试图把它们同时放进一个项目里，比如让定时器每隔100毫秒采集一次传感器数据，然后通过串口发送出去时，是不是偶尔会遇到数据发着发着就乱了，或者LED闪烁的节奏突然卡一下？这就是典型的“多中断协同”问题，也是咱们今天要啃下的硬骨头。

我刚开始用PY32F003做项目时也踩过这个坑。当时做了一个环境监测的小装置，定时器负责每2秒读取温湿度，串口负责把数据打包上传给电脑。单独测试都没问题，可一上电全速跑，电脑端收到的数据时不时就丢包，或者时间戳对不上。折腾了半天才发现，是定时器中断和串口接收中断“打架”了，谁都想先执行，结果把对方给挤掉了。这就像一个小厨房里有两个厨师，一个要炒菜（定时器到点处理），一个要出锅（串口发送完成），如果没协调好顺序，菜不是炒糊了就是凉了。

所以，这篇笔记的目的很明确：不止步于让定时器和串口各自工作，而是要深入它们的中断机制内部，解决优先级冲突、资源竞争这些实际问题，最终实现一个稳定、高效的协同工作框架。我会用最直白的语言，配上我实际调试过的代码，带你一步步从原理到实战，彻底搞定它。咱们先从回顾基础配置开始，但这次会带着“协同”的眼光，去看待每一个参数设置。

2. 核心基石：深入理解定时器与UART的中断机制

要想让两个模块和谐共处，你得先摸清它们各自的“脾气”，尤其是它们如何发出中断请求、以及CPU如何响应。这部分内容有点干，但却是后面解决所有问题的钥匙，我尽量用比喻说清楚。

2.1 定时器中断是如何“到点提醒”的？

在PY32F003上，通用定时器（比如TIM16、TIM17）就像一个精准的闹钟。它的核心部件是一个计数器，从0开始，随着总线时钟（比如24MHz）的节拍向上累加。你通过两个参数设定闹钟响铃的时间点：预分频器（Prescaler） 和 自动重装载值（Period）。

预分频器：你可以把它理解为一个“减速齿轮”。总线时钟24MHz太快了，直接计数的话，一秒钟就数了2400万次，这闹钟响得太频繁没啥用。Prescaler = 1000 - 1 就表示，每来1000个时钟脉冲，计数器才加1。这样，计数器的实际时钟就变成了24MHz / 1000 = 24KHz。
自动重装载值：这就是你设定的闹钟刻度。Period = 12000 - 1 表示计数器从0数到11999（一共12000个数）后，就会触发一个“更新事件”，并产生中断请求（如果中断使能了）。此时，计数器会自动清零，重新开始下一轮计数。

那么中断周期怎么算？公式是：T = (Prescaler + 1) * (Period + 1) / Fclk。代入我们的值：T = 1000 * 12000 / 24,000,000 = 0.5秒。所以，这个定时器每半秒“叮”一次，产生一个中断。

这里有个关键细节，也是我早期容易忽略的：定时器中断属于“内部事件中断”。它不依赖于外部引脚变化，只跟时钟有关，因此中断请求的产生非常规律和准时。但这也意味着，如果它的中断服务函数执行时间过长，错过了下一个定时点，不会产生“中断排队”，而是直接覆盖，导致时间基准漂移。

2.2 UART中断的“随机性”与数据流控制

串口中断则完全是另一种风格，它更像一个“门铃”，响不响、什么时候响，取决于外部数据什么时候到。UART中断主要有三种类型：

接收完成中断（RXNE）：这是最常用的。当串口接收移位寄存器收完一个字节的数据，并转移到接收数据寄存器（RDR）时，就会触发此中断。告诉你：“数据到了，快来取！”
发送完成中断（TC）：当发送移位寄存器把一个字节的数据全部发出，发送数据寄存器（TDR）为空时触发。告诉你：“上一个字节发完了，可以准备下一个了！”
发送寄存器空中断（TXE）：当TDR寄存器为空（即数据已转移到移位寄存器）时触发。它比TC中断更早，允许你更早地填充下一个待发送数据，从而实现更流畅的连续发送。

UART中断的“随机性”是问题的根源。 你不知道电脑上位机软件什么时候会发来一帧数据，可能是在定时器中断正执行到一半的时候。如果处理不好，就会发生中断嵌套，甚至数据丢失。

我举个例子：假设你的定时器中断服务函数里正在执行一段复杂的浮点运算（虽然M0+没有硬件FPU，模拟运算也很耗时），这时串口突然收到了一长串数据。如果串口中断优先级更高，它会打断定时器中断，先去收数据。等收完数据回来，定时器中断里那个未完成的浮点运算可能已经超时，影响了下一个周期的定时精度。如果定时器中断优先级更高，串口数据就可能因为来不及响应而丢失一两个字节。

所以，协同的关键，在于根据你的业务场景