第一次接手一块陌生板子，代码烧进去、电源灯亮着、程序也在跑，就是目标引脚纹丝不动，这种场面几乎每个做裸机开发的人都遇到过。折腾半天最后发现，不是代码逻辑错了，而是某个寄存器的第 3 位忘了置 1。如何对寄存器进行操作这个问题，看起来像是刚入门才需要问的基础题，实际上越往底层做，越会发现它决定了你能不能独立排查问题、能不能看懂别人的驱动、能不能在没有现成库函数的环境里把芯片用起来。
这篇内容聊的不是"寄存器是什么"这种教科书定义，而是我在实际项目里反复用到的操作范式：地址怎么算、指针怎么写、volatile到底防住了什么、位运算在什么情况下会翻车、外设配置的完整链路怎么走、写完没反应该按什么顺序排查。适合三类人看：一是刚接触裸机、被一堆->和移位运算符绕晕的新手；二是长期用现成库函数、想下沉一层看清楚底下发生了什么的开发者；三是已经在写驱动、但经常被"偶发性异常"折腾得没脾气的老手。文中给出的代码都是可直接套用的模板风格，寄存器命名做了抽象处理，偏移量和位定义你在自己芯片的手册里对号入座即可。
1. 寄存器操作的底层逻辑：代码最终落在哪个地址上
1.1 三类寄存器，三套完全不同的操作范式
很多人把"寄存器"当成一个东西，其实在嵌入式语境里它至少分三类，操作方式差别很大。第一类是CPU 内核寄存器，比如通用寄存器、栈指针、链接寄存器、程序状态寄存器，这些由编译器在生成代码时自动分配，写 C 语言的时候基本碰不到，只有在做启动文件、任务上下文切换、异常现场保护这类工作时才会用汇编写上几行。第二类是外设配置寄存器，它们被安排在统一的地址空间里，CPU 用普通的访存指令就能读写，改一个位就等于改一个硬件行为，这是本文的重点。第三类是外设数据寄存器，读写它本身就会触发硬件动作，比如往发送数据寄存器写一个字节，硬件立刻开始往外吐数据；读状态寄存器可能会顺带清掉标志位，这类"有副作用"的访问是最容易写出隐蔽 bug 的地方。
理解第二类的关键在于"内存映射"这四个字。你可以把芯片内部想象成一栋办公楼，CPU 只有一个门牌号系统，内存条占了其中一段，外设控制面板也被安排进了同一段门牌号走廊，只不过它们的实际位置在芯片的另一侧。CPU 并不知道自己在跟谁说话，它只是往某个地址写了一个值，总线译码器看到地址落在某个外设的范围内，就把这个写操作转给对应的硬件模块。所以配置外设这件事，本质上就是"往正确的地址写正确的值"。
提示：同一个地址在不同芯片上可能完全不是一个东西。移植代码时最忌讳的是照抄地址宏，必须回到目标芯片的寄存器映射表里重新核对基址和偏移。
1.2 明明有库函数，为什么还要会直接写寄存器
这个问题我被问过很多次。直接用库函数当然更快，工程上也更稳，但寄存器操作能力在几个特定场景下是不可替代的。第一种是资源极度受限的场合，比如某款只有几 KB Flash 的小容量芯片，库函数带来的代码膨胀可能直接吃掉一半空间，这时候手写寄存器能把体积压到最小。第二种是时序要求苛刻的场合，库函数里为了兼容各种情况往往会加参数检查、分支判断，某些高频中断里这些开销会累积成明显抖动。第三种是排查问题时，调试器里看到的永远是寄存器值，你得知道这个值是哪个位、代表什么意思，否则只能靠猜。
我把两种方式的取舍整理成了一张表，实际选型时按这个逻辑判断基本不会错：
| 维度 | 库函数方式 | 直接操作寄存器 |
|---|---|---|
| 上手速度 | 快，看例程就能跑 | 慢，需要读手册核对位定义 |
| 代码体积 | 较大，含通用分支 | 极小，通常几条指令 |
| 执行确定性 | 一般，有参数校验开销 | 高，指令数固定可预算 |
| 可移植性 | 同一厂商不同系列较好 | 差，换芯片基本要重写 |
| 问题定位能力 | 弱，出问题只能看现象 | 强，能逐位核对硬件状态 |
| 适合外设 | USB、以太网等复杂协议栈 | GPIO、定时器、串口、ADC 等常规外设 |
我的实际做法是混合使用：项目主体用库函数或厂商头文件保证开发效率，但在初始化关键路径、高频中断、以及怀疑库函数有问题的模块上，直接下沉到寄存器层。这样既不会把时间浪费在重复造轮子上，又保留了独立排查的能力。
2. 把寄存器接进 C 语言：地址、指针与 volatile
2.1 从绝对地址到结构体映射的三种写法
最原始也最直白的写法是把地址强转成指针再解引用。这种方式一眼就能看出操作的是什么地址，缺点是满屏魔数，稍微复杂一点的外设就没法维护了。为了改善可读性，通常会包一层宏，把"取地址—强转—解引用"这套动作藏起来，代码里只留下语义化的名字。再往上走就是结构体映射，把一个外设模块的所有寄存器按偏移顺序定义成一个结构体，基址强转成结构体指针，之后用->访问成员，编译器负责算偏移，读起来最接近手册的排布。
/* 写法一：直接强转，适合临时验证 */ *(volatile unsigned int *)0x40020000U = 0x00000001U; /* 写法二：宏封装，可读性和安全性平衡得比较好 */ #define REG32(addr) (*(volatile unsigned int *)(addr)) #define GPIOA_BASE 0x40020000U #define GPIOA_MODER REG32(GPIOA_BASE + 0x00U) #define GPIOA_ODR REG32(GPIOA_BASE + 0x14U) GPIOA_MODER &= ~(0x3U << (2U * 5U)); /* 清掉 PA5 的两位 */ GPIOA_MODER |= (0x1U << (2U * 5U)); /* 配成通用输出 */ /* 写法三：结构体映射，适合整个模块的批量定义 */ typedef struct { volatile unsigned int MODER; volatile unsigned int OTYPER; volatile unsigned int OSPEEDR; volatile unsigned int PUPDR; volatile unsigned int IDR; volatile unsigned int ODR; } GpioType; #define GPIOA ((GpioType *)0x40020000U) GPIOA->MODER &= ~(0x3U << 10U);结构体映射看起来最优雅，但有两个坑必须提前说清楚。第一个是填充问题：编译器有权在成员之间插入对齐填充字节，如果手册里两个寄存器之间隔着一段保留区，你必须在结构体里显式加上同样大小的占位数组，否则后面所有成员的偏移全错，写出去的值会落到完全不相干的地方。第二个是volatile加的位置：它应该加在成员类型上，而不是只在指针上加一次，volatile GpioType *这种写法在大多数编译器上行为是正确的，但一旦有人把它转成普通指针传参，保护就丢了，所以每个成员单独标volatile更稳妥。
2.2 volatile 到底在防什么，它管不住什么
volatile是我见过被误解最多的关键字。它告诉编译器的是"这个对象的值可能在程序控制流之外发生变化，每次访问都必须真的发一次访存指令，不许缓存、不许重排、不许删减"。典型的翻车场景是轮询标志位：你写了一个while (!(REG32(STATUS) & 0x01)) ;等待硬件置位，如果 STATUS 没有volatile修饰，编译器一看循环体里没有任何副作用、条件表达式在它眼里是个不变量，直接把整个循环优化掉，程序瞬间失效。加了volatile之后每次循环都会真的去读一次内存，硬件改动的值才能被看到。
但volatile不保证原子性，也不保证内存序，这两点经常被混为一谈。REG |= (1 << 3)这种写法在汇编层面是"读—改—写"三条指令，如果这中间来一个中断，中断里也改同一个寄存器，回到主流程后中断的修改就被覆盖了。更麻烦的是某些寄存器设计成"写 1 清零"，你用|=去置位一个标志，实际上会把其他已经是 1 的位全部清掉，因为读出来的值里那些位本来就是 1，原样写回去就被硬件解释成"清除请求"。
/* 危险写法：读改写，且对"写1清零"型寄存器语义错误 */ REG32(FLAGS) |= (1U << 3); /* 正确写法：只写目标位，其他位写 0，不受读回值影响 */ REG32(FLAGS) = (1U << 3);2.3 四种基本位运算，以及它们各自的风险边界
寄存器操作说到底就是四种动作：置位、清零、翻转、读字段。置位用|=，清零用&= ~，翻转用^=，读字段用>>加掩码。这四句话写起来简单，风险点在于它们绝大多数都是"读—改—写"三合一，对并发不友好。
| 操作 | 惯用写法 | 隐含风险 | 适用条件 |
|---|---|---|---|
| 置位 | REG |= (1U << n) | 读改写非原子，可能覆盖他人修改 | 单线程且寄存器非写1清零型 |
| 清零 | REG &= ~(1U << n) | 同上 | 同上 |
| 翻转 | REG ^= (1U << n) | 同上 | 同上 |
| 写字段 | REG = (REG & ~MASK) | (v << s) | 两次访存之间可能被中断打断 | 建议放临界区 |
| 读字段 | v = (REG & MASK) >> s | 若寄存器有读副作用可能误清标志 | 确认手册读行为 |
针对并发问题，芯片厂商其实给了硬件解法：很多 GPIO 模块专门提供"置位寄存器"和"复位寄存器"，你往里面写哪些位，硬件就原子地改哪些位，不经过读回步骤，天然免疫中断打断。这类寄存器存在的时候一定要优先用，比自己加关中断要轻量得多。没有硬件支持的情况下，就得靠软件手段兜底：把读改性操作放进临界区，或者针对同一寄存器维护一份"影子变量"，所有修改在软件副本上完成，最后整体写一次。
3. 从零配置一个外设：完整流程与参数推导
3.1 第 0 步永远是时钟使能，八成"没反应"出在这里
现代 MCU 为了省电，几乎所有外设默认都是断时钟的。寄存器地址你能读写、读回来的值也在变，但外设内部逻辑没有时钟就完全不工作，表现就是"配置全对、引脚不动"。这个坑新手上手必踩，因为代码不会报错，调试器里寄存器显示也正常，非常具有迷惑性。
/* 使能挂在某条总线上的 GPIO 与串口，位号以你芯片的手册为准 */ #define RCC_APB2ENR REG32(0x40023844U) RCC_APB2ENR |= (1U << 2); /* 置位后硬件才开始给对应外设供时钟 */ /* 部分器件有时钟稳定等待，使能后回读一次确认 */ while (!(RCC_APB2ENR & (1U << 2))) { }注意：外设时钟使能寄存器经常被设计成"清 0 使能"或者"写 1 有效但读回恒为 0"的特殊行为，一定要看清手册里这一位的读写属性，别把回读校验写成死循环。
3.2 GPIO 模式寄存器：两位一组的坑最多
GPIO 的模式寄存器通常是一个引脚占两位，四组取值分别对应输入、输出、复用、模拟。坑在于很多人习惯性地用|=单独置位，结果旧值残留导致模式错乱。正确顺序永远是先清零目标位、再按新的编码置位，两步之间不要插入任何可能改变该位的操作。速度寄存器和上下拉寄存器同样是两位一组，只有输出类型寄存器是一位一引脚，混着写就容易错位。
/* 通用 GPIO 引脚模式设置，pin 取 0~15 */ static void gpio_set_mode(unsigned int base, unsigned int pin, unsigned int mode) { unsigned int reg = REG32(base + 0x00U); reg &= ~(0x3U << (pin * 2U)); /* 先清掉这 2 位 */ reg |= (mode & 0x3U) << (pin * 2U); /* 再写入新模式 */ REG32(base + 0x00U) = reg; } /* 复用功能选择：pin 小于 8 用低寄存器，否则用高寄存器，每引脚 4 位 */ static void gpio_set_af(unsigned int base, unsigned int pin, unsigned int af) { unsigned int idx = (pin < 8U) ? 0x20U : 0x24U; unsigned int shift = (pin & 0x7U) * 4U; unsigned int reg = REG32(base + idx); reg &= ~(0xFU << shift); reg |= (af & 0xFU) << shift; REG32(base + idx) = reg; }复用功能这块我吃过一次亏：引脚模式已经配成复用，上下拉也对，波形就是不出。查了两个小时才发现复用编号写成了相邻通道的值，硬件把信号导向了另一个内部通道。复用编号不是引脚编号，也不是随便填的，必须逐个对照手册的复用映射表，这是纯手工活，没有捷径。
3.3 串口波特率：把手册公式真的算一遍
波特率计算是寄存器操作里少数需要真正动笔算的地方。标准公式是分频值 = 外设时钟 / (过采样倍数 × 目标波特率)，16 倍过采样时除以 16，8 倍过采样时除以 8。算出来的分频值再拆成整数部分和小数部分，整数进高位、小数乘以 16 后取整进低位。
拿 48MHz 主频、目标 115200 举例：48000000 / 115200 = 416.667，再除以 16 得到26.0417。整数部分是 26，小数部分0.0417 × 16 = 0.667，四舍五入得 1。于是寄存器值等于(26 << 4) | 1 = 0x1A1。回算实际分频值是26 + 1/16 = 26.0625，实际波特率48000000 / (16 × 26.0625) = 115108，误差(115200 - 115108) / 115200 ≈ 0.08%，远低于通常要求的 2%~3% 上限，可以放心用。
| 外设时钟 | 目标波特率 | 分频值 | 整数/小数 | 寄存器值 | 实际误差 |
|---|---|---|---|---|---|
| 48 MHz | 115200 | 26.0417 | 26 / 1 | 0x1A1 | 0.08% |
| 72 MHz | 115200 | 39.0625 | 39 / 1 | 0x271 | 0 |
| 48 MHz | 9600 | 312.5 | 312 / 8 | 0x1388 | 0 |
| 8 MHz | 115200 | 4.3403 | 4 / 5 | 0x45 | 1.36% |
最后一行值得单独说：8MHz 时钟跑 115200 误差已经到 1.36%，虽然勉强能用，但如果时钟源本身精度不够（比如内部 RC 振荡器有 ±1% 偏差），叠加起来就可能超过 3%，表现为通信偶发乱码、换个板子就好。这种"时好时坏"的问题最难查，因为它跟你写的代码逻辑毫无关系。我现在的习惯是：只要波特率误差超过 1%，就重新选时钟源或者换波特率，不给自己留隐患。
3.4 状态标志与数据寄存器：读写顺序不能乱
串口发送一个字节的标准流程是"等发送寄存器空—写数据—等发送完成"。这里有两个不同的标志位，含义不一样：发送数据寄存器空表示可以往里塞下一个字节了，发送完成表示移位寄存器也吐完了、总线上真的安静了。只等前者就切换收发方向或者进入低功耗，最后一个字节会被截断，这个 bug 在 115200 下可能十天半个月才暴露一次。
static void uart_send_byte(unsigned char ch) { while (!(REG32(UART_BASE + 0x00U) & (1U << 7))) { } /* 等发送寄存器空 */ REG32(UART_BASE + 0x04U) = ch; /* 写入数据寄存器 */ } static void uart_flush(void) { while (!(REG32(UART_BASE + 0x00U) & (1U << 6))) { } /* 等发送完成 */ }接收侧更讲究顺序。绝大多数串口的清除标志序列是"先读状态寄存器、再读数据寄存器"，两步缺一不可，而且顺序不能颠倒。如果你先读了数据寄存器，硬件认为你已经把数据取走了，标志位自动清掉，看起来一切正常；但如果在中断服务函数里只读状态不读数据，标志永远不会清，中断会反复触发，表现为程序卡死在中断里出不来。这类现象在调试器里看就是"主循环一行都不走"，很容易误判成死机。
4. 工程化封装：让寄存器代码可读、可维护、可移植
4.1 四种封装风格的实际取舍
裸地址最直接，但只适合一次性的验证代码。宏封装平衡性最好，代价是没法做类型检查。结构体映射可读性最强，代价是必须精确处理保留区。厂商头文件最省事，代价是换系列时要重新适配。我在实际项目里的分层是：最底层用厂商头文件定义地址和位掩码，中间层用自己的宏或内联函数封装操作语义，应用层完全不碰寄存器。这样既享受了厂商维护地址定义的好处，又保证业务代码不会散落一堆移位运算。
至于寄存器操作要不要抽成函数，我的判断标准是看调用频次。中断里每秒调用几万次的热点路径，用宏或者static inline展开，避免函数调用开销；初始化阶段只跑一次的配置，写成普通函数完全没问题，可读性远比那点开销重要。
4.2 保留位、只读位、写 1 清零位：三条铁律
铁律一：保留位要写复位值。手册里标成"Reserved"的位不是给你发挥的空间，它们可能接到内部测试逻辑上，乱写会导致各种无法解释的行为。安全做法是读出原值、只改你要改的位、原样写回，或者干脆按手册要求写固定值。
铁律二：只读位不要写。有些状态寄存器和配置寄存器共用地址，写操作会被硬件忽略，看起来无害，但如果这个寄存器旁边紧挨着一个有写保护机制的寄存器，某些器件的写保护是按地址区间生效的，误写可能触发保护锁定，后续所有配置全部失效，必须复位才能恢复。
铁律三：写 1 清零的位绝对不能用|=累积。前面提过一次，这里再强调，因为它造成的 bug 极其隐蔽。正确的模式是先用临时变量构造出"这一轮要清哪些位"，最后一次性写入，而不是逐位|=。
/* 一次性清除多个中断标志：先构造掩码，再整体写 */ unsigned int mask = 0; mask |= (1U << 1); mask |= (1U << 4); REG32(IRQ_FLAG_REG) = mask; /* 注意是 = 不是 |= */4.3 位带操作：原子性的硬件解法
位带是 Cortex-M 系列里一个很好用的特性，原理是把某块地址区域的每一个比特映射成别名区里的一个 32 位字。你往别名地址写 0 或 1，硬件就原子地改对应位置的那一位，全程不需要读回。地址换算公式是：别名地址 = 别名基址 + (字节偏移 × 32) + (位号 × 4)。
举个例子，目标位在0x20000000的第 3 位，字节偏移是 0，位号是 3，别名地址就是0x22000000 + 0×32 + 3×4 = 0x2200000C。写 1 到0x2200000C，0x20000000的 bit3 就被置上了。
#define BITBAND_ALIAS(addr, bit) \ (*(volatile unsigned int *)(0x22000000U + (((unsigned int)(addr) - 0x20000000U) * 32U) + ((bit) * 4U))) #define LED_ON() BITBAND_ALIAS(&gpio_out_shadow, 5) = 1U #define LED_OFF() BITBAND_ALIAS(&gpio_out_shadow, 5) = 0U它的好处是绝对原子、代码直观、编译出来只有一条存储指令。坏处是只能作用于位带区（通常是 SRAM 的低位区域和外设区的一部分），而且每个位操作占 4 字节地址空间，密集使用会撑大代码。我的用法是：只在真正需要原子性的场景用位带，比如中断和主循环都会改的软件标志位，普通配置代码没必要绕这一圈。
5. 实操排查：寄存器写了没反应的排查清单
5.1 按顺序走五步，别跳步
我在现场排查时有个固定顺序，从不跳步，因为跳步往往意味着漏掉最傻的那个原因。第一步查时钟，外设时钟使能了吗，总线分频是不是配错了导致外设时钟跟你想的不一样。第二步查引脚，模式是不是配成了复用，复用编号对不对，有没有被别的模块占用。第三步查写保护，这个寄存器是不是需要先写解锁序列，某些配置寄存器写之前要连续写入两个特定值，写错或者顺序反了都不会生效，而且不会报错。第四步查编译器，优化等级是不是开太高把轮询循环优化掉了，volatile加没加。第五步才查硬件，外部器件供电了吗，上拉电阻焊了吗，探头接的位置对不对。
这个顺序背后是有概率依据的：时钟和引脚配置问题占了绝大多数，写保护次之，编译器问题再次，硬件问题最少但最难查。按这个顺序走，通常前三步就能定位。
提示：写保护类寄存器的解锁序列通常要求在短时间内连续完成，中间如果插了打印语句或者断点，某些器件会因为超时把解锁状态复位，表现出来就是"单步调试能过、全速跑就失败"。
5.2 并发读改写竞争：最常见的偶发异常源头
有一类 bug 特别折磨人：跑一千次对一次，或者加了打印就好了、去掉打印就出错。这类现象九成以上是读改写竞争。典型场景是主循环里在改某个控制寄存器的使能位，定时器中断里也在改同一个寄存器的另一个位，两边都是|=，谁后写谁赢，先写的那一方修改凭空消失。
解决办法按优先级排：能用硬件原子寄存器就用硬件（置位/复位寄存器、位带），其次用影子变量（软件维护一份完整副本，改完整体写一次），最后才用关中断临界区（简单粗暴但会影响中断响应延迟，高频中断里慎用）。
/* 临界区宏：保存—关中断—恢复，注意要能嵌套使用 */ static unsigned int crit_nesting = 0; static unsigned int crit_primask = 0; static inline void crit_enter(void) { unsigned int p = read_primask(); disable_irq(); if (crit_nesting++ == 0U) { crit_primask = p; } } static inline void crit_exit(void) { if (--crit_nesting == 0U) { write_primask(crit_primask); } }用嵌套计数而不是简单地"关—开"，是因为实际工程里临界区经常嵌套调用，如果内层退出时直接把中断打开了，外层的保护就形同虚设，这类 bug 排查起来非常痛苦。
5.3 常见问题速查表
| 现象 | 最可能原因 | 快速验证方法 |
|---|---|---|
| 配置全对但引脚无输出 | 外设时钟未使能 | 回读时钟使能寄存器对应位 |
| 输出电平一直不变 | 模式寄存器残留旧值 | 打印模式寄存器原始值 |
| 波形有但频率不对 | 分频或重装载值算错 | 反算理论值对比实测 |
| 单步能过全速失败 | 解锁序列超时或被优化 | 关优化后复测 |
| 中断进不去反复触发 | 标志位未按顺序清除 | 检查读状态/读数据顺序 |
| 偶发数据错乱 | 读改写竞争或波特率误差大 | 加临界区、重算波特率 |
| 换板子就出问题 | 时钟源精度不足 | 换外部晶振验证 |
| 调试器读寄存器得 0 | 该寄存器读操作有副作用 | 改用内存窗口或示波器 |
6. 验证手段：怎么证明寄存器真的写进去了
6.1 调试器窗口的两个陷阱
调试器里的外设寄存器视图很方便，但它有两个坑。第一个坑是某些寄存器读一次就会改变状态，你在窗口里刷新一下，硬件行为就被你改掉了，尤其是清除标志类寄存器，看着看着标志就没了，然后你以为是程序清的。第二个坑是调试暂停会冻结时序，对于依赖超时、握手、时钟稳定的外设，暂停期间的硬件行为跟全速运行完全不是一回事，用暂停态下的寄存器值去推断全速行为，结论经常是错的。所以我的习惯是：时序敏感的外设，宁可用逻辑分析仪看波形，也不完全相信调试器里的静态快照。
6.2 回读断言：五分钟省下五小时
初始化函数写完顺手加一段回读校验，是我这些年最划算的习惯。配置完就把关键寄存器的值读回来，跟期望值逐位比对，不一致就打印出来。这段代码在正式发布时会被条件编译掉，不占空间，但开发阶段能第一时间抓到"写是写了、但没生效"的问题。
static int reg_check(unsigned int addr, unsigned int mask, unsigned int expect) { unsigned int got = REG32(addr) & mask; if (got != expect) { log_printf("REG 0x%08X MISMATCH: got 0x%08X expect 0x%08X\r\n", addr, got, expect); return -1; } return 0; } /* 初始化末尾统一跑一遍 */ reg_check(GPIOA_BASE + 0x00U, 0x3U << 10U, 0x1U << 10U);更进一步的做法是把所有关键寄存器打一份快照，存到数组里，出问题时跟正常版本做差异对比。有些团队会把这份快照固化进自动化测试，每次提交代码跑一遍，寄存器配置被动改掉能立刻发现。这套机制在多人协作的项目里价值极高，因为寄存器配置往往藏在某个深层初始化函数里，代码评审时根本看不出来。
6.3 逻辑分析仪：最后的裁判
寄存器值全对、代码逻辑全对、波形还是不对，这时候就该上逻辑分析仪了。我遇到过一个典型案例：串口配置寄存器回读全部正确，引脚模式也对，就是收不到数据。最后用分析仪一抓，发现引脚上下拉配成了下拉，而对接的设备是开漏输出、没有外部上拉，两边都往下拉，总线永远是低电平。寄存器层面看不出任何问题，因为它确实配成了你想要的值，只是这个值本身选错了。
这类问题提醒我一件事：寄存器操作的正确性只能证明"代码执行符合预期"，不能证明"硬件配置符合需求"。前者靠回读和断言，后者只能靠对着原理图和对方设备的接口特性逐条核对。两块板子对接的时候，我现在的固定动作是先把双方的电气特性表列出来对一遍：电平标准、上下拉、驱动能力、是否开漏、是否需要外部电阻，对完了再动手写代码。
踩过的坑里，最不值当的一类是把简单问题复杂化。有一次某个外设死活不工作，我翻手册查时序、换芯片、怀疑焊接，折腾了一下午，最后发现是初始化函数里有一行REG = 0x00写在配置之后，把前面的配置全冲掉了。从那以后我养成了一个习惯：每个外设的初始化函数只在开头有一次整体清零，之后的所有配置都往后追加，绝不在中间插整寄存器写操作。这个规矩看着死板，但它挡住的是最低级的错误，而最低级的错误往往最费时间。
