1. 16MHz 的 AVR 撞上硬实时需求：协处理这条路是怎么被逼出来的

XLR8Core 这个名字第一次出现在我视野里的时候，我正在被一个步进电机项目折磨。主控是一块经典 8 位 AVR 板型，跑在 16MHz，靠软件定时器产生四路脉冲，每一路都要独立调速，还要同时读两个编码器做闭环。结果很干脆：波形抖得像心电图，电机在低速段一顿一顿，串口打日志一开，脉冲直接错乱。这不是代码写得丑的问题，是 16MHz 这个物理上限摆在那里——一个脉冲周期里，主控能执行的有效指令就那么几十条，分给四路输出加两路采样，每路平均不到十条。寄存器接口框架这类东西，就是在这样的账算不下去的时候被逼出来的。

先把话说清楚：XLR8Core 是 Arduino 生态下一套面向 FPGA 协处理的寄存器接口框架。它要解决的问题很具体——主控（那颗 8 位 AVR）不再亲自去"算"每一个波形、每一次采样，而是把这类时序敏感、重复度高的活儿甩给 FPGA 里预先综合好的硬件模块；主控自己退回到"指挥官"的位置，通过一组内存映射的寄存器去下发参数、读取状态、取回结果。框架的核心价值不在于 FPGA 有多快，而在于主控和硬件模块之间那条约定的、可复用的通信契约。有了这条契约，你在 sketch 里写几行寄存器读写，就能调动硬件并行执行；没有这条契约，每加一个功能就要重新设计一遍通信协议，项目根本推不动。

这篇文章适合谁看？如果你手上有一块"主控 + 板载 FPGA"的混合板卡，想在 Arduino 里把 FPGA 用起来，却卡在"不知道从哪儿下手、寄存器怎么划、时序怎么对上"这一步，那接下来的内容基本能当施工图用。如果你只是想了解软硬协同的分层思路，也能从里面拿到一套可以直接搬到其他平台的设计方法。我不会假设你懂 Verilog，但会假设你能看懂 C 结构体和基本的数字电路概念。

先摆一个我认为最重要的判断：在这类板卡上，寄存器接口不是"一种选择"，而是唯一合理的选择。主控和 FPGA 在物理上就在同一块板子上，共享同一组引脚、同一个电源域，中间隔着的只有几毫米走线。这种距离下再去搞一套串口协议、加两颗电平转换芯片、写一套帧格式和校验，纯属自找麻烦。板内通信的本质是"共享总线"，而共享总线最自然的抽象就是地址加数据——也就是寄存器。搞清楚这一点，后面的所有设计取舍都顺理成章。

2. 一张寄存器地图撑起整个框架：地址、方向与位域的三层设计

2.1 地址空间怎么切：四类寄存器定骨架

寄存器接口框架的第一份文档，永远应该是一张地址表。我在实际项目里踩过的最冤枉的坑，就是一开始懒得规划地址，随手给每个功能分配一个编号，做到第三个外设的时候发现地址撞了、位定义冲突了，回头改要动硬件综合、动驱动、动上层应用，三头一起改，一天就没了。所以现在我的习惯是：动手写第一行代码之前，先把整张地址表定死，并且留足扩展空间。

一张合理的地图通常按功能切成四类，这四类在访问属性、更新频率、读写时序上的要求完全不同，混在一起设计必然出问题。

控制寄存器和状态寄存器要严格分开，这是硬规矩。我见过有人图省事，把"启动"位和"完成"位塞进同一个字节，读的时候还得把无关位屏蔽掉。这种设计在单任务里勉强能跑，一旦主控侧有中断服务程序也在访问同一个字节，读-改-写就会互相踩——中断里改了控制位，主程序回写的时候把刚置起来的状态位又冲掉了。分开之后，控制寄存器只写不常读，状态寄存器只读不常写，冲突面直接砍掉一大半。

地址粒度我建议按 1 字节对齐，哪怕某个寄存器只用了 2 个 bit，也独占一个地址。理由是 8 位总线做位寻址会让硬件译码复杂一个数量级，而地址空间在最常见的实现里至少有 256 个，够用得很。省地址不值钱，译码逻辑简单才值钱。

2.2 访问属性：RO、RW、W1C、RC 各自的战场

寄存器不是只有"能读能写"两种。真正好用的框架至少支持四种访问属性，每一种都对应一类具体问题。

