企业官网建设流程全解析

嵌入式实时C++编程，这几年在我接触过的项目里几乎成了逃不开的选题。经常有同事拿着两种观点来找我：一种认为单片机场景老老实实写C就好，C++的抽象和运行时开销是负重；另一种则觉得C++的RAII和模板能让固件代码更可控、更好复用。两种说法各有道理，但实际项目里真正决定成败的，往往不是“C还是C++”的口水战，而是你能不能把语言特性压进实时约束里，让每一行代码的响应时间、内存占用和资源释放路径都可预期、可复现、可测量。

这篇文章想把我在嵌入式实时开发里踩过的坑、总结出来的方法，以及一套可以直接拿来用的工程框架记录下来。不灌鸡汤，不贴理论，重点落在实时系统的确定性设计、C++特性在受限环境下的落地姿势、任务与中断的时序控制、内存池和静态分配的工程实践，以及调试和验证实时性的那套手段。如果你正准备用C++在某个RTOS或裸机环境上做实时控制、数据采集、设备通信类的项目，或者已经写了一半觉得调度乱、内存碎、抖动大，这篇应该能帮你少走不少弯路。

适用对象我大致分三类：一是有一定C基础，想往C++迁移的嵌入式工程师；二是在Linux或上位机写过C++，但第一次接触MCU和裸机环境，需要理解边界约束的人；三是已经在用C++做嵌入式，但实时性一直达不到要求，需要把时序、内存和优先级设计补起来的团队。不同背景的人读同一套方案，关注点会不太一样，我都会尽量写清楚原理和取舍。

1. 核心定位：实时嵌入式C++到底在解决什么问题

很多人把“嵌入式实时C++编程”理解成“用C++写单片机程序”，这么理解不能说全错，但容易忽略“实时”二字的分量。实时不是跑得快，而是每一个关键操作的完成时间都有上界。一个控制任务哪怕平均只花1毫秒，但偶尔出现一次10毫秒的毛刺导致设备剧烈抖动，这在实时系统里就是不可接受的。C++在嵌入式里的价值，恰恰是帮你用结构化的方式管理这种确定性，而不是制造更多不确定性。

1.1 硬实时与软实时的判断标准

项目开始时第一件事是判断系统的实时等级。硬实时系统是指错过截止时间会直接造成物理后果的，比如安全气囊的点爆控制、伺服电机的位置闭环、医疗输液泵的流速控制。软实时系统错过截止时间不会造成灾难，但会明显影响体验或降低性能，比如多通道数据记录仪偶尔漏一个采样点，音频处理缓冲区偶尔欠载一下，可能只表现为轻微杂音，并不致命。

这个判断听起来简单，实际经常被忽略。我见过好几个项目，明明只是做一个带日志上报的采集设备，却硬上了复杂的实时内核调度配置，收益有限，还把系统复杂度拉高不少。反过来，一个真正需要严格周期控制的项目，如果只在主循环里靠软件延时卡节奏，那抖动一定控制不住。所以请务必把一个项目的关键路径和截止时间约束单独立项，作为后续所有设计决策的总纲。

1.2 C++入局的技术动因和现实风险

C++在嵌入式实时领域流行的技术动因有三个：第一，RAII让资源管理变得可预测，锁、中断屏蔽、DMA缓冲区这些临界资源在退出作用域时自动释放，没有遗漏；第二，模板和constexpr把大量计算前移到编译期，让运行期路径变得精简；第三，现代C++的类型安全能挡住很多C语言时期靠“约定”才能维持的接口错误，比如用枚举替代裸int的错误码、用强类型包装底层寄存器地址。

但现实风险同样真实。默认的C++运行时可能引入你根本不需要的启动开销和标准库依赖。比如异常机制在很多MCU上会带来不小的代码量和栈开销，RTTI的动态类型识别在某些工具链上默认就开启，如果不在工程里主动裁剪，Flash和RAM都会莫名其妙涨一大截。同时，STL容器在堆上的频繁分配是实时性的大敌，无锁数据结构用不好反而会产生隐蔽的数据竞争。

所以我的建议是，嵌入式领域的C++，不是照搬桌面风格的“现代C++”，而是一套经过裁剪和约束的“嵌入式C++子集”。有效发挥语言优势，同时把那些与实时性冲突的语言特性明确禁用。这个子集具体包含什么，后面的章节会结合实现细节展开。

2. 工具链与工程基础：搭建嵌入式C++开发环境

