前言
体例约定：本书“第 N 部分“指五大主题分块（一-五，汉字数字），“第 N 章“指 1-20 编号章节（阿拉伯数字），“chXX“是同一章节的英文 ID，三者不混用。
在我待过的项目里，常常看到这样的代码：
三颗 LED 写三份几乎一模一样的函数。加一个新传感器，复制 5 个文件、改 30 个 #define。换一颗芯片像搬家，应用层全部重写，因为驱动层根本不是“驱动层“，是一堆“硬件操作的散装代码“。
不是这些工程师不努力。是 C 代码该怎么组织·我看到的系统讲过的不多。
中国市面上的 C 语言书多数在讲语法：指针、数组、结构体怎么用。嵌入式书多数在讲外设：GPIO、UART、I2C 怎么配寄存器。但“几千个外设驱动是怎么用同一个套路写出来的“、“为什么 Linux 内核 4000 万行 C 代码不会塌”，这些问题·我看到讲透的不多。
这本书补这个洞。
为什么从一颗 LED 开始
任何复杂的工业框架，都是同一套机制的放大。
LED 是一个驱动，ADC 也是一个驱动，电机也是一个驱动。它们的代码骨架完全一样。看懂一颗 LED 怎么从 struct + me 指针 一步步演化到 Platform 驱动，就看懂了 Linux 内核所有的字符设备驱动。
不需要 100 个例子。需要一个例子讲透。
这本书的特点
不实操也能完全理解。
读技术书最常见的挫折是“看懂了字面意思但还是不知道为什么这样写“。这本书的写法是：每一段代码改动，都解释“如果不这么改会怎样“。每一个 static、每一个 void *、每一个 container_of 都讲到不开 IDE 也能 follow。
如果你有经验，扫读一遍就懂。如果你刚入行，每段代码盯着看 3 分钟也能跟上。
双平台代码并行。
每一章的核心代码（struct + 函数）在 PC + STM32 两个平台上都能跑。书里的安排是：
- 主体代码用 PC 模拟实现，gcc 一句编译就能看到效果
- 章末贴 STM32 HAL 等效片段，告诉你换到真实硬件长什么样
完整的 STM32 Zephyr 工程见附录 B，Linux 内核驱动实战工程见附录 C。
真实工业代码做案例。
第五部分两章基于我参与的工业控制板真实项目代码。前面章节铺垫的所有抽象，到了这两章你能看到它们在真实项目里实际长什么样。中国其它嵌入式书几乎都用“LED 闪烁、按键消抖“这种 toy 案例。
代码 100% 跑通。
每一章配套的代码包都过 gcc -Wall -Wextra 0 警告编译，运行 exit 0，输出和章节正文描述一致。
Linux 内核风格代码。
书里的代码统一采用 Linux 内核编码风格：tab 缩进、K&R 大括号、80 列以内、struct led 而非 typedef Led_t。这是世界开源项目最广泛使用的风格。读完这本书你看 Linux 内核源码、Zephyr RTOS 源码不会觉得陌生。
永久免费在线阅读。
这本书不出版纸质版。所有内容在 https://zhaochengbo.github.io/zhaoming-embedded/ 永久免费阅读，仓库在 GitHub 和 Gitee 双 remote，国内国外都能 clone。
这本书和视频的关系
我在 B 站、抖音、视频号都叫「兆鸣嵌入式」。这本书的内容来自我录的「C 语言·一个 LED 讲透面向对象」系列视频。
视频是被动观看，节奏由我控制。书是主动阅读，节奏由你控制。
视频里说 “container_of 就是从成员反推出 struct 起始地址”，3 秒过去你可能没消化。书里这一句你可以盯着看 3 分钟。视频里代码一闪而过，书里你可以一行一行抄。视频发出去就不会再改，书里的代码我会持续修订，每个 commit 都过编译。
书面体相比口播体更深入。视频里因为时长没讲透的细节，书里都会补。
配套代码 vs 视频版
视频里出现的代码和章节配套代码包，会有一些不影响主线的小差异。原则简单：
- 视频先发，已经在 B 站、抖音、视频号上线，画面里录的是哪一份就是哪一份，事后不改。
- 配套代码包是工业级实现，跟着 Linux 内核风格统一收口，每章 0 警告编译、跑得通。
差异常见在三个地方：字段名（视频里 set_brightness，代码里 toggle）、typedef（视频用 LedOps_t，代码用 struct led_ops）、命名风格（视频用 LedBase，代码用 struct led_base）。这些差异都不影响 OOP 机制本身。电话簿装的是几个号码、号码叫什么名字，不改“电话簿 + 拨号“这件事。
读视频以视频画面为准，跑代码以 oop-in-c/code/<章节名>/ 里的代码包为准。每章末尾如果有具体的“视频版与配套代码版字段差异“小节，开头都会回指到这一节。同一句话不会反复展开三遍，知道这个原则就够。
和现有中文嵌入式书的差别
现有的中文嵌入式书大致两类。
一类是野火、正点原子的功能字典型：配套开发板，覆盖完整，对学生友好。短板是 100 万字、20 章外设，章和章之间没有叙事弧线，读完不知道掌握了什么思想。
一类是直接讲 Linux 内核源码，硬核。短板是门槛极高，新人 3 天放弃。
这本书是第三种：从最小的 LED 出发（门槛低），每一章只讲一个概念（聚焦），概念之间有清晰的因果链（叙事弧线），最后落到 Linux 内核风格的 Platform 驱动（够硬核）。
它会比工具书薄得多。但读完之后拿到任何一份工业代码，你能 5 分钟看懂它的骨架。
怎么读
按章顺序读最好。这本书的章节是有积木依赖的：第 11 章的多态需要第 7 到第 10 章铺垫，第 15 章的 Platform 层需要第 12 到第 13 章的转型机制。跳读会失去“为什么是这样设计的“的因果感。
如果就是想速通某个面试题，查附录 D 的索引找对应章。
如果在职工程师只想看“我现在的代码该怎么重构“，直接看第 15 章（换硬件不改应用）和第 16 章（为什么 Linux 一点都不难），再往前补需要的知识。
AI 时代和这本书
“AI 写代码，程序员要失业”，这两年这句话刷屏过太多次。我自己反过来看：写代码这件事被 AI 接走得越多，懂代码的人能做的事就越大。
数字是冷的。今年初的行业调研显示，每天在用 AI 编码工具的工程团队已经到了 73%，一年前这个数字还只有 41%。Linux 内核也在 2025 年 12 月正式合入了一份关于 AI 辅助 patch 的政策文档，写得很直接：可以用，但每一行都还是得有人署上自己的真名，承担合规和质量的全部责任。换句话说，电脑不可能被问责，人才能。这一句同时定义了 AI 时代的两个边界：能做什么，和不能做什么。
承认 AI 已经能写到内核级，再来想这本讲架构的书还剩下什么价值。
AI 写出来的代码是仓库自身风格的镜像。一个 base / ops / platform 分层清楚的工程，AI 加新驱动能顺着风格往下接；一个堆了几百个全局变量、回调乱飞的工程，AI 只会再往里多堆一份。一个工业机器人的多轴运动控制器、一套储能 BMS 的安全联锁、一个无人机飞控的传感器融合，这些场景里仓库有清晰接缝，AI 接续起来是顺的；没有接缝，AI 写得越多技术债涨得越快。架构本身就是 prompt 的一部分。
而且不只是 prompt。业界 2025 这一年悄悄发生了一次术语迁移：从“谁会写 prompt“，变成“谁会搭整个 harness“。Anthropic 把围着模型的这一整套脚手架（工具集、记忆、上下文边界、权限范围、并行执行、评估闭环）叫 agent harness。Google Chrome 那边一位工程师写过一句被反复引用的话：一个不太行的模型加一套好 harness，能打过一个很强的模型加一套烂 harness。你的代码仓库本身就是这个 harness 的一部分。AI 看着它学风格，按它的接缝写新代码，跟它的回调约定打交道。仓库架构差，相当于给 AI 一个差的脚手架，模型再强也救不回来。
而 AI 这件事，最先发现它能做什么、不能做什么的，是写代码这群人。AI 编码工具本身就是程序员做给程序员用的，第一批吃到红利的也是程序员。新模型一发布，最先把它跑遍极限的是程序员，最先做出能稳定工作的 agent 框架的是程序员，最先把它接到生产管线里去把事情真正做完的也是程序员。圈外人看到的 AI 是“能聊天、能写文案“的对话框；圈内人手里的 AI 已经是能跑长任务、能用工具、能审视自己输出、能在错误里自我纠正的协作者。同一个模型，区别就在于它周围有没有一个会写代码的人在搭脚手架。
最近还流行一个词叫 vibe coding：你不去读代码，顺着模型给的输出“感觉对了“就合进去。这种玩法做一个周末玩具、做一个 demo 演示，跑起来完全没问题。但代码一旦放到生产线上、放到一行写错就可能伤人或烧设备的工程上，vibe 这条路就走不通了。生产环境是另一种生物，它不在乎模型多花哨，它只在乎每一行代码有没有人能解释清楚为什么这么写。
还有一件事 AI 写得再好也改不了：签字。PID 参数错了，电机会撞机；中断里偷偷申请了内存，量产之后会在客户现场随机死机。AI 可以把候选代码摆到你面前，但按下合并按钮、把固件烧到二十万台设备上的那个人，是你。这种判断的训练靠的是把每一行代码读懂，知道它为什么这么写，改一笔会牵动什么。这本书想给你的就是这套读法。
程序员的时间结构也在重新分配。原本 80% 的时间在写胶水代码、查接口、调编译，这部分被 AI 接走，让出来的时间能花在理解业务、画架构、在硬件 / 软件 / 业务三层之间做权衡。我看到的真实变化是：原本需要业务专家、程序员、产品经理三方配合才能跑通的项目，现在一个手里有 AI、脑子里有架构、又愿意啃业务文档的人，可以一个人把整条链跑下来。AI 时代真正的稀缺，是这种能跨过“软件 / 硬件 / 业务“三层做综合判断的人。圈外人与其担心程序员失业，不如想想：当一个手里有 AI、又开始啃你这一行业务文档的程序员出现的时候，你这一行的入场门槛还守不守得住。
如果连嵌入式和系统这一层的人都能被 AI 整段替代，市面上别的大部分活早一步就先没了。
所以这本书的态度很简单：不要焦虑，把基础打牢，用 AI 放大自己。下面 20 章每一章都在帮你建立两件事：
- 架构判断：把代码组织到 AI 能放大你，而不是放大你的债的程度
- 生产责任：出问题有方向，能定位，能修，敢在 patch 上签自己的名字
AI 时代不是陷阱，是一台放大器。放大什么，看你手里给它递的是什么。
用 AI 一起读
你手上有 ChatGPT、Claude、Gemini、DeepSeek 这一类 AI 工具，建议边读边用它们。
这本书我尽力写得清楚，但知识本身是一张网，不是一条直线。线性看下去总会有几处你想多问一句“这一段背后还有什么“。把这本书的章节文本（或者具体一段代码）丢给 AI，让它给你扩展、举反例、用你更熟悉的领域类比一遍，比对着纸质书一行行查百度高效得多。
两种用法特别推荐：
- 费曼学习法配 AI：读完一节，把你理解的东西用自己的话讲给 AI 听，让它指出哪里不对、哪里不准确。讲不出来的部分就是你没真懂的部分。这套方法 Richard Feynman 教书时反复用，AI 让它从一对一变成随时可用。
- AI 当陪练，不当百科：问“这段代码为什么这样写“比问“什么是多态“信噪比高得多。具体场景的问题 AI 最擅长，开放式定义题它容易给你一段套话。
我作为作者必须说明：这本书有写得不够透、甚至写错的地方，我自己重读时还在改。AI 同样会犯错，特别是嵌入式、内核、硬件这些容错率极低的领域。把书和 AI 一起当工具用，互相校验，比单信任任何一方都稳。
最后一句话留给在职的你：现在不少卖课的把“答疑“当核心服务卖，但作为工程师，你的核心竞争力是自己解决问题的能力。十年前嵌入式工程师靠老工程师传帮带，现在你有 AI 工具，等于多了一个 24 小时在线的同事。这一代把 AI 用透的工程师，会比上一代有显著的产出优势。
怎么动手
有经验的工程师可以完全不跑代码。书里每段代码每行的意图都讲透了，不开 IDE 也能完全理解。扫读一遍就走的话也对得起这本书。
如果你刚入行或者想要更强的体感，跑一次代码会让你印象深刻。特别是第一次看到三颗 LED 共用一份函数被同一行 led_on() 依次点亮的时候。
每章对应一个 oop-in-c/code/<章节名>/ 目录，里面是完整可编译的代码。第 1 章对应 oop-in-c/code/01-three-leds/，目录里 pc/ 子目录是完整可跑的 PC 模拟版；STM32 真机端片段贴在每章 platform-mcu/stm32/ 下做对照。完整的跨平台工程（STM32 + Linux 用户态）从 ch15 起统一收在 15-platform/ 的 drivers/ + platform/ + linux-driver/ 一组目录里 (见 ch15 § 15.13)。
跑代码三步：
cd oop-in-c/code/01-three-leds/pc
make
./demo
Windows 用户装 MinGW 或 MSYS2（搜官方安装包一路 next，勾选“添加到 PATH“），命令行敲 gcc --version 看到版本号即装好。Linux 一句 sudo apt install gcc make。装好后整本书 20 章的代码都按上面三步跑就行。
没有 STM32 开发板能学吗？能。所有代码都通过 platform.h 抽象 GPIO，PC 上用 printf 模拟。等你学到第 15 章 Platform 层，会自己写一个 platform_stm32.c 替换 platform_pc.c，上层代码一行不改。这就是平台抽象的威力。
反馈与勘误
到 GitHub Issues 或 Gitee Issues 提一个 Issue，附上你看的章节、你的理解、你认为的问题。我会回。
读完哪章你觉得讲透了，哪章还差点意思，也欢迎写出来。这是迭代下一版的最好材料。