1. 课程导入
嵌入式开发长期以 C 语言为主，但在芯片资源日益丰富、系统复杂度持续上升的今天，C++ 的零开销抽象、类型安全与泛型能力正成为提升工程效率与代码可靠性的关键手段。本课程聚焦“现代 C++（C++11 及以后）在嵌入式系统中的工程化落地”，不是单纯讲语法，而是围绕可编译、可调试、可测试、可维护的真实工程链路展开。
一、学习目标：从“会写 C”到“会做嵌入式 C++ 工程”
本课程的学习目标可以归纳为四个层次，它们由浅入深、层层递进：
- 语言层：掌握现代 C++ 在资源受限环境下的可用子集，理解
constexpr、auto、enum class、模板、RAII 等特性如何做到“零开销”。 - 抽象层：能用类、接口、策略与模板对寄存器、外设、驱动进行封装，避免传统宏与函数指针带来的可读性问题。
- 工程层：掌握交叉编译工具链、CMake 构建、链接脚本、启动文件、静态分析与单元测试的完整流程。
- 系统层：理解中断、内存布局、栈与堆、实时性与并发模型，能判断哪些 C++ 特性适合上机、哪些必须禁用。
核心判断标准：一段嵌入式 C++ 代码是否合格，不取决于它用了多少新特性，而取决于它是否在编译期确定、运行时无额外开销、行为可预测、故障可定位。
二、核心概念：嵌入式 C++ 的四个关键词
在进入具体章节前，需要先建立四个贯穿全课程的核心概念。
- 零开销抽象（Zero-overhead Abstraction）：抽象不应带来运行时成本。模板在编译期实例化，
constexpr在编译期求值，内联函数消除调用开销。 - 资源所有权（RAII）：把资源生命周期绑定到对象生命周期，构造即获取、析构即释放，避免忘记关闭外设或释放锁。
- 类型安全（Type Safety）：用
enum class、强类型句柄替代裸整数与宏，让编译器在编译期发现接口误用。 - 可预测性（Predictability）：嵌入式系统关注最坏执行时间与内存占用，动态分配、异常、RTTI 等需谨慎评估甚至禁用。
下面的关系图展示了这四个概念如何共同支撑“嵌入式 C++ 工程能力”，并与工具链、运行时约束形成闭环。
三、整体知识框架：课程如何组织
本课程共 30 章，整体按“语言基础 → 抽象建模 → 工程构建 → 系统实战”的主线推进。下表给出模块划分与关键内容，便于建立全局地图。
| 模块 | 核心内容 | 典型产出 |
|---|---|---|
| 语言基础 | 类型系统、constexpr、引用与移动语义、模板入门 | 可在 MCU 上编译的现代语法子集 |
| 抽象建模 | 类封装、接口与策略、RAII、强类型句柄 | 外设驱动与硬件抽象层 |
| 工程构建 | 交叉编译、CMake、链接脚本、启动文件、静态分析 | 可复现的固件构建工程 |
| 系统实战 | 中断、内存布局、实时性、并发与状态机 | 可运行、可测试的嵌入式应用 |
四、开发环境搭建：从零到可编译
嵌入式 C++ 开发环境与桌面开发最大的区别在于“交叉编译”。宿主机上运行的工具链生成的是目标芯片可执行的机器码。以 ARM Cortex-M 为例，典型工具链为 arm-none-eabi-gcc 与 arm-none-eabi-g++。
# 1. 安装交叉编译工具链（Ubuntu 示例）
sudo apt install gcc-arm-none-eabi g++-arm-none-eabi
# 2. 验证版本
arm-none-eabi-g++ --version
# 3. 最小编译命令示例
arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -std=c++17 \
-ffreestanding -fno-exceptions -fno-rtti \
-Os -c main.cpp -o main.o
其中几个关键参数需要特别理解：-ffreestanding 表示不依赖宿主标准库环境；-fno-exceptions 与 -fno-rtti 关闭异常与运行时类型信息，减小体积并提升可预测性；-Os 优先优化代码尺寸。
建议在工程中固定 C++ 标准版本（如
-std=c++17），并在 CMake 中统一管理编译选项，避免不同开发者环境不一致导致的行为差异。
五、常见误区与复盘
初学者在嵌入式 C++ 上最容易踩的坑，往往不是语法问题，而是工程判断问题。
- 误区一：把桌面 C++ 直接搬到 MCU。动态分配、异常、RTTI、
std::iostream会带来不可控的代码体积与运行时行为。 - 误区二：认为“用了 C++ 就一定慢”。现代 C++ 的零开销抽象在编译期完成，实际性能可与手写 C 相当，关键在于是否误用。
- 误区三：忽视链接脚本与启动文件。没有正确的内存布局，程序可能根本无法启动或栈溢出。
- 误区四：不做单元测试。嵌入式代码同样可以在宿主机上对纯逻辑部分进行测试，提前发现缺陷。
在资源极度受限的芯片上，任何新特性的引入都应先评估其代码体积、栈占用与最坏执行时间，再决定是否启用。工程判断优先于语言偏好。
完成本章后，你应当能够说清楚：本课程要解决什么问题、现代 C++ 在嵌入式中的边界在哪里、整个知识框架如何衔接，以及如何搭建一个可编译、可调试的最小工程。接下来的章节将沿着这条主线，从语言基础开始逐步深入。