为什么我的 SPI 读出来全是 255？MISO 上拉的“坑”你踩过吗？

最近在调试一块基于树莓派的传感器板卡时，遇到一个经典问题：用 C++ 调 spidev 读 /dev/spidev0.0 ，结果每次返回的数据都是 0xFF（也就是十进制 255） 。一开始以为是代码写错了、设备没连上，甚至怀疑是不是内核驱动坏了……折腾半天才发现——这根本不是 bug，而是硬件和协议特性共同作用下的“正常现象”。

今天就来彻底讲清楚这个困扰无数嵌入式开发者的“魔咒”： 为什么 SPI 的 read 操作会读出一堆 255？MISO 引脚的上拉状态到底起了什么作用？我们又该如何正确应对？

一、这不是数据错误，这是总线的“默认语气”

先说结论：

当你从 SPI 设备读到全 255（0xFF），通常意味着 MISO 线路上没有有效的从机输出，而引脚被外部电阻拉高了。

听起来有点抽象？我们一步步拆解。

SPI 是怎么“读”的？

很多人误以为 read(fd, buf, 3) 就像读文件一样，“我去拿三个字节”。但在 SPI 中， 根本没有“只读”这种操作 。SPI 是全双工同步串行协议，主设备每发一个时钟脉冲（SCLK），就会同时完成一位发送和一位接收。

也就是说：
- 主机要读 1 字节 → 必须发出 8 个 SCLK；
- 发出 8 个 SCLK → 主机必须发送 8 位数据（哪怕你不想发）；
- 同时，主机在这 8 个边沿采样 MISO 上的电平，组成接收到的字节。

所以，调用 read() 实际上等价于：
“我发 8 个 dummy bit（通常是 0x00），然后收 8 个来自 MISO 的 bit。”

如果此时从设备没有响应、未使能、或者还没准备好驱动 MISO，那这条线的状态由谁决定？

答案是： 外部电路 。

二、MISO 被上拉了！这就是 255 的来源

大多数设计中，为了防止信号悬空引入噪声干扰，工程师会在 MISO 引脚加一个 上拉电阻 （常见值如 4.7kΩ ~ 10kΩ），将其默认电平固定为高（VDD）。

这意味着：
👉 当从设备不驱动 MISO 时，该引脚自动呈现逻辑“1”。

于是问题来了：

主机发送 SCLK 边沿 MISO 实际电平 主机采样结果
任意 8 次上升/下降沿 全部为高（因上拉） 每位 = 1

最终组合成一个字节： 1111_1111 = 0xFF = 255

这就解释了为什么你会看到这样的输出： 

Received[0] = 0xff (255)
Received[1] = 0xff (255)
Received[2] = 0xff (255)

它不是随机错误，也不是通信失败标志，而是清晰告诉你：“兄弟，没人说话，但我听见了一堆‘高’。”

三、哪些情况会导致 MISO 处于上拉状态？

别急着改代码，先排查以下几种典型场景：

1. 片选（CS）没拉低 or 拉低后立即读取

这是最常见的陷阱！

很多 SPI 从设备（比如 ADC、Flash、传感器）需要在 CS 下降沿后经历一段 建立时间（t_SU,CS） 才能激活内部输出驱动器。如果你在 CS 刚拉低就马上开始 SCLK，MISO 还处于高阻态，自然就被上拉占了主导。

✅ 正确做法：CS 拉低后插入微秒级延时（例如 usleep(10); ），等待从机准备就绪再发起传输。

2. 从设备根本没工作（电源、复位、配置问题）

检查一下：
- 芯片供电是否正常？
- RESET 引脚有没有释放？
- 是否已通过命令进入工作模式？

有些传感器默认处于休眠状态，必须先发唤醒指令才能响应 SPI 请求。

3. MOSI 写错命令，导致从机没开启输出

比如你想读 ADC 数据，但发送的命令格式不对，从机压根不知道你要干嘛，也就不会把转换结果放到 MISO 上。

建议用示波器或逻辑分析仪抓包验证 MOSI 数据是否符合手册要求。

4. 多设备共用 MISO，片选控制混乱

当多个 SPI 从设备共享同一组总线（SCLK/MOSI/MISO）时，必须确保任一时刻只有一个 CS 有效。否则可能出现：
- 两个设备同时驱动 MISO（一个拉高，一个拉低）→ 总线冲突；
- 或者所有设备都未被选中 → MISO 回到上拉状态 → 全 255。

🔧 解决方案：使用独立 GPIO 控制每个 CS，或加入 SPI 多路复用器（如 TMUXHS4612）。

四、别再滥用 read() ！你应该用 ioctl(SPI_IOC_MESSAGE)

回到 Linux 的 spidev 接口，这里有个关键认知偏差：

❌ 错误理解： read() 是“只读”

✅ 正确认知： read() 是“发送 len 个 0x00 并接收 len 字节”

如果你直接调： 

read(fd, buffer, 3);

相当于你在对从机说：“我发三个零，你给我三个数据。”
但如果对方没准备好，你就只能收到三个“上拉默认值”——也就是 255。

更可控的做法是使用 struct spi_ioc_transfer 配合 ioctl ，完全掌控每一次传输行为。

下面是一个推荐的 C++ 封装实现： 

#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/spi/spidev.h>
#include <unistd.h>
#include <iostream>
#include <cstring>
#include <stdexcept>

