嵌入式MCU实时性优化：从中断瘦身到内存池的完整实践

1. 项目概述与性能优化的正确打开方式

嵌入式系统的性能优化，说到底是在资源受限的前提下，把系统的实时性、吞吐量和稳定性压榨到极致。我接手过不少所谓"跑起来没问题，一上量就翻车"的项目，问题往往不是功能缺陷，而是性能余量根本不够——CPU占用率常年90%、中断响应抖动超过设计指标、内存碎片化导致运行几天后随机死机。这次要分享的优化策略，就是针对这类问题的完整打法。

这个项目围绕一套以MCU为核心的实时采集与控制设备展开，主控芯片是Cortex-M7内核，主频400MHz，外扩了SDRAM和Nor Flash，跑的是轻量级RTOS，对外提供Modbus RTU、CANopen以及以太网三种通信接口，同时挂着两路ADC以20kHz的采样率连续采集，数据经过滤波、特征提取后通过以太网周期性上传。整体功能逻辑并不复杂，但性能瓶颈非常典型：多任务并发访问外设、中断频繁抢占CPU、DMA和外设缓冲区竞争、动态内存分配引起的碎片化，几乎把嵌入式优化最常见的几个方向全踩了一遍。

先说结论：这次优化下来，CPU峰值负载从83%降到了41%，任务调度最大时延从2.7ms压到了0.4ms，启动时间从4.8s减到2.1s，系统连续运行72小时无异常。数据不算夸张，但每项都是实打实测出来的。适合谁参考呢？如果你正在做带实时操作系统的嵌入式项目，或者你的板子跑着跑着就出现"偶发性卡顿""重启后偶尔起不来""抓包发现通信超时"这类问题，这篇文章应该能帮你打开思路。

优化做得好不好，最关键的衡量标准不是"代码跑得变快了多少"，而是系统在最坏情况下是否仍然满足设计要求。所以我一开始就把整个优化流程分成了四个阶段：先测量、再定位、后优化、终验证。不测量瞎优化，跟蒙着眼睛开车没有区别。

2. 系统性能基线的构建与瓶颈定位

这一步是整个优化工程的地基。我见过太多人上来就改代码，改完发现瓶颈根本不在那里，时间全浪费了。正确的做法是：先把系统的当前状态量化，再用数据说服自己哪里真正需要动刀。

2.1 CPU占用率：别只信调试器的数字

第一个要建立的就是CPU负载基线。很多人用调试器里自带的CPU Usage统计功能，那个数值在低负载下还可以参考，一旦中断频繁、DMA活跃，调试器统计出来的数字往往会比实际低不少——因为它依赖调试接口的采样频率，采样率跟不上，高频率的短任务很容易被漏掉。

我在这个项目里用的是"空闲任务计数法"：在RTOS的空闲任务里维护一个32位计数器，利用定时器中断每秒读取一次计数值，再用一个参考值（系统完全空闲时一秒内的计数增量）换算成CPU占用率。这个方法的精度取决于空闲任务的优先级和定时器触发的确定性，实测下来误差可以控制在1%以内。基准换算公式很简单：

CPU利用率 = (参考计数 - 实时计数) / 参考计数 × 100%

参考计数的获取方式：系统刚启动、所有业务任务都未创建时，让系统空转一秒，记录下空闲任务计数增量即为100%空闲的参考值。

测出来的结果让我心里有数了：系统平均CPU负载56%，但峰值高达83%，而且波形显示负载呈周期性脉冲——这是ADC采样、协议解析、以太网发送几个任务"撞车"造成的。优化空间很大，但首先得知道是谁在吃CPU。

2.2 中断延迟测量：直接决定实时性上限

第二个关键基线是中断延迟。中断延迟 = 从硬件中断触发到中断服务函数第一行代码执行的耗时，它直接决定了系统的实时性上限。这个参数用示波器测量最准：把某个GPIO在中断服务函数入口翻转，同时给硬件信号源接另一个通道，测两个波形沿之间的时间差。

实测发现，系统在正常运行时的中断延迟在3μs左右，但有一次优化期间测量竟然飙到了41μs。追踪排查后，问题出在一个占用高优先级中断的服务函数里——里面有将近200行代码，包含浮点滤波运算和向另一个任务发信号量的操作。这直接导致后续所有低优先级中断被阻塞。这是个非常典型的错误，后面我会专门讲怎么拆解。

