下面給你一個“為什么嵌入式 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 編程中，十六進制并非“功能上優于二進制”，而是生態、可讀性、可移植性綜合最佳的表達方式；二進制可在特殊場景用作輔助手段，但不宜作為日常寄存器讀寫的主表示法。