在用寄存器、SPI、I2C这些底层接口读取数据时，返回的结果确实几乎全是0xFF、0x12这类格式。这背后是二进制本质、十六进制速记、行业通用习惯三重原因共同作用的结果。

1. 根本原因：计算机只看二进制，但二进制对人太长了

• 芯片内部全是 0 和 1：你龙芯 1C102 的 GPIO 寄存器、MPU6050 的数据寄存器、RC522 的 SPI 缓冲区，在物理上都是一组触发器，每个触发器只能存 0 或 1。8 个触发器组成一个字节。

• 二进制书写灾难：一个字节11010000念起来像电话号码，一个 32 位寄存器11010000110000000000000000000001基本无法阅读和记忆，写代码时也极容易缺位多位。

2. 解决方案：十六进制——二进制的完美速记

十六进制就是为此而生的。它和二进制有天然的血缘关系，因为1 位十六进制数恰好完美对应 4 位二进制数。

对应表（必须刻在肌肉记忆里的“乘法口诀”）：

有了这张表，一个 8 位的字节11010000，可以瞬间心算拆成两半：

• 高 4 位1101→D

• 低 4 位0000→0

• 所以这个字节就是0xD0。

这就是为什么你在写 RC522 的 I2C 地址时，11010000必须写成0xD0，没人会写二进制。

3. 为什么要加0x前缀？

因为12这种写法有歧义。编译器看到12，不知道这是十进制的“十二”，还是十六进制的“0x12”（十进制的 18）。

为了消除歧义，C 语言规定了字面量前缀：

• 0x或0X→ 十六进制 (0x12等于十进制 18)

• 0b或0B→ 二进制 (0b11010000，C 标准较晚引入)

• 无前缀 → 十进制 (12就是 12)

• 0前缀 → 八进制 (012等于十进制 10，这是容易踩的坑)

所以0x是人类写给编译器看的“翻译声明”。

4. 为什么读取结果经常是0xFF或0x00？

这直接关系到 I2C/SPI 的物理特性和故障状态，也是你调 MPU6050 和 RC522 时必经的排查点。

情况一：读到0xFF（全 1，即二进制11111111）

最常见的原因：设备无应答，总线被上拉电阻拉高。

• 物理原理：I2C 和 SPI 的 MISO 数据线都使用上拉电阻拉到高电平。当芯片正常驱动时，它会主动把总线拉低到 0V 来表示“0”，释放总线让电阻拉高表示“1”。

• 故障时刻：如果 MPU6050 没收到你的指令，或者芯片坏了根本没焊好，或者 I2C 地址写错，它就不会去碰 SDA 数据线。

• 结果：主机在 SDA 线上读到的，全是上拉电阻提供的“高电平”。连续读 8 次，就是 8 个 1，拼起来就是一个字节11111111，即0xFF。

• 典型场景：

  • 读 WHO_AM_I 返回0xFF→ I2C 地址错误或芯片未上电/未唤醒。

  • SPI 读 RC522 返回0xFF→ 片选 CS 没拉低，从机根本没被激活。

情况二：读到0x00（全 0，即二进制00000000）

最常见原因：芯片处于复位或睡眠状态，数据寄存器初始值为 0。

• 比如你忘了写PWR_MGMT_1寄存器唤醒 MPU6050，它处于睡眠状态，加速度和陀螺仪的数据寄存器全是0x00。

• 或者你读的寄存器地址本身就是默认值为 0 的状态寄存器。

情况三：读到具体值如0x12、0x68

• 这说明通信完全正常，读到的是芯片返回的真实意义的数据。

• 0x68：MPU6050 的 WHO_AM_I 寄存器，代表芯片身份。

• 0x12：可能是某个配置寄存器的默认值，或传感器数据的低字节。

5. 实际代码中的直观例子

为什么写寄存器也是用十六进制？
因为看十六进制能直接看出二进制每一位的状态，而十进制不行。

比如你要配置一个控制寄存器，想让它的第 2 位和第 3 位为高电平：

• 二进制思维：00001100

• 十六进制写法：0x0C。你甚至可以不看换算表，直接在脑子里画出来：C就是1100，对应低四位的 bit2 和 bit3 是 1。

• 十进制写法：必须写12。你看着12能瞬间反应出二进制是00001100吗？很难。

所以 MPU6050 初始化时你看到的代码全是：

MPU6050_WriteReg(0x6B, 0x00); // 用十六进制，一眼看出是复位值 MPU6050_WriteReg(0x1C, 0x08); // 0x08 是 ±4g 量程，二进制 0000 1000，直观

如果用十进制写MPU6050_WriteReg(107, 0)和MPU6050_WriteReg(28, 8)，你完全不知道 107 是哪个寄存器，8 是哪个 bit 被置位了。

6. 一表总结：为什么用十六进制，而不是别的