📚 课程目录第2章嵌入式系统与C++基础

2. 嵌入式系统与C++基础

嵌入式开发与桌面应用开发最大的差异，不在于“芯片小”，而在于资源、时序和可靠性约束同时收紧。理解这些约束，才能判断 C++ 的哪些特性可以直接使用、哪些需要谨慎裁剪、哪些必须禁用。本节从嵌入式系统特点出发，梳理 C++ 在嵌入式中的优势与限制，再落到编译工具链、内存模型与运行时环境，为后续接口与组件设计建立底层认知。

一、嵌入式系统的四个硬约束

嵌入式系统通常围绕“专用功能 + 长期运行 + 资源受限”展开，其核心特点可以归纳为四点：

资源受限：Flash 可能只有几十 KB，RAM 只有几 KB 到几百 KB，CPU 主频低，无 MMU 或仅有 MPU。
实时性要求：中断响应、控制周期、通信超时都有明确上限，不能依赖“平均性能”掩盖最坏延迟。
长期无人值守：设备可能连续运行数月甚至数年，不允许内存泄漏、栈溢出、死锁累积。
软硬件强耦合：寄存器、外设、DMA、时钟树直接决定代码行为，接口设计必须反映硬件边界。

关键判断：在嵌入式里，“能跑通”不等于“可交付”。可交付意味着在最坏情况下仍满足时序、内存和可靠性约束。

二、C++ 在嵌入式中的优势与限制

C++ 相比 C 的最大价值，不是“面向对象”本身，而是零开销抽象：在编译期完成类型检查、接口约束和代码生成，运行期不引入额外成本。典型优势包括：

强类型接口：用类、枚举类、模板约束参数范围，减少误用。
RAII 管理资源：构造获取、析构释放，天然适配锁、文件、DMA 通道等资源。
编译期计算：constexpr、模板元编程可把查表、配置校验前移到编译期。
内联与零成本：合理使用 inline、模板和 constexpr，抽象层可被完全优化掉。

但 C++ 也有必须警惕的限制：

异常与 RTTI：多数嵌入式工具链默认关闭 -fno-exceptions、-fno-rtti，因为异常表会增大 Flash，栈展开时间不可预测。
动态内存：new/delete 在碎片化和最坏延迟上不可控，实时路径通常禁用。
虚函数与多态：虚表带来间接跳转和 ROM 开销，硬实时路径需评估。
标准库：<iostream>、<thread>、<filesystem> 往往不可用或代价过高。

三、编译工具链：从源码到可执行镜像

嵌入式 C++ 的工具链通常是“交叉编译”结构：在主机上编译，生成目标芯片可执行的镜像。典型流程如下：

源码(.cpp/.h)
   │
   ▼
交叉编译器 arm-none-eabi-g++
   │  -mcpu=cortex-m4 -mthumb -Os
   │  -fno-exceptions -fno-rtti -fno-threadsafe-statics
   ▼
目标文件(.o) ──► 链接器 ld ──► 可执行文件(.elf)
   │                              │
   │                              ▼
   │                        objcopy 生成 .bin/.hex
   ▼
静态库(.a) / 启动文件 / 链接脚本(.ld)

其中链接脚本决定 Flash、RAM、栈、堆的布局；启动文件负责初始化 .data、清零 .bss、设置栈指针并跳转到 main。工具链常用选项包括：

选项	作用	嵌入式建议
`-Os`	优化代码体积	默认优先，Flash 紧张时使用
`-fno-exceptions`	关闭异常	实时系统建议关闭
`-fno-rtti`	关闭运行时类型信息	减少 ROM 与虚表开销
`-ffunction-sections`	每个函数独立段	配合 `--gc-sections` 裁剪未用代码
`-Wall -Wextra`	开启警告	尽早暴露类型与未初始化问题

四、内存模型与运行时环境

嵌入式 C++ 的内存通常分为：Flash（代码与常量）、RAM（数据、栈、堆）、外设寄存器区。理解各段的生命周期，是接口设计的基础。

.text：代码与只读常量，位于 Flash。
.data：已初始化全局/静态变量，启动时从 Flash 拷贝到 RAM。
.bss：未初始化或零初始化变量，启动时清零。
栈：函数调用、局部变量、中断上下文，大小在链接脚本中固定。
堆：动态分配区域，嵌入式常设为 0 或极小。

常见误区：把“堆用得很小”当成安全。真正危险的是栈溢出和中断嵌套过深，它们往往在压力测试或现场才暴露，且难以复现。

运行时环境方面，嵌入式 C++ 通常没有完整的操作系统支持。若使用 RTOS，任务栈、优先级、临界区、信号量都由 RTOS 管理；若为裸机，则需自行处理中断向量、时钟节拍和主循环调度。无论哪种情况，全局对象的构造顺序、静态局部变量的线程安全、atexit 行为都与桌面环境不同，必须在设计接口时显式考虑。

五、案例：一个 LED 控制接口的取舍

假设要设计一个 LED 控制组件，裸机、Cortex-M4、Flash 64KB、RAM 16KB。若直接使用 std::function 和 new 注册回调，会引入堆分配和间接调用；更合适的做法是：

class Led {
public:
    constexpr Led(volatile uint32_t* gpio, uint32_t pin)
        : gpio_(gpio), pin_(pin) {}

    void on()  const { *gpio_ |=  (1u << pin_); }
    void off() const { *gpio_ &= ~(1u << pin_); }

private:
    volatile uint32_t* gpio_;
    uint32_t pin_;
};

// 编译期确定对象，无堆、无虚表
constexpr Led kStatusLed(GPIOA_ODR, 5);

这个例子体现了嵌入式 C++ 的核心思路：用编译期约束替代运行期检查，用值语义替代动态分配，用内联替代间接调用。接口简单、可预测、可静态分析，才是嵌入式组件设计的优先目标。

六、复盘：从“能编译”到“可交付”

很多团队在嵌入式 C++ 上的问题，不是语法不会，而是默认了桌面开发的假设：默认有堆、默认异常可用、默认标准库齐全、默认栈足够大。把这些假设逐条显式化，才能形成可交付的接口与组件。建议在项目初期就明确：是否启用异常与 RTTI、堆是否使用、栈预算多少、中断延迟上限多少、哪些标准库允许引入。这些决策会直接决定后续接口的形态与组件的边界。