1. 嵌入式项目概述

各位同学，大家好。我是你们这门课的老朋友。今天咱们聊聊嵌入式项目最基础的东西——到底什么是嵌入式系统，它有什么脾气，以及我们该选哪种开发模式来驯服它。

说实话，我入行那会儿，嵌入式还没现在这么火。那时候做项目，基本就是「硬件画板子，软件写汇编」，哪有什么生命周期管理。后来踩的坑多了，才慢慢总结出一些门道。今天就把这些经验掰开揉碎，讲给你们听。

1.1 什么是嵌入式系统

嵌入式系统，说白了就是「藏在设备里的计算机」。它不像你桌上的PC，可以装各种软件。它专为特定任务设计，资源有限，但要求极高。

我习惯用一个公式来理解：

嵌入式系统 = 专用硬件 + 固化软件 + 特定功能

举个例子：你家的智能电饭煲。里面有个小芯片，跑着一段程序，控制加热、保温、定时。你没法用它打游戏，但它煮饭绝对比你的PC靠谱。这就是嵌入式——功能单一，但稳定可靠。

我个人遇到过最典型的案例，是给一家工厂做工业控制器。那设备要在高温、高湿、强电磁干扰的环境下，连续运行三年不重启。你想想看，普通电脑在这种环境下，早就蓝屏了。但嵌入式系统必须扛住。为什么？因为它从设计之初，就是为这种极端场景准备的。

1.2 嵌入式项目的特点

做嵌入式项目，跟做纯软件项目完全是两码事。我刚开始带项目时，就犯过一个错——用纯软件开发的思维去管理嵌入式项目，结果差点把项目搞黄。

嵌入式项目有几个「坑」，我一个个说：

1.2.1 软硬件协同开发

这是最大的特点。硬件还没出来，软件就得开始写。等硬件回来了，发现软件跑不通，到底是硬件bug还是软件bug？你想想看，这种「先有鸡还是先有蛋」的问题，在嵌入式项目里天天上演。

我曾经有个项目，硬件工程师说「I2C总线没问题」，软件工程师说「驱动代码没问题」。结果联调时，数据就是读不对。最后查了三天，发现是硬件原理图上I2C的上拉电阻画错了位置。嗯，这种扯皮的事，在嵌入式项目里太常见了。

1.2.2 资源极度受限

做PC开发，内存不够？加条内存条。硬盘不够？换个大的。嵌入式不行。芯片选型定了，资源就定了。你必须在128KB的Flash里塞下整个系统，在8KB的RAM里跑完所有任务。

我见过一个团队，为了省下200字节的RAM，把全局变量改成位域，把函数参数从int改成char。这种「锱铢必较」的优化，在嵌入式开发中是常态。

1.2.3 实时性要求

很多嵌入式系统是「反应型」的。比如汽车的安全气囊，必须在碰撞发生后的几毫秒内弹出。晚一毫秒，可能就是一条人命。

我记得做无人机飞控时，控制循环必须每5毫秒执行一次。如果某次循环因为中断嵌套延迟了，飞机就可能翻跟头。这种「硬实时」的要求，让嵌入式开发变得非常刺激。

1.2.4 调试困难

PC上写代码，printf大法走天下。嵌入式不行。你没法在芯片上接个显示器。很多时候，只能靠一个LED灯闪烁的频率来判断程序跑到哪了。

我早期做项目，最怕的就是「死机」。程序跑飞了，不知道卡在哪。后来学会了用JTAG调试器，才算是有了「透视眼」。但即便如此，有些bug还是得靠经验猜。

1.3 生命周期模型选择

好了，了解了嵌入式系统的特点和项目的难点，接下来就是怎么管的问题。生命周期模型，说白了就是「按什么节奏干活」。常见的三种：瀑布、敏捷、迭代。我分别说说在嵌入式项目里怎么用。

1.3.1 瀑布模型