环境这块看起来是老生常谈，但很多实时性问题，往深层挖恰恰是工具链配置不当导致的。链接脚本里的栈大小、启动代码里是否对C++全局对象进行构造、编译器优化级别和异常处理开关，每一项都会直接改变运行时行为。

2.1 交叉编译工具链版本与标准选择

选工具链时不要只看例程能不能编译，要关注三件事：标准库实现、语言标准支持、以及Newlib或类似运行时的裁剪程度。针对MCU的交叉工具链一般是基于GCC或LLVM/Clang的，区别在于对C++17/C++20的支持成熟度和生成代码体积。实测下来，GCC的arm相关版本在代码密度上通常不错，Clang的编译诊断信息更友好，但两者的库和链接行为有细节差异，不建议中途随意切换。

编译选项组里，我一般固定使用：

-std=c++17 -fno-exceptions -fno-rtti -fno-threadsafe-statics \ -ffunction-sections -fdata-sections -Wall -Wextra -Wshadow \ -Wconversion -Werror

其中两个选项在实时项目里特别重要：

• -fno-exceptions：禁用异常。实时系统里异常处理路径的时间不可控，而且异常处理表占用的Flash量不小。通过错误码或返回std::optional的方式上报错误更符合嵌入式习惯。
• -fno-threadsafe-statics：禁用局部静态变量的线程安全初始化保护。这个保护会在第一次进入函数时加锁，在单核MCU场景属于多余的同步开销，关掉能省一个隐藏的同步点。

同时在链接参数里加上--gc-sections，把没被引用的函数和段裁掉，代码体积可以和纯C方案拉近不少。

2.2 启动代码对C++全局对象构造的处理

这是新人最容易忽略的问题。C++全局对象需要构造，构造函数要在main之前执行，但这个步骤不是编译器自动帮你接好的，它依赖启动文件里的__libc_init_array之类的机制来调用全局构造器，同时把析构函数的注册也一并完成。

如果是从某个纯C工程改造而来，原来的启动文件很可能根本没调用构造器入口。你辛辛苦苦写好的全局对象，访问时数据全是乱的，或者直接触发硬件错误。这时需要检查map文件，确认.init_array段有没有被正确处理。简单验证办法是定义一个带构造函数的全局对象，在构造函数里给一个专用寄存器写固定值，看启动后寄存器值是否正常。

另外要注意链接脚本里堆和栈的边界。C++的局部对象、new操作符、以及某些标准库内部都会用到栈或堆空间，栈顶要定义在内存末端的固定位置，同时在启动代码中有一条显式的栈指针赋值指令。最好在栈区前后各放一段固定的填充模式，运行时周期检测这些填充值有没有被改写，以此判断栈是否溢出。

2.3 构建系统、烧录与调试链路

实时项目里，构建和调试链路要顺手，不然没人愿意频繁验证时序改动。实际使用中我倾向用CMake配合某个交叉工具链文件来管理代码，编译选项、链接脚本、生成hex和bin、烧录和调试任务全部集成到同一个流程里。

调试链路里，SWD接口比JTAG更方便日常使用，占用的引脚少，且多数调试器都支持SWO方式输出日志。我用SWO的典型场景是记录某个任务的调度延迟：在不打断实时流的情况下打印时间戳，误差比在中断里来回切换GPIO小很多。若调试器不支持SWO，再退回到GPIO翻转配合逻辑分析仪的办法，两种方法可以共用一套测试点位。

注意：不要在实时中断服务函数中直接做重日志输出。哪怕日志库宣称占用时间很短，格式化、缓冲清空和外部接口传输在最坏情况下仍然可能拉高中断延迟。日志职责应该放在低优先级上下文里，中断侧只写环形缓冲。

3. 实时任务设计：调度、中断与时间基准

实时系统的灵魂是调度和时序。我在做架构评审时，先看任务表，再看中断处理，最后才看业务代码。只要调度关系清晰，业务代码写得乱一点也有救；调度关系本身混乱，代码再漂亮也会在高峰负载时露出破绽。

3.1 选择周期性任务模型还是事件驱动模型

嵌入式实时系统常见的软件模型有两种：周期性任务模型和事件驱动模型。

周期性任务模型适合控制类应用。比如一个温度控制器，每10毫秒采集一次温度，执行PID计算，更新PWM输出。所有关键操作都固定在时间基准上，系统的行为可以理解成若干并发的定时器链。优点是时序可预测，缺点是CPU在非高峰时刻有大量空转，利用率不高。