RO（只读）用于状态位。硬件侧驱动这个寄存器的输出，主控侧写它没有任何效果。硬件上可以直接把写使能信号掐掉，软件上则在文档里标注清楚，避免后来的人白写代码。

RW（读写）用于控制和配置。这是最普通的一种，但要注意"读回来的值是否等于写进去的值"。有些寄存器做了位宽截断或者范围钳位，写 255 读回来是 200，如果驱动层不告诉上层这件事，上层做累加计算就会莫名其妙跑偏。

W1C（写 1 清零）用于中断标志和错误标志。这个设计的意义在于：它天然是"读-改-写安全"的。你想清第 3 位，就只写 0x08 过去，其他位写 0 不影响。如果用普通的 RW 加"写 0 清零"，那你清某一位的时候必须先把整个字节读回来、改一位、再整体写回去，中间只要硬件置了新标志，就会被你的回写抹掉——这种偶发丢事件的问题极难排查，日志上表现为"中断偶尔丢一次"，实际是软件把硬件刚举起来的手按了下去。

RC（读清零）用于 FIFO 弹出、计数器取值这类语义。读一次就把内容清空，适合"取走即消费"的场景。但它有个副作用：调试的时候用调试器看一眼寄存器，值就没了。所以我在实际项目里对 RC 类型的寄存器一律加一个"影子副本"地址，读主地址消费数据，读副地址只看不清，调试体验好很多。

这四种属性的组合，基本能覆盖 95% 的外设需求。剩下的边缘情况，比如"写任意值都触发一次动作"的触发寄存器，我一般也归到 RW 里，硬件侧忽略写入的数据、只看写选通信号，文档上标注一行"写入值无意义"即可。

2.3 位域表怎么定才不会互相打架

位域是寄存器设计里最容易留下长期债务的地方。一条我用了很多年的规则：一个字节里，同方向的位尽量聚在一起，不同方向的位不要分散。控制寄存器里的使能位、模式位放低位，保留位放高位，中间不要挖洞。挖洞的后果是后面想加功能的时候，你得在洞里塞新位，而新位的语义和旁边的老位毫无关系，代码里就会出现一堆(reg & 0x2C) >> 2这种没人看得懂的表达式。

更具体一点，模式选择这种需要多个 bit 表达的字段，一定要从 bit0 开始、连续排列，并且预留足够宽度。我见过一个项目把三位模式字段放在 bit3~bit5，后来模式从 5 种扩到 9 种，三位不够了，只能再加一个 bit 到 bit7，结果硬件侧译码要同时看两段不连续的位，代码丑到没法维护。改成"模式字段占 bit0~bit3，四位，16 种模式"之后，硬件侧一个 case 语句就写完了。

保留位不要写成"未使用"，要写成"保留，写 0"。这两个说法在行为上不一样：前者暗示随便写什么都行，后者明确要求写 0。硬件侧对保留位的处理也要统一——最省事的做法是忽略写入、读出恒为 0，这样上层做回读校验的时候不会被保留位的随机值干扰。

3. 一次寄存器访问到底发生了什么：总线时序与握手链路拆解

3.1 地址建立到数据锁存的完整窗口

很多人在用寄存器框架的时候，脑子里对"写一个寄存器"这件事的想像是原子的、瞬间完成的。实际不是。一次写操作在物理层面至少分成四步：主控把地址放到地址线上并保持稳定、拉低片选、拉低写选通、把数据放到数据线上，然后在写选通的上升沿，FPGA 侧把数据锁进目标寄存器。这四步里任何一步的时序不满足建立时间或保持时间，写进去的就是垃圾。

在端口模拟总线的实现里，这套动作对应的是几行端口寄存器赋值。主控先写一个端口输出地址和数据的组合，再写另一个端口翻转选通信号，最后再翻回来。整个过程在 16MHz 下大约占用几个到十几个时钟周期，实测下来单次写操作的开销在 0.3 微秒到 0.6 微秒之间。这个数字听起来很小，但你要跟"直接操作端口寄存器翻转一个 IO"对比——后者只要一个周期，62.5 纳秒。也就是说，走寄存器框架比裸翻 IO 慢了五到十倍。

那为什么还要走框架？因为框架的一次写，换回来的是硬件侧成百上千个周期的并行工作。你写一次"启动"，FPGA 里那个模块可能连续产生几万个精确脉冲，主控这边一个周期都没花。这笔账才是协处理的意义所在。单看单次写的开销，框架永远是亏的；看"完成一件完整任务的总开销"，框架才有价值。这个视角转换非常重要，很多人评估方案的时候只算单次调用耗时，得出"框架太慢不如裸写"的结论，方向就错了。

