下面给你一个“为什么嵌入式 C（如 STM32）普遍用十六进制而不是二进制来读写寄存器/地址”的系统性分析。核心观点：十六进制是对底层位模式更高效、更可靠的“人类可读编码”，与硬件资料、编译器和调试器生态形成了标准化协同。

1）语言标准与工具链支持

• 可移植性：C89/C99/C11 标准都没有二进制字面量（0b...），只有十进制、八进制、十六进制。许多编译器（如旧版 Keil armcc）不支持 0b；而 十六进制是所有 C 编译器都标准支持 的。

• 库函数/IO：标准 printf/scanf 没有 %b（二进制）格式，调试打印/日志天然用 %x。你要用二进制就得自己写转换函数或依赖非标扩展。

• 调试器与 IDE：寄存器窗口、内存窗口、反汇编器、Linker map 等默认以 hex 展示；断点地址、PC/LR/SP 等也以 hex 呈现，生态统一。

2）可读性与容错性（人因工程）

• 信息密度：1 位十六进制 = 4 位二进制（1 个“半字节/nybble”）。同样的位型，hex 更短更不易抄写出错：

  • 二进制：0b0101 0011 1010 0001

  • 十六进制：0x53A1

• 分组契合硬件：寄存器常按 4 位对齐说明（bit[7:4], bit[3:0]…），每个 hex 位正好对应 4 个物理位，查 datasheet/参考手册时非常自然。

• 快速目测：设置/清除高位/低位时，hex 更容易看出“哪一组 4 位在变化”，比 16~32 位长串 0/1 容错率更高。

3）与硬件文档的一致性

• 地址/偏移：外设基址、寄存器偏移在参考手册里都是十六进制（如 0x4002 1000）。你在代码里也写 hex，一一对应、不需换算。

• 位掩码/重置值：手册中的默认值、mask、字段宽度也常以 hex 给出（如 0xFFFF_FFFF、0xA5 key）。直接抄到代码里最不易错。

4）表达常见位操作更自然

• 单个位：用移位表达最稳妥、最可移植：

  reg |= (1u << 13); // 置位 bit13 reg &= ~(1u << 2); // 清 bit2

  这比写长串二进制直观、少错，并和 CMSIS 的位定义风格一致。

• 多位字段（nibbles/bytes）：当修改 4 位或 8 位的字段时，hex 掩码/值更简短：

  reg = (reg & ~0x00F0u) | (0x0Au << 4); // 写4位字段

  如果用二进制，要写/读 4~8 个连续 0/1，容易数错位。

5）二进制字面量的现实问题

• 可移植性差：即便有的编译器支持 0b1010, 也常是 GNU 扩展；换到另一套工具链（如旧 Keil、IAR 的某些配置）就可能编译不过。

• 维护成本：团队协作时，审阅者、调试器和脚手架工具大多默认 hex。大量二进制字面量会造成阅读/打印/定位的不一致。

6）何时“可以/值得”用二进制

• 查表/固定模式：需要直接看清每一位的图样，比如段码、GPIO 组态模板、通信帧测试数据等，可使用（在你的编译器支持 0b 时）：

  // 仅示例，前提是编译器支持 0b 前缀 static const uint8_t seg7_A = 0b01110111;

• 代码生成/宏：或用宏把位展开成人可读形式：

  #define BIT(n) (1u << (n)) reg |= BIT(5) | BIT(7);

  这样既避免二进制字面量的不兼容，又保留位级语义。

7）替代方案与最佳实践（STM32 常用）

1. 地址/偏移/重置值 → 用十六进制（与手册一致）。

2. 单个位控制 → 用移位宏：BIT(n) / (1u<<n)。

3. 多位字段 → 用掩码+移位，掩码常用 hex：

   #define RCC_CFGR_PPRE1_Pos 10u #define RCC_CFGR_PPRE1_Msk (0x7u << RCC_CFGR_PPRE1_Pos) #define RCC_CFGR_PPRE1_DIV2 (0x4u << RCC_CFGR_PPRE1_Pos) RCC->CFGR = (RCC->CFGR & ~RCC_CFGR_PPRE1_Msk) | RCC_CFGR_PPRE1_DIV2;

4. 用官方/库定义：CMSIS/LL/HAL 已提供位名、掩码、枚举，更可读、少错、可移植。

5. 调试输出 → %x，与调试器地址/寄存器视图一致。

8）小结（要点对比）

结论：在 STM32 的 C 编程中，十六进制并非“功能上优于二进制”，而是生态、可读性、可移植性综合最佳的表达方式；二进制可在特殊场景用作辅助手段，但不宜作为日常寄存器读写的主表示法。