3. 裸机SPI轮询模式：轮询发送与接收、阻塞式API实现、性能测量

轮询模式，说白了就是CPU死等。你发一个字节，CPU就在那盯着状态寄存器，直到硬件告诉你“发完了”，再干下一件事。这是SPI最基础、最直接的操作方式，也是我们理解后续中断和DMA优化的起点。

我个人习惯，在评估一个外设驱动性能时，一定会先跑一遍轮询模式。为什么？因为它能暴露硬件的原始极限——没有中断延迟，没有DMA描述符开销，纯粹看总线时钟和CPU搬运速度。这个基线数据，是你后续所有优化的参照系。

3.1 轮询发送与接收的核心机制

SPI是同步全双工总线。这意味着，主设备每向MOSI线移出一个bit，就会从MISO线收到一个bit。所以，一次SPI传输，本质上是“发送”和“接收”同时完成的。你没法只发不收，也没法只收不发（除非你不在乎收到的垃圾数据）。

轮询模式下，我们通常这样操作：

1. 把要发送的数据写入SPI数据寄存器（DR）。
2. 硬件自动启动时钟，开始移位传输。
3. CPU不断读取状态寄存器，检查“发送完成”或“接收非空”标志位。
4. 标志位置位后，从DR中读取接收到的数据。
5. 重复以上步骤，直到所有字节传输完毕。

这里有个关键点：你必须在启动下一次发送前，把接收到的数据读走。否则，新数据会覆盖旧数据，造成数据丢失。我在项目中遇到过一位同事，他写了一个SPI驱动，发送正常，但接收总是错位。排查了半天，发现他是在发送完所有字节后才去读接收FIFO，结果只拿到了最后一个字节。

3.2 阻塞式API实现

阻塞式API，就是调用者发起传输后，必须等到传输完成才能返回。这期间CPU被“挂起”（实际上是在死循环里轮询），无法处理其他任务。实现起来很简单，但代价也很明显。

下面是一个典型的裸机SPI轮询发送/接收函数。我以STM32的HAL库风格为例，但去掉了抽象层，直接操作寄存器，方便你理解本质。

// 假设 SPI 寄存器基址为 SPI_BASE
// SPI_SR: 状态寄存器, SPI_DR: 数据寄存器
// TXE: 发送缓冲区空标志, RXNE: 接收缓冲区非空标志

void spi_polling_transmit_receive(uint8_t *tx_buf, uint8_t *rx_buf, uint32_t len)
{
    uint32_t i;
    volatile uint32_t status;

    for (i = 0; i < len; i++)
    {
        // 1. 等待发送缓冲区空（TXE=1）
        while (!(SPI_BASE->SR & SPI_SR_TXE))
        {
            // 空转等待，CPU 100% 占用
        }

        // 2. 写入发送数据，硬件自动启动传输
        SPI_BASE->DR = tx_buf[i];

        // 3. 等待接收缓冲区非空（RXNE=1）
        while (!(SPI_BASE->SR & SPI_SR_RXNE))
        {
            // 空转等待
        }

        // 4. 读取接收数据
        rx_buf[i] = SPI_BASE->DR;
    }

    // 5. 等待最后一次传输完全结束（BSY=0）
    while (SPI_BASE->SR & SPI_SR_BSY)
    {
        // 确保SPI总线空闲
    }
}

这段代码，你仔细看，其实有两个等待点：发送前等TXE，接收后等RXNE。对于全双工传输，这两个等待是串行的。但实际上，硬件在发送第一个字节的同时，就已经在接收第一个字节了。所以，更高效的写法是：先发第一个字节，然后循环里先等RXNE读走数据，再等TXE发下一个字节。这样能稍微减少一点等待时间。

3.3 性能测量方法

性能测量，不能靠感觉。你得用示波器或者逻辑分析仪抓波形，或者用MCU内部的定时器精确计时。我个人习惯用GPIO翻转法：在传输开始前拉高一个GPIO，传输结束后拉低。然后用示波器测量高电平的宽度，这就是传输耗时。

下面是我在一个Cortex-M4项目上实测的数据。SPI时钟设为18MHz，数据长度从1字节到1024字节，分别测量轮询模式下的耗时。

你看到了什么？实测时间比理论时间多了约15%。这15%就是CPU轮询状态寄存器、循环控制、函数调用等软件开销。而且，CPU占用率始终是100%——这就是轮询模式的代价。

我曾经在一个需要同时驱动SPI Flash和LCD的项目里，一开始全用轮询。结果CPU被SPI占得死死的，按键扫描和系统心跳都受到了影响。后来才下定决心切到中断+DMA。这个教训让我明白：轮询模式只适合短数据、低频率、或者CPU闲着也是闲着的场景。

3.4 轮询模式的适用场景与局限

轮询模式不是一无是处。它简单、可靠、延迟确定。在以下场景中，我仍然会优先考虑它：

• 系统初始化阶段：此时中断还没开，DMA还没配置，只能用轮询。
• 单次、短数据通信：比如读取一个传感器的ID寄存器，就1-2个字节，轮询的开销可以忽略。
• 实时性要求极高且数据量极小：轮询没有中断响应延迟，延迟是固定的几个CPU周期。

但它的局限也很明显：

• CPU利用率极低：传输期间CPU只能空转，无法做任何其他事情。
• 无法处理大数据块：传输1KB数据，CPU就要被占用几百微秒，这在实时系统中是不可接受的。
• 功耗高：CPU全速运行等待，无法进入低功耗模式。

3.5 本章知识体系图

下面这张图，帮你梳理裸机SPI轮询模式的核心逻辑和性能瓶颈。

这张图把轮询模式拆成了三个核心模块。你从“轮询模式”出发，左边是硬件机制，中间是软件实现，右边是测量手段。最下面的性能瓶颈框，是我们后续要解决的核心问题。

嗯，轮询模式就讲到这里。它的代码简单，但性能代价清晰。你掌握了这个基线，后面学中断和DMA时，才能对比出它们的真正价值。