时序上还有一条容易被忽略：读操作的窗口比写更长。因为读要等 FPGA 侧把数据驱动到数据线上，主控才能采样，中间存在一个往返延迟。如果你的框架里读操作没有插入必要的等待，读回来的可能是上一次的残值。稳妥的做法是读之前先建立一个周期的地址保持，读选通拉低后至少等一到两个周期再采样数据线。这点余量在 16MHz 下就是一百多纳秒，几乎不影响性能，但能消除一大批莫名其妙的读数错误。

3.2 状态位轮询：为什么不能"写完就跑"

"写完就跑"是新手最常犯的错误，表现形式是：代码里写了一个启动位，紧接着就去读结果寄存器，读到的全是 0，然后怀疑硬件没工作。实际情况是硬件才刚刚开始干活。

正确的做法是轮询状态寄存器的忙闲位。这里有个设计取舍：到底该由硬件产生"完成"信号，还是由软件靠固定的延时等待？我的答案是前者，没有任何商量余地。固定延时的问题在于它必须按最坏情况取值，实际大部分时候硬件早就干完了，主控还在空转；更糟的是如果硬件因为参数不同耗时变长，固定延时就不够，程序跑着跑着就间歇性失败，而且在实验室里很难复现——因为你的测试参数恰好落在快的那一档。

状态位轮询的代码写起来很简单，但有两个细节值得说。第一，轮询循环里不要加打印。串口输出一次几十微秒，会把轮询周期拉长几十倍，你测出来的"任务耗时"全是假的。真要观察，就设一个计数器，循环结束后一次性打出来。第二，轮询要加超时。硬件可能因为参数非法卡死不置完成位，没有超时的轮询就是死循环，整个系统假死。超时值怎么定？我的经验是按"正常耗时的三到五倍"设，同时超时后要能读到一个明确的错误标志，方便定位是参数问题还是硬件问题。

还有一类更隐蔽的情况：状态位是脉冲式的，硬件只置起一个时钟周期就自动清掉。主控轮询的间隔如果大于这个脉冲宽度，就会永远看不到。所以状态位必须做成锁存式——置起后一直保持，直到主控显式清除（用 W1C 最合适）。这条规则我写进了自己的检查清单，每做一个新外设都要过一遍。

3.3 跨时钟域同步与亚稳态的处理

主控跑 16MHz，FPGA 内部模块很可能跑在更高的频率上，或者反过来跑在更低的分频时钟上。这两个时钟域之间的任何单 bit 信号传递，都存在亚稳态风险——信号在目的时钟域的采样窗口内发生跳变，触发器可能输出一个既非 0 也非 1 的中间电平，持续一段不确定的时间后才随机落定。

这个问题的严重性在于它是概率性的。你跑一万次都没事，第十万零一次就错一位，而且这种错误在日志上表现为"偶发数据异常"，几乎不可能靠打印定位。处理办法是标准的：慢到快用两级触发器同步，快到慢用脉冲展宽或握手。

具体的操作细节：控制信号（启动、复位、使能这种单 bit 的）从主控域进 FPGA 高速域，走两级同步器，中间不要插任何组合逻辑。数据总线和地址总线是多 bit 的，绝对不能对每一位单独做同步——那样会出现"有的位先到、有的位后到"的错位采样，读到的地址可能是一个从未存在过的组合，直接把数据写进错误的寄存器。多 bit 的正确做法是：数据在稳定期间保持不动，用一个单 bit 的选通信号做跨域同步，目的域用同步后的选通去锁存整组数据。这也是为什么寄存器总线的时序里，"保持稳定"这条要求是硬性的——它不只是为了满足建立保持时间，也是为了跨域采样的正确性。

4. API 层的封装取舍：为什么要有影子寄存器

4.1 读-改-写与位域安全

如果框架只提供"整字节读"和"整字节写"两个函数，那上层每改一个位都要走一遍读-改-写。这在单线程的 sketch 里勉强能忍，但只要出现中断，就有窗口期问题：主程序读完寄存器、还没写回去，中断进来改了同一个字节的另一位，主程序写回时把中断的修改覆盖掉了。