2.3 内存使用与栈深度检测：隐藏的"定时炸弹"

第三个基线是内存。这个项目使用了RTOS的动态内存分配功能（堆内存方式），运行时任务栈、消息队列、互斥锁等内核对象都要从堆里申请。问题在于，外扩SDRAM虽然空间够大，但动态分配在长时间运行下必然产生碎片，这是任何嵌入式工程师都要面对的现实。

我重新梳理了整块内存的分配格局：

栈深度检测用了一个老办法——栈填充魔法数字。在任务创建时把栈区填满0xA5，运行一段时间后在调试器里数一下还剩多少0xA5，就能算出任务实际用了多深的栈。这个数据非常重要，因为栈溢出是嵌入式系统最隐蔽的死机原因——它不一定会立即崩溃，而是随机覆盖相邻内存，运行几天后才爆发。

2.4 编译器优化与代码级调优：从源头减少浪费

基线数据建好之后，我开始逐项排查代码层面的瓶颈。第一个发现是：调试版工程默认的优化级别几乎等于没优化，很多关键运算路径上存在无谓的重复计算和冗余拷贝。

这个项目用的是GCC编译工具链，我把优化级别从-Og调到了-O2，并对比了编译时间和运行性能。-O2在大多数MCU项目里是最推荐的平衡点：既不会像-O3那样激进导致代码尺寸膨胀、潜在引入未定义行为，又比-Os（偏体积优化）保留了更多速度优化。实测CPU峰值负载直接下降了大约12个百分点。

但光靠编译器选项还不够，代码层面有几个"隐形杀手"必须手动处理：

第一是浮点运算滥用。Cortex-M7虽然有硬件FPU，但浮点运算比定点运算还是慢不少，尤其在除法、开方、三角函数这类运算上。ADC数据处理里的滤波算法原来直接用了浮点算，我把滤波系数定点化之后，同样的滤波效果，耗时从80μs降到了23μs。做法就是把浮点小数放大成整数（乘上2的幂次），计算完再缩小，关键在于选好缩放因子，保证精度不丢。

第二是查表代替实时计算。协议解析里用到的CRC校验和是位运算，这个还好；但通信里面有些字段转换做了乘法、除法和取余，那种路径几百毫秒才执行一次也就罢了，却放在每秒执行上千次的循环里，属于典型的"顺手把运算写在热路径上"。我把这类固定映射关系整理成查找表，空间换时间，平均每次调用从几十个周期降到了两三个周期。

第三是循环展开和循环内不变代码外提。GCC的-O2会自动做一部分，但手工展开小循环依然能显著减少循环控制开销。在数据搬运和解析的循环里，手动展开3到4次后，总耗时又降了一截。这一步不复杂，但需要对照编译器生成的汇编确认。

2.5 链接脚本与内存布局优化：让取指不再"堵车"

基线测量时我发现系统启动后从Flash取指比较慢。原因很典型：MCU内核取指和DMA外设搬运数据都在抢内部总线，虽然没有到死锁的程度，但总线仲裁导致的等待周期直接影响执行效率。

这里的解法是：把性能敏感的中断服务函数、RTOS调度相关代码、高频调用的通信协议函数放到紧耦合内存（TCM，Tightly-Coupled Memory）里。Cortex-M7的TCM是直接挂在内核总线上的，访问它不需要经过总线矩阵仲裁，取指和数据访问延迟显著低于从Flash或SDRAM取指。做法就是在链接脚本里增加一个tcm_code段，手动指定哪些函数放入——我用的是GCC的__attribute__((section(".tcm_code")))语法，把中断入口、调度器和核心滤波算法放进去之后，中断响应和主循环周期都有可感知的改善。

另外一个容易被忽略的问题是SDRAM的初始化时序。很多开发板例程里SDRAM初始化参数是照抄的，跟实际使用的SDRAM芯片不完全匹配。我对照着手册把所有时序参数重新计算了一遍——刷新周期、行激活时间、预充电时间这些——初始化完成后用内存读写测试工具全地址跑了几轮，确认无误后发现SDRAM的读写效率也有细微提升，这是白捡的便宜。

2.6 工具链补强：让测量更精确

为了把整个优化过程建立在数据上，我引入了两个轻量级工具：一个硬件调试探针的事件追踪功能，配合IDE可以导出任务切换和中断触发的时间戳序列；另一个是在代码里打时间戳的轻量级插桩库，避免在正式优化过程中反复手动加打印调试。

