干STM32这行的，谁没跟HardFault死磕过。为什么会死磕，因为有些问题调代码调不出来，逻辑没问题，这是由于对stm32内部结构不太清楚，只调代码调不出来，不是代码能力不够，而是对Cortex-m4寄存器不够了解。

我们早期在学习Stm32时不是用的HAL库而是标准库，甚至有的功能直接用的寄存器编程，没有使用封装程度非常高的HAL，使得我们对寄存器了解更透彻，原理理解的也更深入，现在的人大部分使用HAL，优点是编程容易，拖拽加属性配置就够了，代码很少，但是也少了原理的更深层理解。而要调试有些错误就是需要对寄存器了解才能达到我们的目标，下面就是对寄存器的介绍：

Cortex-M4内部寄存器

上述图示中的是Cortex-M4内部的寄存器其实不多，加上异常屏蔽寄存器数下来一共就21个，可以分成4类

R0到R12是通用寄存器，基本工作都是这些寄存器干的

R13、R14、R15是三个核心特殊寄存器，管程序跑哪、怎么回来

xPSR是状态寄存器，记录运算结果和CPU状态

剩下几个是系统控制寄存器，管中断、特权级这些东西

这是ARM核的，32bit宽度，下面就是寄存器的详细介绍

一、通用寄存器R0-R12

我最早以为叫"通用寄存器"就是随便用的临时变量，想怎么赋值就怎么赋值，直到第一次写C和汇编混编做微秒延时——在延时函数里随手把R5拿来当循环计数器用了，跳回主函数之后，一个全局的设备状态变量值全乱了，查了整整两天才反应过来：这13个寄存器根本不是平权的，有个叫AAPCS的调用约定，规矩比公司代码规范还严，你写的所有C代码编译成汇编，全是按这个规矩来的，你乱改不崩才怪。

规矩其实很简单：R0到R7是低寄存器，不管是16位短指令还是32位Thumb-2长指令，都能直接访问它们，是出镜率最高的"主力打工人"。平时做加减乘除、读写内存地址、给函数传参数、存返回值，基本全靠这八个寄存器忙活。

R8到R12是高寄存器，就金贵多了——只有32位的Thumb-2指令能碰到它们，16位短指令根本操作不了。写个GPIO翻转、串口发字节这种简单小函数，基本见不到它们出场，只有做FIR滤波、浮点运算这种复杂算法的时候，编译器才会把它们掏出来用。多了这五个能直接用的临时寄存器，就能少往栈里倒腾好几次数据，少几次内存访问速度自然就上去了。不过这几个你真不用特意背，写C代码的时候编译器比你会分配，我写了快十年STM32，也就手写汇编做速度优化的时候特意指定过它们，平时根本不用操心。

我当年第一次看编译器给简单函数生成的反汇编，都看愣了。就一个两数相加的函数，编译完就两行汇编：

ADD R0, R0, R1

BX  LR

为什么能这么短？就是AAPCS规矩卡死了：函数前四个参数按顺序塞R0-R3，返回值直接放R0里。进来的时候两个参数已经在R0和R1里了，加完结果直接就在返回位置，跳回去就完事，全程连栈都没碰，一个周期就跑完。

之前有人说寄存器编程比HAL库快，根子其实就在这：很多简单操作HAL库外面包了好几层参数检查、分支判断，不开优化的话，本来一条指令能完事的活，绕了好几个函数调用，压栈出栈当然费时间。但也别听网上瞎吹一棍子打死HAL，开个-O2最高优化，简单函数全被编译器内联成单条寄存器操作，和你直接写寄存器速度根本没差，也就极端时序要求的场景需要抠这点效率。

二、栈顶指针R13（SP）

SP说穿了就是栈顶指针。Cortex-M4用的是满递减栈，压栈的时候先把SP减4，再往地址里存数据，所以SP永远指着最后一个压进去的有效数据。这个概念不难，但我当年第一次移植UCOS-II到STM32F407的时候，被它的双栈设计整懵了快一周。

一开始我以为SP就是一个寄存器，切任务的时候把栈指针地址换过去不就行了？结果写好的调度器一切任务就跑飞，查了好久才知道，Cortex-M4是‌真做了两个物理上独立的SP寄存器‌，不是软件模拟改值，是硬件上就有俩：

一个叫MSP（主栈指针），上电默认就用它，不管程序跑在哪，只要进中断、进异常，硬件强制切回MSP。这是内核的"安全栈"，永远不会被用户代码搞坏，哪怕你任务栈溢出去了，内核异常处理还能正常跑。

一个叫PSP（进程栈指针），只有在线程模式下才能用。RTOS里每个任务独立的栈空间，全靠PSP来指，任务切换的时候根本不用把栈里的数据倒来倒去，调标准库自带的__set_PSP()改个指针值，几行汇编就切完了，快得离谱。

裸机写代码你可能一辈子都碰不到PSP，但只要上操作系统，这东西就是任务切换的核心。当年裸机开发我还踩过一个所有新手都犯过的错：照着官方例程把栈大小设成1K，点灯跑串口都没问题，一加printf打印浮点数，跑两步就飞。后来才明白栈大小根本不用对着代码硬算，先开个4K跑起来，调试的时候读一下SP到过的最低地址，看看最多用了多少栈空间，再往下减就行，人脑算出来的栈大小永远不准，别费那个劲。

三、LR（R14）：链接寄存器，存放返回的地址

LR的功能特别纯粹：存返回地址，告诉你"从哪来的，该回哪去"。，比如跳转指令有B和BL，B只跳转不返回，BL就会把返回地址存入LR，等需要返回时就把LR存入的地址拿来使用。