事件驱动模型适合通信协议栈、按键响应这类“有事件才处理”的场景。它把CPU时间集中在真正需要处理的事务上，功耗低、响应快，但每个事件的处理延迟和多个事件并发时的仲裁逻辑比较复杂，一旦有多个高优先级事件同时到达，调度器要能保证关键事件优先处理，否则会丢数据。

实际项目中两种模型经常混用。比如无线通信模块用事件驱动，而传感器采样使用定时器中断触发周期性任务。混合模型下要在任务表中明确区分两类任务的优先级，避免事件风暴打乱周期任务的节奏。

3.2 优先级分配与优先级反转的规避

优先级分配我有几条土经验。第一，中断优先级和任务优先级是两个维度，不要混在一起排。外设中断的优先级应高于所有任务，因为中断是系统响应外部世界最快的手段。第二，任务内部按“截止时间紧迫程度”和“资源持有时间”两个因素排序。越靠近硬实时上限的任务越要排在前面，但要注意它持有的共享资源时间越短越好。

优先级反转是必须处理的经典问题。优先级反转指高优先级任务等待低优先级任务释放资源，而低优先级任务又被中间优先级任务抢占，导致高优先级任务等待时间变得不可控。解决手段有两种：互斥量启用优先级继承，或者干脆设计成“高优先级任务不等待低优先级任务”，而是把共享资源的访问做成无等待的方式。

我比较推崇后一种思路，在性能敏感路径上尽量设计成无锁或最小化临界区。比如传感器数据由一个任务采样写入，另一个消费任务直接读取最新值并加原子标志，就不需要互斥量。若必须用锁，把临界区代码控制在几条指令长度内，并且绝不在临界区内调用任何可能阻塞的函数。

3.3 中断服务程序的实时性设计：快进快出

中断服务程序的设计准则就八个字：快进快出。中断来时，处理器从当前任务切换到ISR，所有现场压栈，这个过程本身就有抖动，如果ISR里再执行大量运算或调用可能阻塞的服务，关中断时间就不可控了。

推荐的模式是“ISR里只做最少量必要操作，把耗时工作交给低优先级任务”。典型实现：

// 中断服务中只做两件事：记录时间戳，丢入环形缓冲 extern "C" void ADC_IRQHandler() { // 读出清除中断标志 ADC_IntClear(); // 把采样值和当前时间戳写入无锁环形缓冲 RingBufPush(sample_now()); }

如果硬实时要求更严的延迟抖动，可以采用“事件标志+PendSV”方式。用一个极短的ISR只更新时间戳和设置事件标志，然后在更低的PendSV异常中做批量处理。PendSV的优先级可以设置为比普通外设中断低，但高于所有任务，这样既保证了中断快速退出，也让后续处理依然享有确定性的调度优先。

3.4 用GPIO翻转法测量任务周期抖动

实时性不是靠感觉判断的，必须量化验证。最原始的量化手段是GPIO翻转法：在一个周期任务的开头拉高一个测试引脚，在任务结尾拉低。用逻辑分析仪测量脉冲周期，就能看到这个任务的周期抖动情况。

图省事的话也可以用一个定时器中断做辅助测量。设定定时器捕获某个测试引脚的电平变化，同时记录定时器计数，得到每个周期的精确时间戳。对这个时间戳序列做差值，能直接看到最大抖动在哪一次运行中发生。结合任务表，把抖动来源和那个时间点正在运行的任务对照，定位问题会非常快。

我在实际项目里会同时测三层时延：中断触发到ISR进入的延迟，ISR退出到对应任务恢复执行的延迟，以及任务开始到关键操作完成的延迟。这三层分别对应了中断压栈开销、调度器切换开销、以及业务代码的执行效率。调优时可以逐层定位瓶颈。

4. C++语言特性在实时环境下的取舍与落地

C++的众多特性并不是全都适合嵌入式。我这些年总结出一个经验：把语言特性分成“优先使用”“限制使用”“明确禁用”三类，写进团队规范，比在代码评审时逐条争论要高效得多。下面详细展开每一类的典型内容。

4.1 RAII：管理临界资源的第一选择

RAII大概是C++对嵌入式实时系统最友好的贡献。临界区、互斥量、中断屏蔽、GPIO方向配置、DMA通道占用，都可以封装成对象，利用构造和析构保证进入和退出。