事件追踪导出的序列图帮我发现了一个之前"用示波器都难抓住"的问题：两个任务在抢同一个串口外设时，因为互斥量的优先级继承机制配置不当，导致低优先级任务占着串口不放，中等优先级任务持续抢占CPU，高优先级任务反而被"饿死"。这类问题纯靠看代码很难一眼看出来，但事件序列上非常明显。后面3.3节我会把优先级反转作为专门案例展开。

3. 核心优化实施：从系统到代码

基线建完了，瓶颈也定位清楚了。接下来进入真正的优化实施阶段。我按照"先系统、再关键路径、最后代码细节"的顺序来推进，每一步都保持"改一项、测一项、回归一项"的节奏，避免优化之间互相干扰，也方便在出问题时回溯。

3.1 中断服务程序瘦身：从机制上消除长阻塞

前面提到过一个中断服务里直接做复杂运算和任务通信的案例。这类设计在实时系统里是"大忌"。中断服务函数应该遵循一个基本原则：能不在中断里做的事，绝不在中断里做。

原则背后的原因有两个层面。第一，中断服务函数会抢占所有普通任务和低优先级中断，函数写得越长，系统"最坏情况中断延迟"就越高，实时性就越差。第二，中断上下文里调用RTOS API（比如信号量、消息队列发送）是有约束的，不是所有API都能在中断里安全调用，强行调用不仅增加不确定性，还可能引入优先级反转以外的怪问题。

我的拆解策略是：中断服务函数里只做三件事——

1. 读取硬件状态寄存器，把数据从外设FIFO搬到内存缓冲区；
2. 清除中断标志位；
3. 给对应任务发送一个"数据就绪"的信号量或事件标志组，然后立即退出。

所有数据处理、协议解析、运算逻辑全部搬到普通任务上下文里执行。这样中断从200行瘦身到20行以内，实测中断延迟从41μs降到了3.2μs，效果立竿见影。还有一点值得提醒：信号量的创建和获取一定要放在任务上下文而不是中断里操作，这是RTOS使用的红线规则之一。

3.2 任务优先级与调度策略调整：精细化调度

基线数据显示的CPU负载脉冲，跟任务调度策略直接相关。原本的优先级配置是"每个任务一个优先级，按功能优先级从高到低排"，粗看起来合理，实际运行起来互相干扰严重。三个高频任务和三个低频任务挤在一起，调度器频繁切换，缓存命中率下降，任务切换开销拉高了CPU负载。

我做了两个关键调整：

第一是"按周期分组"。把1ms周期任务单独设一个高优先级组，10ms、100ms、1000ms任务分别放到低一些的优先层级。这样高优先级组内任务之间、中低优先级组内任务之间不会互相打断，减少了无谓的上下文切换。需要说明的是，这里的分组不是简单的"把周期一样的设成同一个优先级"，而是要让同一组内任务的执行时间之和小于该组的调度周期，否则高优先级组会独占CPU。

第二是"关键路径让路"。通信协议栈的接收解析任务和ADC数据处理任务都涉及实时性要求，我把它们放在最高优先级，但强制在它们内部增加"主动让出CPU"的机制——每处理完一帧或一个数据块，主动调用一次延时或任务切换。这样既保证了关键数据的实时性，又避免高优先级任务长期霸占CPU导致其他任务饿死。

调整之后的调度效果：任务切换次数从每秒1500次降到了600次，CPU峰值负载自然就下来了。这步操作的启发是：任务优先级不是越分开越好，关键是让一起跑的尽量不互相打扰，让偶尔跑的不拖累关键路径。

3.3 优先级反转问题：一个差点让系统"假死"的坑

这个问题我要单独拎出来讲，因为它极其隐蔽，而且后果严重。

当时系统出现了一个"偶发性假死"：运行半小时或几小时后，以太网通信突然断掉，但看门狗没有复位设备，LED指示灯也正常闪烁。用事件追踪功能一查，发现一个中等优先级任务（LCD刷新）在长时间占用CPU，而一个高优先级任务（以太网接收解析）明明就绪了却一直拿不到执行权。深入追踪后确认是优先级反转：低优先级任务持有某个互斥量，高优先级任务在等这个互斥量，中等优先级任务又不需要这个互斥量、一直抢占CPU，导致低优先级任务没法释放互斥量，高优先级任务被无限期阻塞。

