嵌入式系统那块儿，有时候真像是把计算机装进一个没有气阀的罐头里，略微一震动就散架。
那会儿做嵌入式，总认定这东西就是硬件+固件的包，仿佛只要把芯片的裸机跑起来，剩下的就都是代码能搞定。结局后来发现，这玩意儿跟一个隔了一百年的老房子似的，装修再好看，走进去也得先拆掉墙，看看地基是不是埋得够深，水龙头是不是拧得忒粗，水都流不进马桶里去。 说到底层逻辑，老外的说法就是那个啥，反正就是“在有限资源下最大化功能”，中文里翻译过来就是个废话。但在我给那些 Java 程序员讲的时候，他们就像是被蒙了眼的大鹏，只认定“我要用 C++ 里的指针去操作寄存器，这不科学吗？”他们不知道的是，寄存器就是那个芯片的内存条，而指针就是用来指挥内存条的铅笔，铅笔没油了，根本划不出哪一条线。 最让我头疼的是内存。
那会儿写 C 代码，开发者们大约能接纳栈和堆这种概念，毕竟他们学过数据结构，总而言之就是“临时用的先放这儿，用完了记得收回来”。但嵌入式环境不同，你拿个 RISC-V 的管住器去跑“动态分配”要么“引用计数”这种逻辑，就像让一个只能靠吃干粮撑一天的运动员去跑马拉松，最终半路就饿晕了。
那时候我见过好多项目，整个内存池用了一周还没到底线，报警都没动静，最终直接让 CPU 进死循环，风扇都转不起来。他们那帮人总认定“内存不足”是系统调度的难题，结局一查，原来是自己把堆叠得忒厚了，把栈压得忒扁了，直接给操作系统吃了大肉。 寄存器也是同理。在通用机里，寄存器只是 CPU 内存条上的一块小格子，随意写写删删就行，容量小但速度快。在嵌入式里，寄存器又是另一回事，它们是被物理锁死的，比如 R0 到 R15 这十一个编号，你只能在这十一个格子里掏东西。但有的系统赞成指令自加载要么动态扩展，这玩意儿在理论上是可行的，但在实际嵌入式架构中，往往出于上下文切换忒频繁，要么缓存一致性协议忒复杂，害得软件层面的“动态扩展”变成了“硬件层面的灾难”。 举个例子，我想写个简易的计算器，用 R0 存个数，R1 存个运算符，R2 存结局。
这挺好办，几个指令就能跑通。但目前，某个 RISC-V 处理器赞成指令自加载，即指令的编码能够直接写进去寄存器里，不用每次取指时再读一遍。理论上这能优化掉取指周期。但在我们群里吵了一架，结局证明这玩意儿在嵌入式场景下是“神来之笔”还是“灾难之源”，彻底取决于那款芯片的上下文切换频率和状态机设计。有的芯片一切换上下文，R0 里的数据就丢了，那算就不对了；有的芯片切换忒慢，每次取指都要先写寄存器再写内存，效率反而比直接写寄存器低。
这种“理论可行，实践难做”的情况，就是嵌入式开发最让人头秃的地方。 再谈谈中断和上下文切换。在操作系统里，切换上下文是平滑的，像换 actor 一样，只是临时把内存里的状态改一下就行了。但在硬实时系统中，要是中断处理逻辑忒复杂，比如在中断里要判断“我要保存这个寄存器，但我不知道要不要保存另一个”，那结局就是系统直接挂掉。
这时候开发者会陷入“我是不是漏了啥寄存器？”的自我质疑，仿佛只要代码逻辑够严密，就能容错。
实际上嵌入式不是这样，它不是要容错，而是要避免毛病形成。 还有外设驱动这块，也是那种玄学。大量嵌入式工程师喜爱用 GPIO 直接管住 LED 或传感器，认定“这是硬件，软件管不了”。结局呢？浮点运算的延迟，时钟域转换的抖动，SPI 总线上的时序违例，这些在软件层面都能解决的难题，硬件驱动一出来，就像让盲人摸象，摸到骨头，却看不见皮肉。
那时候我跟大家争论不休，说“驱动程序应当把外设走成中断源”，结局对方回怼：“那不就是硬抢占吗？那多费事啊，还要处理优先级，还要处理中断嵌套！”行吧，这确实是两难。 在理论层上，我们应当追求的是“尽可能少的状态变化”。理想的嵌入式软件，应当是一棵倒挂的树，除了根节点和少数几个关键分支，大局部节点都是死代码。所有的状态挪都应当通过中断触发，而不是通过代码流。出于代码流带来的上下文切换，在嵌入式这种对延迟敏感的系统里，就是那根刺。
比如做电机管住，要是软件里每个状态切换都要加几个原子操作，那电机转速可能还不如不停转的匀速。
这时候，理论上先把状态码存有寄存器里，让中断去触发布局指令，哪怕牺牲一点执行工夫，也比在代码流里加乱码强。 有些项目里，大家喜爱把逻辑直接写在汇编里，认定这样效率高。但调试的时候真不是省劲。出于汇编对 CPU 的依赖忒深，一旦寄存器命名不规范，要么状态机逻辑写反了，整个程序就是一片耳鸣，没有任何报错信息。
这时候开发者只能靠逻辑推理去“猜”哪儿错了，效率极低。而现代编译器，特别是 RISC-V 编译器，别看能生成微优化的汇编，但它不会生成那种“为了节省延迟，把 CPU 状态紧耦合”的指令，要不就你自己显式地写出来。
故此，理论上，嵌入式软件应当让状态机和 CPU 的内存布局保持“无耦合”，所有变态的寄存器操作都要手动管住。 最终谈谈数据输入输出。在嵌入式里，数据流往往是单向的，就连是不连续的。
比如一个工业网关，每隔 10 秒上传一次感知数据，每次上传都要换两次内存（一次栈，一次堆），还要经过 TCP/IP 协议栈的层层封装。
这种“高吞吐、低延迟”的架构，要是不小心把某些周期性的任务插进了数据流里，就会害得数据丢包或延迟超标。
这时候，理论上的“数据由此可见性”就成了难题。
要是两个线程在同一个循环里与此同时访问全局变量，看看哪位先用了，哪位后用了。在嵌入式里，要是不加锁，直接访问共享缓冲区，结局就是数据错乱。
故此，有些团队选择把逻辑分散到不同的驱动程序里，每个驱动只负责自己的“由此可见性”和“互斥”，希望这样能用更少的锁来管理更复杂的状态。 总而言之，嵌入式原理论文里的那些大道理，像空气一样，你听多了也就习惯了，但真正落地时，你得亲自去拧螺丝去测试性能。
不要总想着写个漂亮的 API 文档要么设计个优雅的数据结构，有时候，把状态码存到 R0，然后让中断去读，哪怕这行汇编多几行字，也比在 C 代码里加一个浮点运算强。
毕竟，在这个只有 4096 个格子的大房间里，如何把状态转得最快、最稳，才是真本事。
