2. 轮询发送模式原理：CPU忙等待、发送寄存器与移位寄存器

大家好，我是你们的讲师。今天咱们来啃一块硬骨头——轮询发送模式。很多初学者觉得UART发送嘛，不就是往寄存器里丢数据吗？其实没那么简单。我见过不少工程师，包括我自己刚入行时，都在这上面栽过跟头。

说白了，轮询发送就是CPU一直在“盯着”发送完成标志位，直到它说“我准备好了”，才把下一个字节塞进去。这个过程里，CPU几乎啥也干不了，全耗在等待上了。

2.1 CPU忙等待机制：为什么CPU会“卡死”？

先看一个典型场景。你写了一个UART发送函数，循环发送100个字节。结果发现，整个系统在发送期间像死机了一样，按键没反应，LED也不闪。嗯，这就是忙等待的典型症状。

我给大家画个流程图，看看CPU到底在忙什么：

看到红色箭头那条循环了吗？这就是CPU“空转”的路径。我曾经在一个项目里，用115200波特率发一帧512字节的数据，结果整个系统卡了将近50毫秒。对于人来说50ms不算啥，但对于一个实时控制系统，这足以让电机丢步、传感器数据超时。

2.2 发送寄存器（TX）与移位寄存器的关系

很多新手搞不清这两个寄存器的区别。我打个比方：发送寄存器（TX）就像是一个“缓冲区”，而移位寄存器才是真正干活的那个“工人”。

寄存器	别名	作用	CPU访问方式
发送数据寄存器	TX / DR	暂存待发送的数据字节	CPU可读写
发送移位寄存器	TSR	将并行数据逐位移出到TX引脚	CPU不可直接访问

工作流程是这样的：

1. CPU把数据写入TX寄存器——这一步很快，一个存储指令就搞定。
2. 硬件自动将TX内容复制到TSR——前提是TSR空闲（上一字节已发送完毕）。
3. TSR开始逐位发送——每个bit按波特率时钟从TX引脚输出。
4. 发送完成后，硬件置位TC标志——通知CPU可以发下一个字节了。

2.3 发送完成标志位轮询：代码怎么写才靠谱？

好，理论说完了，咱们上代码。这是最基础的轮询发送实现：

// 最基础的轮询发送函数
void UART_SendByte(uint8_t data)
{
    // 1. 等待发送完成标志置位
    while (!(UART->SR & UART_SR_TC));
    
    // 2. 写入数据到发送寄存器
    UART->DR = data;
}

这段代码看起来没问题，对吧？但我告诉你，这里有个坑。我曾经在一个项目里用这个函数连续发送数据，结果发现第一个字节总是发不出去。排查了半天，原来是复位后TC标志默认就是1，第一次进入函数时while直接跳过，但此时TSR还没初始化完成，数据写进去就丢了。

改进后的代码：

// 带初始化的轮询发送函数
void UART_SendByte_Safe(uint8_t data)
{
    // 等待上一次发送完成
    // 注意：第一次调用时，TC可能为1，但TSR可能未就绪
    // 所以先写一个字节触发发送，再等待完成
    while (!(UART->SR & UART_SR_TC));
    
    // 写入数据
    UART->DR = data;
    
    // 对于某些芯片，需要再次等待TC置位
    // 以确保数据真正从移位寄存器发出
    while (!(UART->SR & UART_SR_TC));
}

你可能会问：“为什么要等两次？”嗯，第一次等待是为了确保前一个字节发完，第二次等待是为了确保当前字节发完。对于单字节发送，第二次等待其实可以省略，但如果你要连续发送多字节，第二次等待就是必须的。

2.4 轮询发送的性能瓶颈与优化思路

咱们来算一笔账。假设波特率是115200，数据位8位，1位停止位，无校验。那么发送一个字节需要的时间是：

(1 + 8 + 1) / 115200 ≈ 86.8 微秒

也就是说，每发送一个字节，CPU要空等大约87微秒。如果发1000个字节，就是87毫秒。这87毫秒里，CPU啥也干不了。

波特率	每字节耗时	1000字节耗时	CPU利用率
9600	1.04 ms	1.04 s	≈0%
115200	86.8 μs	86.8 ms	≈0%
921600	10.9 μs	10.9 ms	≈0%

看到没？不管波特率多高，CPU利用率都是0%。因为CPU一直在“空转”。

2.5 实战中的几个“坑”

最后，我分享几个我在项目中踩过的坑，希望能帮大家少走弯路：