解法是第一时间打开RTOS的互斥量优先级继承特性（Priority Inheritance）。这个机制的原理是：当高优先级任务被低优先级任务持有的互斥量阻塞时，内核临时把低优先级任务提升到高优先级的级别，让它尽快运行并释放互斥量，然后再恢复原优先级。打开这个开关后，同一个场景下，系统响应恢复正常。

除此之外，我还调整了访问共享外设的方式：把原先"每个任务都直接操作串口"改成"所有串口访问统一经过一个串口管理任务"，用消息队列串行化访问。互斥量的使用频次下降了90%，因为只有这一个任务在使用外设，没有竞争就没有反转。这个思路背后的通用原则是：能用"专用访问者"解决的问题，不要用锁去解决。锁最终还是要封装的，不如直接让访问者唯一化。

3.4 DMA与外设数据通路优化：减少CPU搬运

在优化前，ADC采样数据是每个数据点都触发一次中断，CPU在中断里手动读取采样值。20kHz的采样率意味着每秒2万次中断，每次中断哪怕只要10μs，CPU也要为此付出20%的负载。优化效果最明显的一个动作就是把ADC采样从"中断逐点搬运"改成"DMA批量搬运"。

具体做法是：ADC采样结果直接由DMA写入内存缓冲区，半满和全满各触发一次中断，CPU在中断里只做缓冲区指针切换和信号量通知，剩下的滤波和特征提取在任务里做。中断频率从20kHz降到了大约200Hz，光这一项CPU负载就降了18个百分点。

DMA配置里有几个细节特别值得注意：

1. 缓冲区对齐。DMA对内存地址对齐有要求，如果缓冲区首地址不对齐，可能触发总线错误或性能下降。我在内存池里专门划分DMA专用区，保证2KB对齐。
2. 缓存一致性。MCU内部有缓存，DMA写入内存的数据如果不做缓存一致性处理，CPU读取时可能读到旧数据。Cortex-M7的缓存一致性处理，要么关闭缓冲区对应地址范围的缓存，要么在访问前执行Clean和Invalidate操作。我采用的是"缓冲区首尾各留一段安全区，在缓冲区切换点统一处理缓存失效"的做法，实测可靠，没有数据错乱。
3. 环形缓冲区。DMA批量搬运天然适合配合环形缓冲区使用，我在内存池里为每个DMA通道分配了4KB的环形缓冲区，读写指针分离，半满和全满中断正好对应环形缓冲区的一圈。这样整个数据链路从"逐点搬运"变成了"批量处理"，CPU负载和代码复杂度同时降下来。

以太网收发也做了类似的DMA优化，发送时直接把待发送的数据包挂到DMA描述符上，CPU不再参与数据拷贝。这里有个坑在于一般协议栈内部已经把DMA封装好了，但因为站在系统层面看，真正要优化的是"不要让CPU把数据从协议栈缓冲区再拷到应用缓冲区"，能引用就引用，能传递指针就传递指针，实在要拷贝也放在低频路径上。

3.5 内存池与对象复用：根除动态分配碎片

动态内存分配的碎片化问题在内存充裕时不会立即显现，但运行时间越长越致命。我针对这个项目做了三类优化：

第一类：任务栈和内核对象全局静态化。每个任务的栈空间、消息队列的存储区、互斥锁等内核对象，全部从动态堆分配改为静态数组分配。静态分配在编译阶段就确定了地址，不产生堆碎片，也不存在分配失败的运行时风险。栈大小在最深路径的实测基础上各加20%冗余，这是工程上比较稳妥的做法。

第二类：大块数据缓冲改用内存池。协议栈接收和发送缓冲区、ADC数据缓冲、以太网收发描述符，这些频率高、大小固定的缓冲需求，我用一个通用的固定块内存池管理。内存池预先在启动阶段划分好一组大小相等的块，分配和释放都是O(1)复杂度，而且永不产生跨块碎片。

第三类：减少堆接口调用。其实嵌入式RTOS的堆实现都有不同程度的碎片风险，我处理完前两类之后，运行时动态分配调用次数从每秒十几次降到了接近零，剩下极个别场景（比如启动阶段注册网络接口）用动态分配，运行稳定后不再触碰堆。实测系统连续运行72小时，内存使用曲线非常平稳。

4. 各优化手段的优先级与收益评估

优化做到这一步，踩的坑也不少，各手段的收益差异是肉眼可见的。我把这次实施的所有优化手段按性价比排了个序，方便大家在实际项目中做取舍：