解决办法有两层。软件层加影子寄存器：驱动里维护一份和硬件寄存器一一对应的内存副本，所有位操作都先改副本，再由一个统一的提交函数写回硬件。这样读-改-写的窗口被压缩到只有提交那一瞬间，冲突面小得多。更关键的是，影子寄存器让"设置某一位"这个动作变成了纯粹的内存操作，速度快、无副作用，上层可以放心地多次调用。

接口层提供原子位操作：setBits(reg, mask)、clearBits(reg, mask)、writeBits(reg, mask, value)这三个函数覆盖了绝大部分位域需求。它们的实现方式我倾向于都走影子寄存器加提交，而不是每次直接读硬件。原因很实在——读硬件比读内存慢一个数量级，而位操作在时序敏感的场景里调用很频繁，能省则省。

有一个坑必须提：影子寄存器和硬件侧自更新的寄存器不能共用。状态寄存器由硬件驱动，它的值随时在变，如果你也给它维护一份影子副本，读出来的就是过期数据。所以我的划分原则很明确——控制、配置、数据这类"主控写、硬件读"的寄存器用影子；状态、结果这类"硬件写、主控读"的寄存器永远直读，不缓存。

4.2 批量写与突发传输的接口形态

单个寄存器写完了，紧接着常要做的是"把一组参数一口气写下去"。典型场景：给波形发生器下发频率、占空比、相位、幅度四个参数，四个参数必须同时生效，否则中间会出现一个参数已更新、另一个还是旧值的非法状态，硬件行为不可预测。

这时候接口层要给writeBlock(startAddr, buf, len)这样的批量函数。硬件侧配套的做法是：参数先写进一组暂存寄存器，不生效；最后写一个"应用"位，所有参数在同一时刻一起搬运到工作寄存器。这个"应用位"本质上是一个软触发的同步锚点，它保证了参数组的原子性。

批量写还有性能考量。每次写都要走一遍完整的地址建立、选通、撤销流程，如果四个参数分开写，开销乘以四。批量写如果硬件侧支持自增地址，就可以省掉重复的地址建立步骤，实测能快三成左右。不过自增地址会增加硬件译码的复杂度，小项目里可以不上，等真出现性能瓶颈再加。

4.3 volatile 与编译器重排：C 层面的隐形陷阱

这一条是我认为最容易翻车、也最容易被文档忽略的。寄存器地址在 C 语言里通常被定义成一个指针，如果你忘了加volatile，编译器完全有权利把"连续写同一个地址两次"优化成"只写一次"，或者把写操作挪到别的语句后面。代码逻辑上没错，实际行为完全错了。

// 错误写法：编译器可能合并或重排这两次写 #define REG_CTRL (*(uint8_t *)0x40) REG_CTRL = 0x01; REG_CTRL = 0x00; // 正确写法：volatile 保证每次访问都真实发生 #define REG_CTRL (*(volatile uint8_t *)0x40) REG_CTRL = 0x01; REG_CTRL = 0x00;

加了volatile还不够。volatile只保证"这次访问不能省、不能合并"，但不保证不同 volatile 访问之间的顺序。如果你的流程是"先写参数数据寄存器，再写启动控制寄存器"，编译器理论上可以把这两次写调换位置，硬件看到的就是"先启动，后给参数"，结果用了上一轮的旧参数跑了一次。这种错误的恶心之处在于它依赖编译器的具体优化行为，换个编译器版本、改个优化等级，行为就变了，你会以为是自己代码写错了，查半天查不出来。

彻底的解决办法是在关键的顺序点上插编译屏障：

// 写参数 REG_DATA = param; // 编译屏障：告诉编译器此处不许跨越重排 __asm__ __volatile__("" ::: "memory"); // 再写启动位 REG_CTRL |= 0x01;

__asm__ __volatile__("" ::: "memory")这行的意思是"这里有一个看不见的内存操作，别把内存访问挪过它"。它在生成的目标代码里不产生任何指令，纯粹是给编译器的约束。我在框架的提交函数里固定放一条，从此再没遇到过顺序错乱的问题。

5. 从零做一个自定义协处理外设：地址表到综合脚本

5.1 需求定义与寄存器草案

假设现在要做一个"四路独立 PWM 加编码器计数"的协处理外设，需求是这样的：四路 PWM，频率和占空比可独立配置，主控能随时改；两路正交编码器，硬件自动计数，主控按需读取。手动在软件里实现这套东西，主控基本就干不了别的事了，正好适合甩给 FPGA。

