嵌入式系统项目分析入门与实践

　　KnowWhat，KnowHow，andKnowWhy在项目进行的过程中，常发生一些意料之外的事：诸如电路运行不正常、程序代码在不该出错的地方出了纰漏……。这种不太愉快的经验，电脑工程师们常称它为Bug。但从另一个角度来看，笔者就要恭喜读者了，因为您适时地抓住了系统的问题，让系统可以在出货之前就发现潜在的问题。KnowHow是不是一定要在项目进行的时候，才能发现这些要命的Bug呢？当然不是！在工程的应用上，常常会有一些经验公式或经验法则，这些东西存在的价值，就是确保不要在前人已经确认过的问题上再次浪费时间。通过这些知识，项目得以顺利地进行，我们把这些经验叫做KnowHow。KnowWhat一个KnowHow值得读者花多少时间去学习？或者花多少钱去购买呢？这和读者手上的项目有关。上过物理学的人都知道，一个从地表发射的实体，要多快速度才能脱离地球引力，顺利地到达设置的轨道？忘了？没关系，去查一查总会知道的。但是，如果设计一个可以从地表发射，并进到距地表6公里轨道的火箭，要如何做呢？笔者推想有95％以上的人根本连想都不想就回答说：不知道。在这个例子中，读者之所以知道如何求得正确的脱离速度，是根据课本上的公式算出来的，可以称为KnowWhat。以前求学时，认真一点的同学，还会思索这个公式如何推断出来，这已经有一点KnowHow的意味存在了。但对工程师来说，这还是隔靴搔痒。因为工程要的是产品与运用，也就是实际的产出。KnowWhat只能让我们有参与讨论的资格，还没资格进场和别人比赛呢！当开发团队有了KnowHow之后，就可以安安心心地去进行手上的项目了。也许是光驱的完全解决方案（TotalSolution），或者是某某驱动程序的源代码（SourceCode），这些东西都会让工程师的生活过得快活一点。但是等一等，事出有因，为什么要做这些事？各位，我们再将焦点转到上一段去。假设公司今天成功地研发出了一枚轨道火箭（假设公司请来了一位对火箭系统非常了解的专家，从KnowWhat到KnowHow一手包办。不但知道如何导出火箭的脱离速度，还能进到工厂第一线帮忙焊接金属管），但是别忘了，我们是一家设计嵌入式系统的公司，这个火箭好像对我们公司的业务与形象没有非常大的关联，这就是为何需要知道KnowWhy的核心之处了。KnowWhy在很久很久以前（现在也一样），老板要负起做决定的责任。就像当初美国甘乃迪总统要求工程师在十年内将人类送到月球上去一样。因为他知道，这样的举动会有什么样的结果与影响。底下的工程师当然就要使命必达地完成上面交付的任务。一批人负责推进，一批人负责导航，另一批人负责筹载，还有一些人负责找钱。果不其然，人类总算是成功地踏上了月球，还留下了“这是我的一小步，却是人类的一大步”之类感人的话。言归正传，要是今天公司也生产了一枚火箭，不但可能卖得不好，还可能受到政府相关部门的“关切”。所谓KnowWhy，讲成白话，就是为何要做？老板决定要做CD-RW，要做工业控制电脑，还是要做会走路的机器人，这都需要经过审慎的市场评估和一定的风险评估才能将人与钱投资下去，开始进行下一步的工作。综合上述的观点，每一个嵌入式系统项目都有它的KnowWhat、KnowHow、KnowWhy，由这些关键知识组成一个系统，缺一不可。但从实际的角度来看，要找到KnowWhat的人容易，找到KnowHow的人较难，但也并不是找不到，最难找的莫过于KnowWhy的人了。一个KnowWhy的人必须要能综观全局、评估项目可行性，并做出最重要的决定，那就是要不要做？要做什么？这种能力也就是本书想要向读者传达的精神，也就是“系统”的观念与实务。知识经济时代讲了这么多，读者也许会纳闷，为什么笔者一直强调KnowWhy的重要性，这不是交给老板或项目经理去解决就好了吗？是的，就以前的情况是这样的。但是到了知识经济时代，每个独立的知识工作者都有可能成为自己的老板。即除了读者本身的专业之外，还有可能要跟别的专业领域的人合作，决定要不要接某个项目，或者和上游厂商洽谈合作事宜。如果此时读者没有KnowWhy的能力，就要一辈子去追求新的KnowHow，并且将宝贵的时间花在别人的KnowWhy上，或者投资宝贵的时间在不被市场看好的产品上。KnowWhy能力的养成并非一蹴而就，但也非无从学起。本书所强调的系统观念，就是以系统工程为经，系统化方法作纬，并以一个项目故事来带领读者进入到以系统为主的观点上。在经济时代中，资本再也不是惟一的限制，惟一的限制在于各位的创意。如何将各位无限的创意变成一个真正的商品，其中关键就在于系统观念。系统观念着重的就是大处着眼、小处着手与瞻前顾后。其实说穿了，本书也只是一本KnowWhat的书而已。根据学习历程的3A原则Accept、Apply、Adapt，各位先试着去接受（Accept）系统的概念，进而去应用（Apply）。从中摸索出属于自己的方法，最后将自己的方法运用（Adapt）到手上的项目，那就是真真实实属于自己的智慧了。EnjoythisBOOk！