优先级排序的核心逻辑是：先解决会导致系统崩溃、错乱、超时的问题，再优化负载和效率。反过来做，表面上看CPU降了很多，但系统可能依然偶发假死，治标不治本。

另外，优化手段之间不是独立叠加的。比如中断瘦身做完之后，CPU负载下降了，这时候再看DMA优化，收益可能没有单独做时那么亮眼，但它们都在为"最坏情况"做保障——中断延迟低了，即使偶尔负载高的场景，实时性也能满足。所以衡量收益不能只看平均负载，还要看最坏情况下的表现。

5. 典型问题排查与排错实录

优化过程不是一蹴而就的，我在这个项目里也遇到了几个非常典型的问题，单独列出来分享，这些问题都是常规文档不会写、但实际总会碰到的。

5.1 问题一：任务栈溢出导致的间歇性死机

现象：系统运行约2小时后随机死机，看门狗能复位但不稳定，复位间隔从几分钟到几十分钟不等。

排查思路：一开始我怀疑是堆碎片，因为死机时间点毫无规律。用栈填充法排查之后，发现是ADC处理任务的栈深度超出预设值——优化过程中我把ADC任务里的一部分逻辑改成用较大的局部数组，栈需求直接涨了800字节，结果时不时踩过界，覆盖了相邻内存里的某个任务控制块，系统随之崩溃。

解决与反思：这个问题的教训是"任何优化都不应该只关注是否跑得过，还要关注是否站得住"。改完代码后，重新做栈深度基线测量，用栈填充法把每个任务的实际最大深度记录下来，再加30%余量重新分配栈。从那以后，我把"栈深度测量"列为了每次改动后的必做回归项。

5.2 问题二：DMA缓存一致性问题导致的数据错乱

现象：以太网接收数据偶发错乱，抓包发现某些数据包中间有几个字节是旧的。

排查思路：一开始怀疑链路问题，换了几种网线、交换机端口，问题依旧。后来才意识到是缓存一致性问题——DMA把新数据写入了内存，但CPU从缓存里读到了旧数据。Cortex-M7的缓存是物理寻址、写回策略的，DMA搬入内存的路径跟CPU读缓存的路径不是一条路，这个必须主动处理。

解决：在DMA缓冲区的处理路径上增加缓存无效化（Invalidate）操作，确保CPU读取前缓存已经失效。另外我把以太网接收缓冲区的设计改成了双缓冲交替使用，每个缓冲区处理完毕后再切换，保证DMA写入期间CPU不会去读同一个缓冲区。

5.3 问题三：高优先级任务饿死导致的心跳超时

现象：通信心跳报文偶尔超时，重启后恢复，但无法稳定复现。

排查思路：这个跟3.3节的优先级反转类似，但场景不同。这次是高优先级任务（协议解析）内部调用了阻塞延时等待某条件成立，但因为系统繁忙，条件成立的信息被优先级更低的任务延迟上报，高优先级任务的实时性反而被拖垮。跟踪事件序列发现，协议解析任务"就绪"后长时间无法进入运行态，因为另一个同优先级任务（ADC采集）一直不释放CPU。

解决：调整调度策略，把协议解析和ADC采集两个任务通过事件标志组协同，而不是两个都抢占。事件标志组让两个任务可以"按事件触发、按顺序执行"，高优先级任务只在需要的事件发生时运行，其余时间主动让出CPU。系统事件序列从此平稳。

5.4 问题四：启动时间过长

现象：上电到系统完全就绪耗时4.8s，偶发超过5s。

排查思路：大部分时间消耗在Flash等待和以太网PHY自协商上。Flash等待太久，查了一下是初始化代码里的Flash访问延迟配置太保守；以太网PHY自协商是协议规定的，不能取消，但可以并行化——先初始化其他外设，再做PHY的软件复位和协商等待。

解决：重新配置Flash延迟，缩短了约0.6s；把外部器件初始化从串行改为并行，省了0.8s；启动阶段的关键数据初始化从动态装载改为直接映射，省了1.2s。总启动时间从4.8s降到2.1s。如果你的项目对启动时间有严格要求，可以优先检查启动阶段是否存在串行等待链——这是性价比最高的优化位置。

5.5 问题五：编译器优化级别调高后引入的"怪问题"

现象：调成-O2后，系统偶发出现一些"看起来完全不该发生"的异常，比如全局变量忽然变为初始值、条件判断并不是预期分支。