这是最传统的模型。需求→设计→编码→测试→部署，一步接一步，像瀑布一样往下流。

阶段	输出物	嵌入式场景举例
需求分析	需求规格说明书	确定传感器类型、通信协议、响应时间
系统设计	架构设计文档	芯片选型、任务划分、中断优先级分配
硬件设计	原理图、PCB	绘制电路、布局布线、打样
软件编码	源代码	驱动开发、应用逻辑、协议栈
系统测试	测试报告	功能测试、压力测试、EMC测试
部署维护	生产文件、用户手册	量产烧录、现场升级、故障排查

什么时候用瀑布？

• 需求非常明确，几乎不会变（比如军工项目）
• 硬件成本高，改一次板子要花几万块
• 安全关键系统，每一步都需要严格评审

我个人觉得，瀑布模型在嵌入式里最大的好处是「可控」。每个阶段都有明确的交付物，项目经理心里有底。但缺点也很明显——太死板。等你把需求文档写完，市场可能已经变了。

1.3.2 敏捷模型

敏捷在互联网圈很火，但在嵌入式圈，很多人觉得「水土不服」。为什么？因为硬件没法「敏捷」。你不可能今天改个需求，明天就重新做块板子。

但敏捷的思想是可以借鉴的。我习惯的做法是：

• 硬件部分用瀑布：因为硬件改版周期长，必须一次做对
• 软件部分用敏捷：驱动、应用、协议栈，可以分版本迭代
• 联调阶段用Scrum：每天站会，软硬件工程师一起对齐进度

我曾经在一个智能家居项目中，硬件平台固定后，软件团队每两周发布一个固件版本。第一版只实现基本开关功能，第二版加入定时功能，第三版加入远程控制。用户反馈越来越好，产品也越做越稳。这就是「嵌入式敏捷」的实战。

1.3.3 迭代模型

迭代模型是我个人最常用的。它介于瀑布和敏捷之间。每个迭代周期（通常4-8周），完成一个「可工作的版本」。这个版本可能功能不全，但核心链路必须跑通。

举个例子：做一款智能手表。

• 迭代1：点亮屏幕，显示时间，按键响应。硬件能跑，软件能亮。
• 迭代2：加入心率传感器驱动，能采集数据并显示。
• 迭代3：加入蓝牙通信，能把心率数据传到手机。
• 迭代4：加入运动算法，计算步数和卡路里。

每个迭代结束，你都有一个「能跑」的版本。虽然功能少，但可以给客户演示，可以给测试团队验证。这样，风险被分散到每个迭代里，而不是到最后才发现「全盘皆输」。

我记得有个项目，做到迭代2时，发现蓝牙芯片的功耗超标。如果按瀑布模型，可能要到迭代4才发现这个问题，那时候硬件已经定型，改都来不及。但迭代模型让我们提前暴露了风险，及时换了芯片方案。

1.3.4 如何选择？

我给大家一个简单的判断标准：

• 需求稳定 + 硬件复杂 + 安全关键 → 瀑布模型
• 需求多变 + 硬件成熟 + 软件为主 → 敏捷模型（软件部分）
• 需求半明确 + 软硬件都有风险 → 迭代模型

你想想看，做汽车ECU（电子控制单元），你敢用敏捷吗？肯定不敢。但做一款智能玩具，需求天天变，你非要用瀑布，那就是跟自己过不去。

小结

这一章，我们聊了嵌入式系统的本质——专用、受限、实时、可靠。也聊了嵌入式项目的三个特点——软硬件协同、资源受限、调试困难。最后，我们对比了三种生命周期模型，给出了选择建议。

下一章，我会带大家深入需求分析阶段。那才是项目真正的起点。很多项目死就死在需求没搞清楚就开干。到时候我会分享一个我亲身经历的「需求变更惨案」，保证让你印象深刻。

好了，今天就到这里。记住一句话：嵌入式项目，七分管理，三分技术。把生命周期管好了，项目就成功了一半。