有许多朋友都曾跟我聊过类似这样的问题——想要从事嵌入式行业都需要学习哪些知识？

每当面对这个问题的时候，其实我也是一脸懵逼状态的，这些问题真心很不好回答，说少了，有敷衍的嫌疑，说多了，又是长篇大论，于是为了解答这个问题我决定写下这篇文章，暂定的名字叫《嵌入式系统架构师之道》。

虽然我自己也还在这条道上“上下而求索”，但毕竟是在嵌入式行当里摸爬滚打将近十年了，午夜梦回也会抓起床头的小本子记录一下零星的感悟，时间久了总算是找到了一条我认为能够在嵌入式领域登堂入室的大道。

这是一条我自己的道，所以，正在阅读这篇文字的亲们：

如果您是前辈，还请不吝指教；

如果你是道友，我们不妨相互印证一下彼此的心得、彼此的道；

如果你是正准备踏上这条道的菜鸟，真心希望我总结的道能让你少走一些弯道。

何谓嵌入式系统？

对于嵌入式系统的定义，最权威的莫过于IEEE给出的定义：“Devices used to control, monitor, or assist operation of equipment, machinery or plants.”

可是这个定义实在是太宽泛了，宽到跟没说一样。

所以我个人还是比较倾向于咱们国家计算机技术与软件专业技术资格（水平）考试指定的那本《嵌入式系统设计师教程》（后文简称为教材）中的给出的一句解释：“嵌入式系统是一种专用的计算机系统，作为装置和设备的一部分。……”

诚如教材中的解释所说，在早期的工程应用中，嵌入式系统就是一种专用的计算机系统。

由于使用通用的计算机系统成本太高，为了降低成本，于是针对某个领域内的具体应用，重新设计软、硬件结构，优化掉无用的部分，一方面降低了系统的成本，另一方面也有针对性地提升了系统的性能。

但，一开始的嵌入式系统远没有现在这么丰富多彩。近些年来半导体技术的爆发式增长，Soc也越发的变得复杂，与此同时，通信技术的发展也极大地推动了嵌入式系统的繁荣。

随着微处理器成本越来越低、性能越来越好，成本的因素在嵌入式系统中的约束已经越来越弱化，如果当前的发展趋势可以保持下去的话，在可预见的将来，嵌入式系统的设计与研发也许将会向着集成化、通用化、模块化的方向发展。

不过咱们话说回来，无论是IEEE、还是教材中的解释都明确指出，嵌入式系统一定是包含软件和硬件两个部分的。

近些年来，我面试别人的时候常常遇见一些有志于嵌入式行业的青年，只学习了一写嵌入式Linux的剪裁和移植，和基于Linux的程序开发就来面试嵌入式的岗位。

每到这个时候，我的内心都是很困惑的，不知道从什么时候开始，嵌入式的培训变成了Linux培训，会在Linux系统上用QT写扫雷真的不能叫懂得嵌入式。

记得大学的时候刷侯捷老师的《深入浅出MFC》这本书的时候，印象最深的就是郑重写在章节前面的一句话“勿在浮沙筑高台”，在我之后的技术生涯中，这句话一直被我奉为座右铭。

那么当前的嵌入式系统知识体系中都包含哪些内容呢？

嵌入式行业发展到今天这个地步，我个人认为，如果想从事嵌入式这个行业，并且想要有所成就，至少如下六块技术都要有所涉猎：

除此之外，想成为嵌入式系统架构师以上这些知识也还是不太够看，至少还需要在加上两大部分：

做系统设计，尤其是嵌入式系统的设计，绝大多数时候是与行业密切相关的，很多时候即使是同样的功能需求，在不同的行业应用中也会导致完全不同的系统设计。例如，同样是温湿度的采集，对于野外的气象数据收集模块通常的要求是防尘、防水以及低功耗，对数据的实时性要求不高，而放在工业领域上则更侧重的是测量精度与实时性要求，但放在民用领域则更看重的是低功耗与有好的人机交互，对精度和实时性反而没什么要求。一个嵌入式系统最终成败，很大程度上取决于设计者对目标行业的理解程度，不仅包含输入的需求文档还有最终用户的使用习惯、目标行业的工艺流程甚至操作人员的教育程度等等。

关于系统架构师是否要懂得项目管理这个话题就不在这里争论了。在我看来，一个工程从需求导入、到系统设计、再到系统实现、实施乃至最后的交付，整个过程中，无论是资源申请、成本估算，还是风险评估、进度跟踪，都与架构师的工作密不可分。很难想象在一个项目中，架构师只管将设计抛给项目经理，之后就对项目不理不睬，这应该就是一场灾难。

这也正是我心中的嵌入式系统与嵌入式系统架构师。

所以我坚信，只有像这样一步一步踏踏实实走出来的道，才是真正通往嵌入式系统架构师的康庄大道。

最后，献上一幅嵌入式架构师知识地图，与诸位道友共勉！