暂缺《嵌入式系统项目分析入门与实践》作者简介

第一篇 项目导学区
第1章 系统概念与市场需求
1. 1 下班后的工作室
1. 1. 1 下班后的工作室
1. 1. 2 Allen与Tim的技术背景
Allen的技术背景
Tim的技术背景
1. 2 第一笔交易
1. 2. 1 第一笔交易
1. 2. 2 新兴市场
1. 3 深入探讨
1. 3. 1 什么是系统
子系统的重要性
子系统的次序性
小结
1. 3. 2 什么是系统工程
系统需求
风险评估
制定系统规格
系统规划
系统设计
系统实现
系统测试
售后服务
项目讨论
提供明确的步骤
注重进程. 人力资源与成本之间的均衡
有效地记忆项目历史, 帮助系统发展组织的成长
小结
1. 3. 3 什么是系统化方法
一号工具：MindMap
二号工具：有效率的阅读
三号工具：问题分析与决策分析
小结
1. 3. 4 什么是嵌入式系统
小结
系统概念总结
1. 4 市场需求
小结
1. 5 进入嵌入式系统职场
1. 5. 1 嵌入式系统应用未来发展的趋势
无线网络
定址服务
射频身份识别 RFID 晶片
汽车通信／信息系统 Telematics
机器人
显示器
小结
1. 5. 2 嵌入式系统工程师所需具备的基本技术条件
综合能力
相关硬件
小结
第2章 风险分析与规格制定
2. 1 要不要接这个项目
2. 2 客户到底要什么
2. 3 深入探讨
2. 3. 1 风险分析
需求风险
时间风险
资金风险
项目管理风险
风险分析
小结
2. 3. 2 外包的考虑
外包的优点
外包风险
关于外包项目
小结
2. 3. 3 规格制定
系统功能
系统限制
系统开发资源
小结
2. 3. 4 和不同领域的专家合作
时间的优势
可靠性优势
风险
小结
本章结论
第3章 系统规划与设计
3. 1 请先等一等
3. 2 想好再动手
3. 3 两难的抉择
3. 4 深入探讨
3. 4. 1 系统规划
规格分析
预估项目进程
小结
3. 4. 2 系统设计
设计系统架构
寻找适当方案
系统设计
3. 4. 3 由上而下或由下而上的设计
3. 4. 4 设计阶段的一些决策
硬件方面
ICE和ICD
软件方面
HardReal-TimeSystem
SoftReal-Time System
小结
3. 4. 5 设计模板
本章结论
第4章 系统实现与测试
4. 1 按图施工
4. 2 突然想到的好主意
4. 3 工作室传来的笑声
4. 4 跑道上的悲歌
4. 5 深入探讨
4. 5. 1 系统实现
系统实现考虑
从硬件做起
从驱动程序移植开始做起
从现成平台开始做起
软件实现
学习微控器的架构与外设控制
设计驱动程序
撰写与测试驱动程序
和系统集成
硬件实现
小结
4. 5. 2 版本控制
如果没有版本控制
软件控制的工具
人员训练
小结
4. 5. 3 系统测试
测试的目的
测试的方向
测试的种类
小结
4. 5. 4 系统调试
系统调试
调试方向
调试方式
小结
本章结论
第5章 售后服务与项目总结
5. 1 售后服务
EMI问题的后话
5. 2 项目总结
5. 3 深入探讨
5. 3. 1 售后服务
5. 3. 2 项目讨论
本章结论
第二篇 项目装备区
第6章 MindMap
6. 1 什么是MindMap
6. 2 为什么要使用MindMap
MindMap在记录事情上的优点
MindMap在问题讨论与沟通上的优点
MindMap在项目执行上的优点
本书为什么要使用MindMap
6. 3 如何绘制第一幅MindMap
如何绘制MindMap
使用软件制作MindMap
6. 4 范例
本章结论
第7章 有效率的阅读
7. 1 什么是有效率的阅读
7. 2 为何需要有效率的阅读
7. 2. 1 何谓阅读效率
7. 2. 2 效率阅读带来的好处
7. 3 如何达到有效率的阅读
7. 3. 1 环境准备
加内存法
加内存法是如何运行的
7. 3. 2 预习
7. 3. 3 有指引的阅读
7. 3. 4 复习
7. 3. 5 反复使用与练习
7. 3. 6 专业文件攻略
Data Book
专业书籍
专业杂志
撰写报告
7. 3. 7 再一次测试
本章结论
第8章 问题分析与决策分析
8. 1 问题分析
8. 1. 1 什么是问题分析
8. 1. 2 为何需要问题分析
8. 1. 3 如何进行问题分析
8. 1. 4 问题模式
问题模式基本观念
环路式思考
时间延迟
双重恶性循环
8. 1. 5 问题分析实例——麻烦的USB Driver
新的挑战
练功之旅
开什么玩笑
原来Spec. 上面写着
Byte Alignment
超频问题
另一种CPU Endean
时序问题
另一种CPU时序问题
小结
8. 2 决策分析
8. 2. 1 什么是决策分析
8. 2. 2 为何需要决策分析
8. 2. 3 如何进行决策分析
8. 2. 4 决策分析实施案例——要不要接这个项目
MEI委托案的决策分析
决策分析实施案例——微控器的选择
小结
本章结论
第9章 数据收集
9. 1 为何需要收集数据
9. 2 要收集哪些数据
决定要设计何种系统
研究如何进行系统设计
实际进行设计
系统验证与微调
推出产品
9. 3 如何进行数据收集
查市场报告与趋势分析
查论文
查技术报告
查规格与标准
查专利
用搜索引擎查数据
9. 4 范例
本章结论
第10章 在嵌入式项目中使用UML
10. 1 什么是UML
10. 2 使用UML的好处
10. 3 UML范例
基本程序流程图
Use Case Diagram
Activity Diagram
State Chart Diagram
Sequence Diagram
Deployment Diagram
Class Diagram
10. 4 利用UML描述系统
系统分析阶段
系统设计阶段
本章结论
第11章 PCB How-To
11. 1 需求
11. 2 规格
11. 3 规划
11. 4 逻辑设计
11. 5 工程外包
11. 6 焊接
测试
取得硬件检查点
分模块测试
撰写功能完整的测试程序
11. 7 调试
本章结论
附录 缩写简表