我以前接手过一个老代码，中断屏蔽做得极其随意。函数A屏蔽中断，函数B调用某个异步回调，中间夹杂各种提前return，最后经常出现中断被多屏蔽一次或者少恢复一次，设备整机随机卡死。后来改成锁对象之后，问题彻底消失：

class InterruptLock { public: InterruptLock() { saved_state_ = DisableIRQ(); } ~InterruptLock() { RestoreIRQ(saved_state_); } private: // 保存中断使能状态，恢复时避免破坏嵌套场景 };

这段代码的核心技巧是保存进入前的状态，而不是简单地在析构时使能所有中断。原因是中断屏蔽可能存在嵌套，里层退出时如果直接开中断，会把外层屏蔽状态破坏，带来不可预期的并发窗口。RAII的另一个好处是析构顺序是确定性的，作用域退出即释放，不会因为函数中间某个分支漏掉收尾。

4.2 编译期计算与模板：把开销消灭在运行之前

C++的constexpr和模板在嵌入式里可以大显身手，因为MCU算力有限，把能在编译期完成的计算提前到编译期，运行路径就能少一大截。

constexpr函数典型应用是协议帧格式计算。比如一个报文，头部、数据区、校验字段各有固定偏移，你可以在编译期计算各字段的绝对地址，生成打包/解包数组。运行时只剩数据搬移，没有移位、乘法之类的计算，时间开销极低。

constexpr uint32_t ComputeCrcTableIndex(uint8_t byte, uint32_t poly) { // 编译期计算crc查找表项的代码，运行时零开销 }

模板适合做设备寄存器位域描述。用模板包装寄存器地址和位偏移，生成的代码在优化后往往和内联的移位与位与指令完全一致，但可读性和可维护性大幅提升。模板特化还能针对不同类型的外设提供不同的初始化行为，且不产生虚函数开销。

这里要强调：模板看多了代码膨胀。每个模板实例都会生成独立代码，在Flash空间紧张时容易被“代码爆炸”坑到。实际使用时，我会用静态断言限制实例化类型数量，并且用--gc-sections清理无用实例，发布前检查map文件里最大的几个函数是否超出预期。

4.3 容器和动态内存：能不用就不用，用则必须确定上下界

STL容器在资源受限环境下要非常谨慎。std::vector、std::list在正常运行中会动态申请堆内存，分配时机不可预测，分配耗时也会因为堆碎片而波动。在实时路径中，你不可能冒“某次push_back触发堆整理耗时3毫秒”的风险。

我的建议分三个层级：

• 实时路径内，全部使用静态数组、定长环形缓冲区、或者固定容量模板容器。例如用std::array替代std::vector，容量在编译期决定。
• 非实时但高频路径，可以用内存池加自定义分配器的容器，通过池化把分配时间收敛到纳秒级。
• 初始化阶段或配置阶段，才允许使用堆上的容器，且必须记录峰值占用。

如果确实需要动态分配特性，我建议实现一个固定大小的内存池，并把所有容器的分配器替换成这个池。自定义分配器的代码并不复杂，后面第5章会给出实现框架。

4.4 虚函数与回调：谨慎使用，明确场景

虚函数带来运行时多态，也会引入两个实时冲击。一是调用时多一层间接跳转，跳转目标在运行时才能确定，影响分支预测，部分MCU上会带来明显时延。二是vtable本身存放在RAM或Flash中，如果代码段被写保护或映射到不同地址空间，虚调用的行为可能出乎意料。

并不是完全禁用虚函数。如果系统状态机数量比较少，类型层次很浅，且每个分支的处理时间都比较短，用虚函数可以显著简化代码。比如多个传感器驱动共享同一个SensorInterface基类，用虚函数组织非常自然。

但有以下几种场景建议避免虚函数：

• 中断服务函数或硬实时任务里，虚函数调用目标不确定，时间上不可控。
• 对调用频率特别高的函数，比如每次采样都要执行的协议解析函数，尽量用模板或条件分支实现。
• 需要对象复用和存储位置确定的场合，比如对象池中存多态类型，虚析构会带来额外复杂度。

如果要做回调，用函数指针反而比虚函数更直白。C++11之后也可以使用std::function，但它在某些工具链实现里存在堆分配，需要在工程里禁用或替换为自实现的轻量回调对象。

5. 内存与资源管理：确定性分配的工程实践

实时系统的第二个命门是内存。堆碎片、分配耗时、栈溢出，每一样都可能导致间歇性故障，而这些故障最难查。因为它们在低负载时可能几天不出现，高负载时突然爆发，又不会稳定重现。

5.1 栈、堆与静态区的合理划分

固件里的内存大致分三块。.bss和.data段是静态和全局变量，生命周期覆盖整个系统，大小在链接时固定。栈用于函数调用和局部变量，大小由链接脚本设定，溢出后果非常隐蔽。堆用于动态分配，如果启用了malloc/new，就要接受它带来的碎片风险和不确定耗时。

我的工程模板惯例是：

• 全局对象和核心数据结构优先放静态区，数量在编译期就能数清楚，内存占用一目了然。
• 任务栈单独规划，每个任务栈要有至少25%的余量，并在栈底填充固定值，运行中通过监视哨兵检测溢出。
• 堆仅在初始化阶段可用，进入任务调度后禁止动态分配。
• 如果必须使用动态分配，使用内存池（后面给出实现）而不是通用malloc。

关于栈大小，可以先用一个保守值编译，运行不同负载场景，统计任务栈的最大使用量。测量方式是在任务每次回到就绪态时检查栈填充区是否被破坏，如果破坏则加大栈并重新测量。没有实测数据前，不要拍脑袋决定栈大小，否则要么浪费大量RAM，要么留下隐患。

5.2 一个轻量内存池的实现框架

内存池的原理很简单：初始化时按固定大小切分一整块内存，用空闲链表把所有块串起来，分配时取链表头，释放时插回链表。因为没有碎片，分配和释放的时间都是O(1)级别的，且耗时只取决于链表操作，与当前内存使用率无关。

template<typename T, size_t N> class MemoryPool { public: T* allocate() { if (free_head_ == nullptr) { return nullptr; // 池满，转入错误处理 } T* obj = reinterpret_cast<T*>(free_head_); free_head_ = free_head_->next; return obj; } void deallocate(T* obj) noexcept { // 把节点插回空闲链表头部，O(1) auto* node = reinterpret_cast<Node*>(obj); node->next = free_head_; free_head_ = node; } private: struct Node { Node* next; }; Node* free_head_ = nullptr; std::byte storage_[sizeof(T) * N]; };

这个池有几个隐含前提要说明。第一，池在初始化时一次性把整块静态数组划分好，绝无外部堆依赖。第二，如果池满，allocate返回空指针并触发错误处理，调用方要有明确的失败路径，不能在实时链路上做不定长等待。第三，deallocate是纯链表操作，可以在中断关闭状态下安全调用，但要注意同一池的不同线程/任务互斥问题，一般通过池级互斥锁解决。

使用这个池时，我还会再加一层“对象复用”语义，比如定义ReusableInterface，在释放时自动调用析构、重新分配时自动调用构造。这样对象生命周期管理就和内存池完全绑定，避免悬空指针和重复释放。

5.3 如何在编译期禁用动态内存

想让系统彻底避免动态内存，最有效的办法是在编译和链接层把new、delete、malloc、free等操作拒之门外。可以重载这些全局函数，让它们直接触发断言并进入死循环：

void* operator new(size_t size) { // 静态断言或上抛一个致命错误 PanicHandler(size); return nullptr; }

不要直接返回nullptr就完事，因为如果某个库内部把空返回值当成正常分支处理，问题会被悄悄掩盖。要让系统在出错时立即进入可观测的故障状态，比如点亮故障灯、把错误码通过SWO发出、然后halt住，这样调试时能一锤定音。

同时，检查链接的启动代码里是否包含堆初始化逻辑。有些工具链即使你没用到new，也会因为启用了某些标准库功能而引入堆。通过查看map文件中的_sbrk、_heap_end这类符号，能确认堆底边界是否被引用。若确认没有堆需求，把堆段大小设为零能节省RAM。

此外，尽量不使用std::string这类依赖动态分配的组件。需要定长字符串时用字符数组，需要可变长但不超过上限的缓冲区时用带容量的静态数组。自研的数据格式上，我习惯在所有字符串字段前面带上长度，避免处理时越界。

5.4 初始化阶段的顺序控制

C++全局对象构造不是按源文件顺序天然正确的。跨编译单元的全局对象依赖最典型的问题：A模块在构造函数里要读取B模块的全局配置，但B模块的构造函数还没跑，读到的是未初始化数据。

解决这个问题有三种手段。第一种是延迟初始化模式，用函数内部的静态局部变量来替代全局对象，首次访问时才构造。第二种是显式初始化顺序管理，启动代码里按依赖顺序调用各模块的init()函数。第三种是编译期构造，把对象放进.noinit段，并在启动代码中手工调用构造。

我比较喜欢第二种，因为它把初始化依赖暴露在明面上，排查问题容易。实际工程中，我会维护一张初始化顺序表，表里的每一项是一个结构体：模块名称、初始化函数指针、依赖标记。启动时按表顺序执行，任何一项返回错误就立刻停止并输出错误码。这张表写起来繁琐，但对系统的可维护性和审计性非常有益。

6. 调试、排查与性能验证实录

到了这一章，前面的设计和编码都已完成，接下来是残酷的验证阶段。把实时系统调稳定，往往比把功能跑通多花两三倍时间。下面把我在实际项目中高频遇到的状况整理出来。

6.1 高频问题速查与解决手段

排查工具方面，逻辑分析仪配合GPIO翻转法是最直接的手段。预算允许的话，也建议准备一个带数字捕获的示波器，观察关键信号的毛刺。软件层面，把调试日志输出通道和业务代码解耦，日志通过环形缓冲写入，用空闲任务或上位机命令周期上传，既不影响实时性又能拿到完整流程。

6.2 用SWO和环形缓冲做非侵入式追踪

做实时系统追踪时，我强烈推荐用SWO（Serial Wire Output）做辅助调试通道，如果手头芯片支持的话。SWO的优势是它由调试接口独立输出，不占用UART引脚，也不容易受应用代码中的中断抖动影响。你可以在关键路径的入口和出口各发送一个带时间戳的事件，通过上位机脚本重建任务时间线。

如果硬件不支持SWO，就退回到环形缓冲加GPIO翻转的组合。环形缓冲由一个中断服务程序写入时间戳，由调试任务周期性打包上传。需要注意环形缓冲本身也要是单生产者单消费者模型，否则需要额外同步。我一般用一个无锁环形缓冲，限制写入端和读取端各只有一个任务访问。

追踪数据要能定位三层问题：上下文切换延迟、任务执行耗时、以及中断被延迟的时间。分别在三层的边界上放置追踪点，形成一张完整的时序表。某次排查电机控制抖动问题时，我就是靠这种追踪数据发现，某个通信协议栈的任务每500毫秒执行一次Flash写操作，写的过程中会抢占电机控制任务约2毫秒，导致电流环周期被拉长。通过在追踪数据里看到任务重叠，一两分钟内就定位了根因。

6.3 我常在工具链层面加的两个检查项

第一是让链接器生成完整的Map文件，并建立一个检查脚本。脚本会分析最大的20个全局符号和最大的10个函数，设定上限阈值，一旦某个函数体积超过预期就打印告警。这个检查在每次构建时自动执行，能非常及时地发现模板实例化膨胀、内联失控等问题。

第二是开启编译器的-fstack-usage开关，把每个函数的栈使用量保存到分析文件。然后用脚本统计每个任务从入口到关键路径末尾的最大栈深度，结合任务栈尺寸自动生成警告。这个步骤成本很低，但能在调试前先把明显的栈风险拦截下来。

6.4 基于实际项目的实时性调优顺序

当实时性不达标，我的调优顺序通常是：先查中断延迟，再查任务抢占，接着查内存分配路径，最后才查算法效率。这四层里，前面任意一层的问题都可能让后面所有优化白费。比如算法再快，如果在高峰期被一个长关闭中断的临界区卡住100微秒，整体抖动仍然超标。

先把所有中断服务函数的时间控制到几微秒级别，再审查每个任务的临界区，确保没有在临界区内执行耗时且阻塞的调用。然后把动态内存路径清零，改用内存池或静态分配。算法层面的优化放到最后，因为编译器的优化和MCU的硬件特性往往比手写微优化更有效。

一点点收尾的经验

我这几年最深刻的体会是：嵌入式实时C++编程，难的从不是某个语法或某个库函数，而是把“确定性”三个字贯穿到每一行代码、每一个调度决策、每一段内存布局里。语言只是工具，C++提供了更多表达约束的方式，但约束能不能真的生效，取决于你对目标硬件的理解、对系统的量化测试，以及对实时概念的敬畏。用C++写嵌入式，最忌“堆功能”，最喜“立边界”。如果你能在项目初期就把实时任务表、内存规划表、以及“禁用特性清单”这三张表立起来，后面八成的问题都可以在设计阶段被消灭。