排查思路：一开始以为是缓存一致性问题，后来用编译器生成的汇编逐一对比，发现是代码里有两处未定义行为（UB）——一段是整数溢出后再比较符号，另一段是结构体成员对齐问题导致的非法访问。这些代码在-Og下碰巧表现正常，但优化级别提高后，编译器依据标准假设做出的优化路径变化了，问题就暴露了。

解决与反思：这个问题的教训很深刻：优化级别不是随意调的，调高之前必须保证代码没有未定义行为。排查手段是开编译器的-Wall -Wextra告警，把所有警告清零后再升优化级别。另外建议在正式发布前用最高告警级别完整编译一次，宁可早期多花时间修警告，也不要后期在目标板上"猜谜"。

6. 优化效果的验证与长期稳定性回归

优化做完了，最关键的环节是验证。嵌入式系统不是"跑通一次"就算完事，而是要在可预期的运行场景内持续稳定。我把验证分成三层：

第一层是功能回归：测试所有业务功能是否正常，通信协议是否兼容，数据采集精度是否满足规格书要求。优化过程中我用了两套板卡并行跑——一套保留优化前固件作为对照，另一套跑优化后固件，对照测试数据。

第二层是性能指标复测：把开头建的基线全部重新测量一遍，CPU峰值负载、中断延迟、调度最大时延、启动时间、内存水位、任务切换次数，每个都记录数据，跟优化前对比。优化后智能指针逻辑不展开，这里数据最重要：

第三层是长期稳定性压测：系统跑连续192小时，记录各种偶发场景（通信超时重传、外设拔插、异常电压波动），验证优化后的系统是否始终满足设计指标。这一层最耗时，但也最必要——性能优化常常在低负载下表现完美，一旦高负载持续运行就可能暴露不稳定。

回归验证阶段我还特意做了温度测试：把板卡放进温箱，从-20℃到70℃反复循环，同时跑通信和数据采集业务。这个测试有两点意义：一是确认DMA和内存访问在芯片不同温度点下仍然稳定，二是确认CPU负载降下来之后芯片发热量低了，温升对时序的影响也小了。很多线上偶发问题，其实是温度漂移下的时序裕量不足导致的，这一步能提前筛掉大半。

7. 实操过程中的关键经验与避坑心得

整个优化项目做完，我总结了一些通用的经验，这些经验不局限于某个具体芯片或某款RTOS，适用于绝大多数嵌入式性能优化场景。

第一，优化必须建立在测量数据上。我见过太多"感觉这里慢了，改一下"的做法，最后大概率是浪费时间。正确流程是：先建基线，把CPU负载、中断延迟、调度时延、内存水位、启动时间全部量化；然后基于数据定位瓶颈，按性价比排序优化；每改一步重新测量，保持"任何改动都要有数据支撑"。

第二，中断服务函数做减法永远是第一优先。中断延时直接决定了系统实时性的上限，这个上限如果在设计阶段就定死了，后面想靠优化别的挣回来是非常困难的。中断里只做必不可少的事，其余全部丢给任务处理，这条原则适用于所有RTOS。

第三，内存的碎片化和栈溢出是嵌入式系统最隐蔽的"定时炸弹"。动态分配在非必要的路径上不要用，栈深度要用数据说话，不要靠猜。哪怕是资源最紧张的单片机项目，多分配几十字节栈换来的稳定性，远远值回成本。

第四，编译器优化级别不是越高越好。从-O2到-O3提升的幅度有限，但引入未定义行为的风险显著增高。务必要保证代码没有UB、所有警告清零后再提高优化级别，不然你会在排错上花掉比省下来的性能多得多的精力。

第五，优化不是只调代码，还要调工具链、调内存布局、调调度策略。同样一段代码，放在Flash里执行和放在TCM里执行，性能差距可能接近一个数量级。链接脚本和内存规划应该是性能设计的一部分，而不是最后才想到的收尾工作。

第六，也是我个人体会最深的一点：性能优化要"系统性"推进，不能"东一榔头西一棒子"。先解决稳定性风险（中断延迟、栈溢出、内存碎片），再做效率提升（DMA、调度、代码级优化），最后做验证。顺序错了，前面做的优化可能都会被后面暴露的问题拖下水。

如果你正在做嵌入式项目，对照这份清单排查一遍，大概率能找到至少一两个值得优化的地方。先把测量工具架起来，数据会告诉你该往哪里走。