class SPIDevice {
public:
    explicit SPIDevice(const char* device_path) : fd(-1) {
        fd = open(device_path, O_RDWR);
        if (fd < 0) {
            throw std::runtime_error("无法打开 SPI 设备: " + std::string(device_path));
        }

        // 设置 SPI MODE 0: CPOL=0, CPHA=0
        uint8_t mode = 0;
        if (ioctl(fd, SPI_IOC_WR_MODE, &mode) == -1) {
            close(fd);
            throw std::runtime_error("设置 SPI 模式失败");
        }

        // 设置每字 8 位
        uint8_t bits = 8;
        ioctl(fd, SPI_IOC_WR_BITS_PER_WORD, &bits);

        // 设置最大速率 1MHz
        uint32_t speed = 1000000;
        ioctl(fd, SPI_IOC_WR_MAX_SPEED_HZ, &speed);
    }

    ~SPIDevice() {
        if (fd >= 0) close(fd);
    }

    // 显式控制 SPI 传输：可指定是否发送数据
    int transfer(const uint8_t* tx_buf, uint8_t* rx_buf, size_t len) {
        struct spi_ioc_transfer tr;
        std::memset(&tr, 0, sizeof(tr));

        tr.tx_buf        = reinterpret_cast<unsigned long>(tx_buf);
        tr.rx_buf        = reinterpret_cast<unsigned long>(rx_buf);
        tr.len           = len;
        tr.speed_hz      = 1000000;
        tr.bits_per_word = 8;

        return ioctl(fd, SPI_IOC_MESSAGE(1), &tr);
    }

    // 只读模式：发送 dummy byte（0x00）以产生时钟
    int read(uint8_t* rx_buf, size_t len) {
        std::vector<uint8_t> dummy(len, 0x00);  // 发送空字节
        return transfer(dummy.data(), rx_buf, len);
    }

private:
    int fd;
};
使用示例： 
int main() {
    try {
        SPIDevice spi("/dev/spidev0.0");
        uint8_t buffer[3];

        // 添加必要的延时（根据芯片手册）
        usleep(10);  // 等待从机稳定

        int ret = spi.read(buffer, 3);
        if (ret > 0) {
            for (int i = 0; i < ret; ++i) {
                printf("Received[%d] = 0x%02X (%d)\n", i, buffer[i], buffer[i]);
            }
        } else {
            perror("SPI 读取失败");
        }

    } catch (const std::exception& e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return -1;
    }

    return 0;
}

📌 关键点总结：
- 使用 transfer() 可灵活控制发送内容；
- read() 方法显式填充 0x00 作为 dummy 输出，避免歧义；
- 所有参数均可动态调整（速度、位宽、延迟等）；

五、硬件设计建议：上拉不是原罪，合理才是王道

前面说了，MISO 上拉本身是有益的，不能简单去掉。正确的做法是软硬协同优化：

项目 建议
上拉电阻阻值 4.7kΩ ~ 10kΩ，太小耗电大，太大易受干扰
驱动能力匹配 若走线长或负载重，选择输出驱动强的从设备
CS 到 SCLK 延时 至少满足 t_SU,CS（查芯片手册），一般 1~10μs
使用缓冲器 在噪声环境或长距离传输中加 SN74LVC1T45 等电平转换/驱动 IC
避免热插拔误触发 可结合中断引脚判断设备是否存在

六、实战调试技巧：快速定位问题根源

当你再次遇到“全 255”时，可以按以下步骤快速排查：

  1. 🔧 检查物理连接
    - MISO、MOSI、SCLK、CS 是否接反？
    - GND 是否共地？

  2. 📈 用逻辑分析仪看波形
    - CS 是否正确拉低？
    - SCLK 是否出现？
    - MOSI 数据是否符合预期？
    - MISO 是否全程高？还是部分时段有变化？

  3. ⚙️ 确认从设备工作模式
    - 是否需要初始化命令？
    - 是否处于低功耗模式？

  4. ⏱️ 增加 CS 后延时
    cpp digitalWrite(CS_PIN, LOW); usleep(10); // 至少 5~10 微秒 spi_read(...); digitalWrite(CS_PIN, HIGH);

  5. 🔄 尝试回环测试（Loopback）
    将 MOSI 和 MISO 短接（小心电压兼容性），发送特定字节（如 0x5A），看能否收到相同数据。可用于验证主控 SPI 功能是否正常。

结语：255 不是终点，而是起点

下次当你看到 SPI 返回一堆 255，请不要慌张，也不要轻易归咎于“硬件坏了”或“驱动有问题”。相反，把它当作系统给你的一个提示信号：

“嘿，我现在听到了高电平，说明没人说话——你是想等一个人开口呢，还是先把麦克风打开？”

理解 MISO 上拉的本质、掌握 spidev 的真实行为、规范片选时序与软件流程，才能真正驾驭 SPI 这条看似简单却暗藏玄机的总线。

这才是嵌入式开发的魅力所在：每一个 255 背后，都藏着一段软硬交织的故事。

如果你也在项目中踩过类似的坑，欢迎留言分享你的解决方案！

Logo
乐奇 Rokid 开放社区

更多推荐

cover

AI眼镜的赢家不在硅谷，在一个县城

avatar 乐奇 Rokid 开放社区
cover

ChatGPT流量不到Google的1%，机会在智能体搜索

avatar 乐奇 Rokid 开放社区
cover

极刻觅镜 | AI眼镜日报｜智能眼镜日报：XREAL AURA发布、参议员质询Meta隐私

avatar 乐奇 Rokid 开放社区