先把寄存器草案列出来。这一步不要写代码，就在纸上写，写完自己念一遍，看每个字段的语义是否清晰、是否有重叠。

这张表定下来之后，后面所有工作都是围绕它展开的。有一个细节值得单独讲：16 位计数值拆成两个 8 位寄存器读，存在"读低字节和高字节之间计数器刚好进位"的撕裂问题。解决方式有两种，一种是硬件侧在读低字节时把高字节锁存住，另一种是软件侧连读两次取一致值。前者更干净，我一般选前者，代价是硬件侧多两个触发器。

5.2 硬件侧译码与功能实现

硬件侧的核心是一段地址译码：把地址总线上的值和地址表逐项比对，命中谁就把写选通或读选通分发给谁。这段逻辑写起来枯燥但不能错，尤其是别漏掉"默认分支"——所有没命中的地址，读的时候要返回一个固定值（比如 0），不能悬空，否则主控读到的是数据线上的随机电平。

功能实现部分，PWM 用的是计数器加比较器的经典结构：一个自由运行的 N 位计数器，跟占空比寄存器比大小，小了输出高、大了输出低。分频系数用来控制计数器的步进节奏。编码器部分是正交解码状态机，根据 A、B 两相的跳变顺序判断方向，加减计数。

这里有个坑得说清楚：参数寄存器和工作寄存器要分开。主控写进去的是参数寄存器，硬件实际比较的是工作寄存器。两者之间那个"应用"动作，才是参数生效的时刻。如果偷懒直接拿参数寄存器做比较，主控写到一半的时候——比如占空比刚写了新值、分频系数还是旧值——硬件会用一组不匹配的参数跑几个周期，输出波形上出现一个毛刺。这种毛刺在示波器上一闪而过，很难抓到，但在某些负载上会引发误动作。

5.3 软件侧驱动封装与自测流程

驱动层的结构我一般这么组织：一个描述寄存器表的结构体常量、一组底层读写函数、一层语义化的 API。