刚学写ARM汇编的时候我就遇到一个问题：当时写了个串口发送字符串的函数，里面又调用了个1ms延时函数做超时判断，结果发送完返回的时候，程序直接飞到不知道哪段代码里去了。查了好久都没找到，后来直接仿真运行，一行代码一行代码进行调试，发现它一直在串口发送和延时函数中跳转，这才反应过来——我进延时函数没先把之前的LR压栈！执行BL调子函数的时候，硬件直接把LR里原来主函数的返回地址给覆盖了，你不提前存起来，等想返回的时候早就找不到回家的路了，程序可不就飞了。写C的时候编译器会自动帮你处理压栈，所以你感觉不到，但手写汇编的时候，这个坑几乎所有人都踩过。

不过中断里的LR你不用操太多心，它存的不是普通的返回地址，是个叫EXC_RETURN的特殊返回码。中断服务程序跑完把这个值塞回PC，硬件自动知道该用哪个栈、恢复哪些寄存器、切回什么模式，比老ARM7需要手动进出栈方便太多了，标准库的中断函数你正常写业务逻辑就行，不用管现场保护的事。

四、PC（R15）：程序计数器，指哪执行哪

PC就是程序计数器，永远指向‌当前正在执行指令的下一条地址‌。正常执行的时候，跑完一条16位Thumb指令PC加2，跑完32位Thumb-2指令加4，一条一条顺序往下走，你改了PC的值，程序就跳走了——说白了，所有函数调用、分支判断、中断跳转，本质都是硬件在改PC的值。比如函数返回，其实就是把调用函数的地址放在LR中，在想要跳回来时再把LR保存的地址赋给PC就跳转回来了

五、xPSR：运行状态的"黑匣子"

xPSR其实是三个独立的状态寄存器挤在同一个地址里，算是CPU的"运行记录本"，CPU刚干了什么、现在在干嘛，全记在这上面。

APSR是我们平时打交道最多的，运算完的结果标志全存在这四个位里：

N位记结果是不是负数

Z位记结果是不是0

C位记加法有没有进位、减法有没有借位

V位记有符号数有没有溢出。

别觉得这些位没用，你写的if(a == b)判断相等、for循环判断结没结束、两个数比大小跳分支，编译出来本质上都是运算完查这几个位，然后决定跳不跳转。

IPSR就更简单了，里面存着当前正在执行的异常编号。当年调电机驱动的时候，出现过好几次高优先级中断堵死低优先级任务的问题，我就是在调试器里读IPSR的值，一眼就看到是ADC采样中断占着CPU不放，查起来特别快，不用瞎猜是哪个中断出了问题。

EPSR是硬件自己维护的，主要存Thumb状态位和IT指令块的状态，我写了这么多年代码从来没手动操作过，不用特意去了解。

六、几个系统级寄存器，懂了能少走很多弯路

剩下几个系统级寄存器，平时写业务代码你可能感觉不到它们的存在，但标准库里的内核函数，本质全是在操作这几个寄存器：

‌PRIMASK‌：就是全局中断开关，标准库的__disable_irq()和__enable_irq()本质就是改它。改个共享变量、操作几字节的短临界区用它就行，用完赶紧打开，关太久了串口丢数据、定时器不准都是轻的。

‌FAULTMASK‌：比PRIMASK狠多了，连HardFault都能屏蔽，我也就做极端故障复位的时候用过一次，平时别碰。

‌BASEPRI‌：我做电机、四轴这类高实时性项目的时候最喜欢用的寄存器。你给它设个优先级阈值，所有优先级比它低的中断全会被暂时屏蔽，高优先级的电流采样、编码器采样中断照常跑，比直接关全局中断优雅太多，不会影响系统硬实时性，标准库__set_BASEPRI()一行代码就搞定。

‌CONTROL‌：管两件事，一是线程模式跑特权级还是用户级，二是当前用MSP还是PSP。当年移植UCOS任务切换的时候，改完PSP最后一步就是改这个寄存器，切到用户级就跳去任务代码跑了，几行汇编的事。

使用标准库延时时，我们常用的两种方法，一种是直接循环，还有一种就是使用滴答定时器，通过直接读取滴答定时器SysTick->VAL这个当前计数值寄存器，算好系统时钟周期数轮询，延时精度能到一个时钟周期，比直接循环准多了。说白了就是摸透了寄存器的行为，根本不用被库函数封装限制住。

七、真碰上HardFault了，怎么查？

最后简单提两句大家最怕的HardFault，真跑飞了也不用慌，更不用上来就一行行注释代码碰运气：进了Fault之后先找对SP，看栈帧里保存的PC值，三秒钟就能定位到崩在哪条指令；再读下CFSR寄存器，是数组越界、除零、非法指令还是栈溢出，写得明明白白，具体步骤网上资料很多，我就不啰嗦了。

其实我一直觉得，现在开发工具越来越方便是好事，CubeMX确实能省很多初始化的重复劳动，但底层的逻辑从来没变过。我当年学STM32的时候，没有这么多现成的库可以调用，配个外设要翻好几天手册一位一位设寄存器，慢是慢，但配完之后你是真知道每一位写1是干什么、写0会有什么效果，出了问题根本不用靠猜。

我们华清远见再讲STM32开发时，也不会直接讲HAL库，我们一般是先讲寄存器，再大量讲标准库，最后再讲HAL库，这样原理理解会更透彻。

寄存器从来不是什么书本上高深的黑科技，它就是CPU干活的工作台——你写的每一行C代码，最后编译完全是在操作这些寄存器。没事的时候点进标准库或者HAL库的源码看看，它这个函数到底改了哪个寄存器的哪几位，比你看十篇入门教程印象都深。底子扎实了，再碰到什么奇奇怪怪的问题，你心里就不慌了。