typedef struct { uint8_t addr; uint8_t access; // RO / RW / W1C / RC uint8_t resetVal; } reg_desc_t; static const reg_desc_t regMap[] = { {0x00, ACCESS_RW, 0x00}, {0x01, ACCESS_RO_W1C, 0x00}, {0x10, ACCESS_RW, 0x00}, // ... }; void pwmSetDuty(uint8_t ch, uint8_t duty) { if (ch > 3) return; writeShadow(0x10 + ch, duty); // 先改影子 } void pwmApply(void) { commitShadow(); // 统一提交，参数原子生效 }

自测流程要有明确的分层。第一层是"寄存器自检"：上电后往每个 RW 寄存器写 0x55 再写 0xAA 读回来，确认总线通路正常、地址译码没错位。这一步能把 90% 的接线和译码问题挡在门外。第二层是"功能单测"：单独测一路 PWM，占空比从 0 扫到 255，用逻辑分析仪抓波形看占空比是否线性。第三层才是"联动测试"：四路同时跑，同时读编码器，看有没有互相干扰。

第一层的自检我强烈建议做成可复用的函数，每次改动硬件综合之后都跑一遍。改动 FPGA 逻辑最容易引入的就是地址译码的回归问题，而这类问题如果不自检，表现出来往往是"某个功能偶尔不对"，排查成本极高。

6. 调试现场：那些只有上电才暴露的问题

6.1 首次写不生效：复位与初始化顺序

有一类问题我遇到过不止一次：代码完全正确，单步调试也正常，但整机上电后第一次写寄存器就是不生效，第二次开始就好了。原因几乎都是初始化顺序——主控启动比 FPGA 配置完成快，主控已经在写寄存器了，FPGA 那边还在加载配置，总线上的信号根本没被接收。

解决办法是在初始化流程里加一个"握手确认"：主控先读一个固定的识别寄存器，硬件侧把这个寄存器做成一个常量（比如固定的版本号），读到正确值才认为 FPGA 就绪，读不到就重试。这比固定延时靠谱得多，因为不同批次的器件配置时间有差异，固定延时要么浪费要么不够。

还有一个小细节：上电时所有寄存器必须有明确的复位值。硬件侧不加复位逻辑，寄存器上电就是随机态，主控读到的第一个状态值可能是"忙"，于是流程卡在等待里。所有寄存器统一复位为 0，是最省事也最不容易出错的约定。

6.2 偶发错位：总线竞争与多主访问

如果系统里除了主控之外还有别的模块能访问同一组寄存器（比如调试接口、或者第二个主控），就会出现总线竞争。两个主同时驱动数据线，轻则读到错值，重则长期对冲损伤端口。框架层面必须有一个仲裁机制，最简单有效的是"同一时刻只允许一个访问源，用互斥标志加超时"。

在单主控系统里，竞争往往来自另一个方向：主程序与中断服务程序同时访问。前面说的影子寄存器能缓解，但不能根除。彻底的做法是在提交函数里关中断——提交动作只有几条指令，关中断的时间窗口极短，对系统实时性的影响可以忽略。我一开始担心关中断会影响串口接收，实测下来提交函数占用不到 1 微秒，16MHz 下串口一个字节要 80 多微秒，完全来得及。

6.3 计数对不上：状态位清除时机

编码器计数读出来总是差一点点，或者溢出标志清不掉，这类问题的根源通常在清除时机上。常见错误是"在轮询循环里顺手清标志"，结果清完之后硬件又置了一次，循环退出时标志还在，下一次进来又立刻命中，形成虚假的连续事件。

我的做法是把清除动作放在"处理完数据之后"，而不是"检测到标志之后"。流程是：检测到标志 → 读走数据 → 处理数据 → 清除标志。这样即使硬件在处理期间又置了一次标志，也会被保留到下一轮，不会丢事件。反过来，如果先清后处理，处理期间的新事件就丢了。

还有一条经验：W1C 寄存器不要用影子机制。前面说过状态寄存器不缓存，这里再强调一次——对 W1C 寄存器做读-改-写是最危险的组合，因为读回来的值和写下去的值语义完全不同，硬件看到的可能是"把当前所有置起的标志全部清掉"。

7. 性能账本与适用边界：什么时候该上协处理

7.1 实测数据对比表

我把同一个四路 PWM 加两路编码器的任务，在三种实现下各测了一遍。测试条件是 16MHz 主控、逻辑分析仪抓波形、每种跑一万次取平均。

这张表最能说明问题的不是第一列，而是第三列和第四列。参数更新耗时只差几倍，但 CPU 占用从 85% 掉到 4%，这是量级上的差别——省下来的算力可以做通信、做上层逻辑、做数据记录。编码器可测频率提高了一个数量级，这是软件方案再怎么优化也追不上的，因为它的瓶颈在采样率的物理上限，不在代码效率。

但我也得把话说全：寄存器框架的单次访问开销确实比裸翻端口高。上面那个 0.5 微秒里，相当一部分是框架的函数调用和影子寄存器同步的开销。如果你的任务真的只是"翻转一个引脚"，那就别上框架，直接操作端口寄存器，一个周期完事。用框架的前提是"你换回来的是硬件并行执行"，换不回来就是纯亏。

7.2 不该用 FPGA 协处理的三种场景

第一种，任务本身没有并行性、也没有严格时序要求。比如读一个温度传感器，一秒钟读一次，软件实现几十行代码就够了。为这种任务写一套 Verilog、配一套寄存器、维护一份地址表，投入产出比极差。

第二种，逻辑还在快速迭代、需求天天变。FPGA 里的硬件逻辑改一次要重新综合、重新下装，迭代周期比改 C 代码长一个数量级。在产品形态还没定型的时候上协处理，等于把自己锁死在一个改不动的架构上。我自己的做法是：先用软件把逻辑跑通、把接口形状摸清楚，等需求稳定了再把最耗时的那个模块搬到硬件里。

第三种，数据量大但不需要实时处理。比如采一批数据、存起来、事后分析，这种完全可以软件慢慢搬。协处理的价值在"实时"两个字上，不在"数据量"上。判断标准很简单：这个任务如果晚了几微秒会怎样？会出错、会丢数据、会失步，那就值得上硬件；晚几毫秒也没事，那就老老实实写软件。

最后分享一个我在多个项目里验证过的小技巧：新外设上硬件之前，先用软件实现一版行为完全相同的模拟版本。模拟版本用普通的内存变量代替寄存器，接口签名和真硬件驱动完全一致。上层应用先对着模拟版本开发和调试，等上层逻辑稳定了，再把底层换成真的寄存器读写。这样能把"上层逻辑错误"和"硬件时序问题"彻底分开，调试效率提升非常明显——我甚至遇到过上层调完后换真硬件一次通过的情况，因为所有逻辑 bug 在模拟阶段就已经暴露干净了。