目录
1 7 . 4 嵌 入 式 系 统 开 发
嵌入式系统的应用软件是面向特定用户和特定应用的软件系统，是实现嵌入式系统功能的关键，嵌入式系统用途广泛、种类繁多，因此，嵌入式应用软件也多种多样，应用软件的类型和开发难度也千差万别。近年来，随着嵌入式支撑软件的迅速发展，应用软件的幵发条件、开发环境和开发效率都得到了极大的改善，同时也使得应用系统的功能不断增强。
17.4.1 开发平台
嵌入式系统的软件开发方法采用的不是通用的幵发方法，而是交叉式开发方法，即软件在一个通用的平台上开发，而在另一个嵌入式目标平台上运行。这个用于开发嵌入式软件的通用平台称为宿主机系统，被幵发的嵌入式系统称为目标机系统。而当软件执行环境和幵发环境一致时的开发过程则称为本地开发。
1 . 交叉开发环境
图 17-11是一个典型的交叉平台开发环境，包含三个高度集成的部分：
(1) 运行在宿主机host和目标机target上的强有力的交叉开发工具和实用程序。
(2) 运行在目标机上的高性能、可裁剪的实时操作系统。
(3) 连接宿主机和目标机的多种通信方式，例如，以太网、USB、 、串口、ICE( (In-Circuit
Emulator ，在线仿真器）或 ROM
宿主机提供的基本开发工具是交叉编译器、交叉链接器和源代码调试器，作为目标机的嵌入式系统则可能提供动态装载器、链接装载器、监视器和调试代理等。在目标机和宿主机之间有一组连接，通过这组连接，程序代码映像从宿主机下载到目标机，这组连接同时也用来传输宿主机和目标机调试代理之间的信息。
嵌入式系统幵发人员需要完全了解目标机系统如何在嵌入式系统上存储程序映像、可执行映像如何下载到内存，以及执行控制如何传递给应用•，需要了解运行期间如何和何时装载程序映像，如何进行交叉式的开发和调试应用系统等，这些方面对代码的开发、编译和链接等步骤都有影响。
2 . 交叉编译环境
图 17-12是一个典型的交叉编译环境的示例，显示了如何使用开发工具处理各种输入文件，并产生最终目标文件的过程。在 图 17-12中，交叉编译器将用户编写的C/ /C ++/Java 源代码文件根据冃标机的CPU类型，生成包含二进制代码和程序数据的目标文件。在此过程中，交叉编译器会建立一
个符号表，包含所产生的目标文件中指向映像地址的符号名，当建立重定位输出时，编^器为每个相关的符号产生地址。
通常，还可以使用归档器将这些目标文件收集到一起，形成一个库。最后，链接器将这些目标文件作为输入来产生一个可执行的映像。一般来说，用户会首先编辑一个链接脚本文件，用来指示链接器如何组合和東定位各个代码段，以便生成最终文件。此外,链接器还可以将多个目标文件组合成一个更大的重定位目标文件或一个共享目标文件。
在嵌入式系统中，一个目标文件通常包含通用信息（例如，文件尺寸、启动地址、代码段和数据段等具体信总）、机器体系结构特定的二进制指令和数据、符号表和重定位表，以及调试信息等。目前，嵌入式系统中常用的目标文件格式是通用对象文件格式(Common Object File Format, COFF ) 和可执行链接格式（ Executable Linking Format， ，ELF ) 。另外，一些系统还需要有一些专门工具，将上述格式转换成二进制代码格式才可使用。
17. 2 开发流程
嵌入式系统软件的开发过程大体可以分为项目规划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段，各个阶段不断反复，直到最终完成设计目标。与通用系统的开发类似，嵌入式系统的开发过程也可， 以采用软件工程中常见的开发过程模型，例如，瀑布模型和螺旋模型等。在开发过程中，设计人员可以根据具体应用的特点和设计目标，选用合适的分析与设计方法。
1. 过程模型
在嵌入式系统开发实践中，人们提出了一些专门面向嵌入式系统开发的过程模型，例如，嵌入式系统快速面向对象过程（ Rapid Object-Oriented Process for EmbeddedSystem, ROOPES ) 是一个迭代的基于UM L 的过程模型，无 线 Internet 服务工程过程 (Wireless Internet Services Engineering Process ，WISEP ) 是一个用于无线 Internet 服务的专用领域的过程模型，这些模型能够很好地与特定的幵发组织和约束条件（例如，应用领域和技术特点等）相适应。
在众多模型中， R O O P E S 在实时嵌入式开发环境中得到了大量应用。 R O O P E S 模型
的核心思想是螺旋式迭代。对于大多数嵌入式系统的幵发，完全的瀑布模型（时间太长）和螺旋模型（过于敏感）都是不适合的，这是因为系统开发的初期，有很大一段时间是开发和生产硬件，而且生产周期往往比较长，这就要求硬件的开发要先于软件开发，且所有的硬件需求在产品运行之前都必须清楚。完全迭代的解决方案在这种情况下是不可能清楚详细需求的。为此,R O O P E S 提出了半螺旋式生命周期模型，如 图 17-13所示，将瀑布模型和螺旋模型结合起来，进行适当裁剪来适应不同的项目。
在半螺旋模型中，需求分析和系统工程两个阶段在迭代之前进行，与瀑布模型的生命周期一样，仅进行一次。但是，比螺旋模型生命周期中的需求定义要完整得多，即系统整体的基本功能已经完成。//嵌入式系统先做好需求和设计，迭代主要发生在软件开发阶段！！！
在系统工程阶段，首先定义完整的高层架构；然后，定义架构的子系统，并进行软件和硬件的划分和功能分配。
瀑布模型和半螺旋模型的主要差别在于螺旋部分，半螺旋模型要创建一系列的原型，原型的不同部分由不同的小组进行独立开发，然后在集成和测试阶段汇集到一起。
2 . 分析与设计方法
分析与设计方法对于嵌入式系统成功幵发具有十分重要的意义，这是因为良好的设计方法可以使设计人员淸楚地了解他们所做工作的进度，确保不遗漏其中的任何一项工作：允许使用 C A S E 工具帮助设计人员进行工作，将整个过程分成几个可控的步骤进行。
良好的设计方法方便设计团队的成员之间相互交流，通过定义全面的设计过程，团队里的每个成员可以很好地理解他们所要做的工作，以及完成分配给他们的任务时所达到的目标。
目前，嵌入式系统常用的分析与设计方法主要有改进的结构化方法、面向对象的方法和基于构件的方法。
(1) 改进的结构化方法。
早期，实时系统的设计方法主要是结构化设计方法，在传统的结构化设计方法的基础上，人们提出了很多针对实时系统的设计方法，例如，实时（ 结构化分析与设计（Real-Time Structured Analysis and Design ，RTSAD ) 、实时系统设计法 方 法 （ Design Approach for Real-Time System ，DARTS ) 和并发实时系统设计方法(Concurrent DARTS, CODARTS ) 等。
这些方法本质上是结构化方法和数据流分析方法等传统方法向实时嵌入式软件开发领域的扩展。采用结构化方法的系统在复用性和可修改性等方面有较大的局限性。
(2) 面向对象方法。
面向对象的实时系统设计方法在可复用性和可修改性等问题上具有明显的优势。采用 0 0 A 和 O O D 可以很好地对大型、复杂的实时系统进行分析与设计。目前，己存在不少针对实时系统的面向对象方法，例如，0 0 D 方法侧重于对象划分和信息隐藏，但在多任务结构方面和实时性的处理能力明显不足；
实时的面向对象建模 （Real-time Object-Oriented M odeling, R O O M ) 方法主要着重设计和实现阶段，为描述对象的行为定义了一套文本和图形语言；实时系统面向对象技术 （Object-Oriented Technology forReal-Tim e System ，O O T R T S ) 方法以 O M T 和融合方法 （ Fusion M e th o d ) 为基础，提出了对实时系统响应时间、时间域和并发的处理方法，并具体提出了对并发（先并发）、同步（后同步）、通信（再通信）、中断处理和硬件界面等方面的处理。 O O T R T S 方法将软件开发的主要阶段很好地合并起来，从规格说明到运行模型之间的过渡紧密自然，还支持渐进式开发。
(3) 基于构件的方法。
构建具有清晰的接口和良好的复用机制，日益成为提高嵌入式开发效率和改善嵌入式软件质量的一种重要手段。在嵌入式系统设计中，实时内核、网络协议栈（TCP/ /IP ) 、嵌入式Web 服务器、嵌入式数据库、嵌入式CORBA 、数据压缩算法和视频处理算法等均可作为构建嵌入式系统的构件。CORBA、 、EJB、 、COM/DCOM等主要的几类构件形式也都会逐步用来构造嵌入式系统。
17.4.3 软硬件协同设计
嵌入式系统设不同于通用系统的软件设汁，通常包含硬件设计和软件设计两个方面，其中前端活动（例如，规格说明和系统架构）需要同时考虑硬件和软件两个方面。早期的嵌入式系统采用的设计方法是采用硬件优先的原则，首先设计硬件系统，然后，在平台上进行软件设计，即系统在一开始就被划分为软件和硬件两大部分，并且软件和硬件独立进行开发设计。硬件设计过程缺乏对软件架构和实现机制的全面了解，带有一定的盲目性，软硬件之间的交互受到很大限制，软硬件之间的相互性能影响也很难评估，这种方法有可能将硬件子系统的很多设计缺陷遗留到软件设计阶段由软件系统来弥补；同时，一旦系统测试阶段发现严重问题，需要对硬件进行修改时，整个设计流程
和设计周期会受到严重影响。该方法的软硬件设汁各自的设计空间局限性很大，很难对一个特定的应用进行性能综合优化，也很难以适应大规模、复杂的系统设计任务。
1 . 软 硬 件 协 同 设 计 方 法
随着嵌入式系统功能日益强大、复杂度日益提高，系统设计所涉及的问题越来越多,难度也越来越大。同时，软件和硬件时间的界限也变得十分模糊，不再是截然分开的两个概念， “软件硬化”和 “硬件软化”两种趋势同时存在，软件和硬件的相互影响和相互结合日趋紧密。因此，出现了软硬件协同设计的方法，即使用统一的方法和工具对软件和硬件进行描述、综合与验证，如图17-14所示。
协同设计是一种在设计的最初阶段就将软件与硬件两方面结合起来权衡功能的分配（哪些功能硬件实现、哪些功能软件实现），在软件与硬件的并行设计过程中实现软硬件的交互，以满足系统的功能与性能要求的设计方法。
它的一个最主要的优点就是，设计时充分考虑到了现有的软硬件资源情况,在软硬件功能的设计和仿真中，软硬件相互支持，在设计幵发的早期阶段，软硬件的互相结合可以及早地发现问题和解决问题，避免了开发后期反复修改带来的一系列问题，有利于降低系统成本，缩短开发周期。在协同设计过程中，对软硬件的划分要从系统的角度将软硬件完成的功能作均衡，以系统目标为设计标准，在系统的复杂度一定时，使软硬件结合达到更髙的性能。软硬件划分好以后，软件和硬件的设计一直是保持并行的，在设计过程中两者交织在一起，互相支持，互相提供幵发的平台。软硬件协同的方法可以使软件设计人员在硬件完成之前接触到硬件模块，从而更好地设计硬件的驱动、应用程序和操作系统等软件；同时，可以使硬件设计人员尽早接触软件，为软件设计人员提供高性能的硬件平台，减少了设计中的盲目性。
2 . 协 同 设 计 工 具
嵌入式系统的协同设计离不开统一的分析与设计工具的支持，目前，嵌入式系统的协同设计工具可以分为两类：协同合成工具和协同模拟工具。
主要的协同合成工具有P O L 1 S 、 C O S Y M A 和 Chinook 等，协同模拟工具有 P T O L E M Y 和 T S S 两种。在整个系统设计完成后，在统一框架下模拟不同种类的成分是必要的，协同模拟不仅进行功能检验，而且为用户提供各系统的性能信息，这有助于在系统的早期提出变更方案，不至于造成重大损失。
(1) P O L I S 。
P O L I S 是 U C - Berkeley 开发的交互式嵌入式系统的软硬件协同设计框架，它适用于小型控制系统的设计，系统描述支持基于有限状态机 （Finite State Machine ,F S M ) 的语言。由于软硬件均可透明地从同一协同设计有限状态机 （Codesign F S M ,C F S M ) 描述中取得，设计空间的灵活性也相应增加，支持使用 P T O L E M Y 语言的协同模拟，在描述及实现层均支持形式化验证。 P O L I S 主要关注高级语言的转换、规则检査和软硬件界面综合等技术，比较适合实时控制领域的嵌入式系统设计。
(2) C O S Y M A 。
C O S Y M A 是由德国 I D A 公司开发的一种探索硬件与软件协同设计综合进程的平台，它面向软件系统，支持自动分割和协同处理器综合，在综合时期可以对设计空间进行探索。系统综合取决于硬件限制，不支持并发模块，即一次只能有一个线程执行1 架构同样受限，不支持形式化验证，设计的成功与否取决于分割及幵销估计技术。 C O S Y M A 的主要缺点是处理器和协处理器不能并行工作。
(3) Chinook 。
Chinook 是为控制系统而设计的，整个系统的描述作为一个输入提供给 Chinook , 它的内部模式基于类似等级状态的模式，它不对代码进行分割，为整个设计提供单一的模拟环境。 C h i n o o k 支持多种系统架构，尤其是多处理器结构；支持定时限制的描述，能合成多种接口，包括系统之间的软硬件接口；能直接从定时图表中合成设备驱动器，可以控制处理器之间的通信。
(4) P T O L E M Y 。
P T O L E M Y 的关键思想是混合使用面向对象内核的计算模型，可用于模拟多种系统，在各种应用中被广泛使用，硬件模拟也是它的一项功能，但不适合于系统综合。
(5) T S S 。
系统模拟工具 （Tool for System Simulation , T S S ) 是模拟复杂硬件的工具，采用C 。 语言编写，单个模块的提取可由用户控制，可以方便地进行添加与删除模块。TSS 不支持分级模块，没有用于同步各处理器存取共亨数据结构的机制，模块间的通信通过端口和总线进行。TSS支持多核系统的模拟。
17.4.4 系统分析与设计
本节以一个多用途通用控制平台为例，对嵌入式系统的开发与设计过程进行描述。该平台是一个面向工业、企事业单位、生活社区和普通家庭用户，集成了移动通信、互联网技术、无线局域网和无线传感器网络等先进的网络技术，以及视频信息采集与处理技术的多用途控制平台。对于家庭用户来说，可以通过移动通信网络随时随地了解家中状况，吋以远程控制家里的电器设备，并且设备出现了故障或紧急情况，该通用控制平台可以主动地通过手.机或电话网通知用户或火警等相关部门。特别是出现火灾等极端状况时，控制平台吋以启动有关设备进行扑救，同时将相关数据和现场图像或视频资料发送出去，提供给救援人员参考，以便协助救援。对于企业用户，该系统可以设置在仓库、车间和实验室等地点，并且多个平台设备之间可以共享数据和相互协作。
1 . 需求分析
嵌入式系统一般都是面向产品开发的，对嵌入式系统进行需求分析是一项复杂而费时的工作。需求分析阶段最重要的成果之一就是系统规格说明书（不是软件需求规格说明书）。
对于不同的项曰，该文档形式可以灵活变化，但基本包含：
物理尺寸、操作环境、存放环境、指示灯装置、无线电标准、无线电功率和频率、数据传输率、存储器、平均无故障时间、功耗、电源适配器、散热、系统复位、协议等内容。
在进行需求分析时，可以采用UML 进行需求描述。有关这方面的详细知识，请阅读11.5节。 .
2 . 系统架构设计
嵌入式系统的架构由硬件架构和软件架构组成，随着嵌入式软件复杂度的日益提高，系统的响应速度（实时性）和可靠性等重要指标不再仅仅由硬件架构所决定，软件架构的影响也逐步增大。
描述系统如何实现规格说明中定义的功能是系统架构设计的主要目的。但是，在设计嵌入式系统的架构时，很难将软件和硬件完全分开。通常的处理方法是先考虑系统的软件架构，然后再考虑其硬件实现。
系统架构的描述必须符合功能上和非功能上的需求，不仅要体现所要求的功能，还要满足成本、速度和功耗等非功能约束。
软件架构的选择和设计很大程度上取决于嵌入式系统的架构，主要考虑以下几点因素： ’
( 1 ) 系统的实时性要求。
对于硬实时系统，必须进行严格的时序分析。
(2) 采用的设计模型。
对于简单的中小型嵌入式系统，可以采用“先硬件后软件”的方法；
对于复杂、大型嵌入式系统，必须采用软硬件协同设计的方法，还要充分考虑软件和硬件两个方面的互相制约和影响。
(3) 是否需要EOS 。
对于复杂的和口后需要继续开发和移植的系统，最好采用EOS
来增强系统的可扩展性。在所有满足系统功能和性能要求的方案中，应该优先选用最简单的架构。
3 . 硬 件 子 系 统 设 计
嵌入式系统的开发环境由4 个部分组成，分别是目标硬件平台、EOS 、编程语言和开发工具，其中处理器和操作系统的选择应当考虑更多的因素，避免错误的决策影响项目的进度。
嵌入式系统设计的主要挑战是如何使互相竞争的设计指标同时达到最佳化。
设计人员必须对各种处理器技术和IC技术的优缺点加以取舍。一般而言，处理器技术与技术无关，也就是说，任何处理器技术都可以使用任何1C 技术来实现，但是最终器件的性（ 能、一次性工程（Non-Recurring Engineering ，NRE ) 成本、功耗和大小等指标会有很大的差异。通用的可编程技术提供了较大的灵活性，降低了 NRE 成本，建立产品样机与上市的时间较快；定制的技术能够提供较低的功耗、较好的性能、更小的体积和大批量生产时的低成本。根据这些原则，设计人员便可以对采用的处理器技术和处理器做出合理选择。
一般地，全定制商用“通用处理器+软件”是大多数情况下都适用的一个选择。根据用户的需求和项目的需要，选择合适的通用嵌入式处理器，选择时需要考虑处理器的速度、技术指标、开发人员对处理器的熟悉程度、处理器的I/ /O 功能是否满足系统的需求、处理器的调试、处理器制造商的支持可信度和封装形式等指标。
在硬件子系统的设计中，首先，将硬件划分为部件（或模块），并绘制部件连接框图；其次，对每个部件进行细化，将系统分成更多个可管理的小块，可以被单独实现。通常，系统的某些功能既可用软件实现也可用硬件实现，没有一个统一的方法指导设计人员决定功能的软硬件分配，但是可以根据系统约束清单，在性能和成本之间进行权衡。嵌入式系统中接口电路的设计需要考虑的因素主要有电平匹配问题、驱动能力和干扰问题。设汁时需要注意I/ /O 端口、硬件寄存器、内存映射、硬件中断和存储器空间分配等方面。总之，硬件设计人员应该给软件设计人员更多、更详细的信息，便于进行软件设计和开发。
4 . 软 件 子 系 统 设 计
根据需求分析阶段的规格说明文档，确定系统计算模型，然后，对软件部分进行分析与设计。嵌入式系统的软件设计需要根据应用的实时性要求、应用场合、可用资源情况等诸多约束，进行合理的任务划分，这是嵌入式系统应用软件设计的关键所在，直接影响软件设计的质量。在实时系统中，一个应用系统通常由一系列的任务构成，每个任务完成一个独立的功能，这些任务互相协作来共同实现系统的整体功能。
首先，明确系统的实时性指标，究竟是软实时还是硬实时，最坏情况下的实时时限是多少等；然后，确定任务大体的数目。任务划分的力度和数目的合理性直接决定着调度幵销和任务之间通信开销，以及系统响应时间的重要决定因素，这需要充分考虑极端情况下的各种因素。实时系统的软件应该尽可能的简化，过于复杂的软件设计会增加系统的复杂性，从而降低可靠性。
接着，进行可调度性分析。对已经划分好的任务根据实现的功能特点进行分类，识别出具有硬实时性要求的所有关键任务，并给所有的任务赋予适当任务优先级，根据每个任务执行的时间估计值在考虑调度开销余量的条件下进行粗略的可调度性分析，从而确保所有关键任务都满足调度时限。根据分析结果再对所有的任务进行适当的分裂与重组。对于周期相同的所有任务的功能进行适当的组合形成一个单独的任务，以降低事件； 分发机制的开销：对于若干固定顺序执行的任务要合成一个单一任务，避免同步开销；将若千有相同的事件源触发的任务也合并成一个任务，以减小事件分发机制的开销；对于计算密集型或以数据处理为主而不进行I/ /O 操作的功能独立出来，由一个优先级的任务来实现；对任务之间的同步与互斥机制进行分析，尽量避免大粒度的互斥锁。
最后，在具体的实现上，根据系统特点确定任务的优先级，任务优先级分配的一般原则如下：
(1) 与中断的关联性。
凡是与中断服务程序相关联的任务应该安排尽量高的优先级，以保证及时处理异步事件，提高系统的实时响应能力。否则，CPU 可能被其他优先级高， 的任务长期占用，使得第二次中断发生时，上一次中断还没有处理，从而产生信号丢失，甚至是外部设备失败。
(2) 紧迫性。
越是紧迫的任务对响应时间的要求就越是严格，对于所有的紧迫任务，根据它们响应时间的先后顺序，安排优先级。
(3) 任务的频繁性。
对于周期性的任务，执行越频繁，则周期越短 ， 允许耽搁的时间也就越短，故相应的优先级也应该越卨，以保证处理的及时性。并且，任务的处理时间越短，优先级也应越髙。
(4) 传递性。
信息处理流程的前驱任务的优先级应该高于后继任务的优先级，例如，数据的采集任务优先级应该高于数据处理任务的优先级。
5. EOS 的选择
在选择 E O S 时，也需要做多方面的考虑：
( (1 ) E O S 的功能。
根据项 R 需要的 E O S 功能来选择 E O S 产品，要考虑系统支持 E O S
， 的全部功能还是部分功能，是否支持文件系统和人机界面，是实时系统还是分时系统，
以及系统是否可裁减等因素。
(2) 配套开发工具。
有些 R T O S 只支持该系统供应商的开发工具。也就是说，还必
须向 E O S 供应商获取编译器和调试器等；有些 E O S ， 使用广泛，且有第三方工具可用，
因此，选择的余地比较大。
(3) E O S 的可移植性。
E O S 到硬件的移植是一个重要的问题，是整个系统能否按期
完工的关键因素，因此，要选择那些可移植性程度高的 E O S , 从而避免 E O S 难以向硬
件移植而带来的种种困难，加速系统的幵发进度。
(4) EOS 的内存需求。
均衡考虑是否需要额外RAM或 或 EEPROM 来迎合EOS 对内
存的较大要求。有些EOS 对内存的要求是H 标相关的，例如，Tomado/ /VxWorks 等，开
发人员能按照应用需求分配所需的资源，而不是为EOS 分配资源。
(5) EOS 附加软件包^
EOS 是否包含所需的软件部件，例如，网络协议栈、文件系
统和各种常用外设的驱动等。
(6) EOS 的实时性如何。
有 些 EOS 只能提供软实时性能，对于需要达到硬实时性
能要求的系统就不适用；有呰EOS， 即可满足软实时要求，也能满足硬实时要求，例如，
MS Windows CE 2.0 等。
(7) EOS 的灵活性。
EOS 是否具有可剪裁性，即能否根据实际需要进行系统功能的剪裁。有些EOS 具有较强的可剪裁性，例如，嵌入式Linux和 和 ECos 等。
6 . 编程语言的选择
对于嵌入式系统编程语言的选择，需要考虑通用性、可移植性、执行效率和可维护性等方面。
(1) 通用性。
随着微处理器技术的不断发展，其功能越来越专用，种类越来越多，但不同种类的微处理器都有自己专用的汇编语言。这就为系统幵发人员设置了一个巨大的障碍，使系统编程更加困难，软件复用无法实现；而高级语言一般和具体机器的硬件结构联系较少，比较流行的高级语言对多数微处理器都有良好的支持，通用性较好。
(2) 可移植性。
由于汇编语言和具体的微处理器密切相关，为某个微处理器设计的程序不能直接移植到另一个不同种类的微处理器上使用，因此，讨移植性差；髙级语言。 对所有微处理器都是通用的，因此，程序可以在不同的微处理器上运行，可移植性较好。这是实现软件复用的基础。
(3) 执行效率。
一般来说，越是高级的语言，其编译器和开销就越大，应用程序也就越大、越慢。但单纯依靠低级语言（例如，汇编语言）来进行应用程序的开发，带来的问题是编程复杂、开发周期长。因此，存在一个开发时间和运行性能之间的权衡。
(4) 可维护性。
通常，低级语言程序的可维护性不卨。高级语言程序往往是模块化设计，各个模块之间的接口是固定的。因此，当系统出现问题时，可以很快地将问题定位到某个模块内，并尽快得到解决。另外，模块化设计也便于系统功能的扩展和升级。在嵌入式系统的分析与设计过程中，需要完成一系列的文档，例如，技术文件H、 录、技术任务书、技术方案报告、产品规格、技术条件、设计说明书、试验报告和总结报告等，这些文档对完成产品设计和维护相当重要，需要按照通用计算机系统开发的文档管理标准进行管理。有关软件文档管理方面的详细知识，将在20.10节 介绍。
17.4.5 低功耗设计
嵌入式系统通常都是一些移动设备，不能像通用计算机系统那样，长期插接供电电 源，因此，在进行嵌入式系统设计时，必须考虑其功耗问题。事实上，低功耗设计是嵌入式系统设计中的难点，是-个系统化的综合问题，必须从软件和硬件两个方面全面考虑，才能真正有效地降低功耗。
1 . 基于硬件的低功耗设计
对于常用的典型 C M O S 集成电路，其功耗由静态功耗、静态漏电流功耗、内部短路功耗和动态功耗组成。通常，在 C M O S 器件的整体功耗中，动态功耗大约占70%〜 90%，静态功耗与静态漏电流功耗一般不大于2 % , 内部短路功耗在10%〜 30%之间。从硬件方面降低器件工作时的功耗，主要从降低工作电压方面考虑。对于嵌入式系统设计人员来说，基于硬件的低功耗设计应该从如下几个方面考虑：
(1) 板级电路低功耗设计（整体）
板级电路的低功耗设计主要围绕处理器的低功耗特性和外围芯片的工作特点，设计处理器的供电电路和外围芯片的电源控制电路，处理器的供电设计允许改变其内核的输入电压，达到降低功耗的目的，外围芯片的电源控制则允许.处理器能够根据实际需要对工作空闲的外围芯片的电源幵启和关闭，从而降低其功耗。
(2) 选择低功耗处理器（CPU)
处理器是嵌入式系统不可缺少的核心部件，选择处理器时除了参考其功能、性能、接口和指令集等指标外，还应该考虑功耗特性，在满足正常工作的前提下，尽量选择低电压工作的处理器，或者选择可以动态调整电压和工作频率的处理器。对于同样核心的处理器或其他外围电路，应该选用制造工艺更先进的器件。
(3) 总线的低功耗设计(总线）
对于嵌入式系统来说，总线的宽度越宽，功耗就越大，在可能情况下，应该优先选用低功耗的总线器件，例如，低电压差分信号器件 （L o w VoltageDifferential Signal , L V D S ) 〇 L V D S 是一种小振幅差分信号技术，使用非常低的幅度信号通过一对差分信号传输数据，允许单个信道传输速率达到每秒数百兆位，因其特有的恒流源模式驱动，所以产生的噪音极低，功耗很小。随着 L V D S 器件信号速率的进一步提升，品种越来越丰富，在嵌入式系统设计中的应用也会越来越广泛。
(4) 接口驱动电路的设计（外设）
设计接口驱动电路时，要选用静态电流低的外围芯片，还要考虑上拉/下拉电阻的选取、悬空引脚的处理和缓冲器使用等。电阻大小应该仔细计算或采用模拟工具进行仿真，悬空的引脚应该接地或接电源。接口芯片驱动能力如果能够满足需要，尽量减少使用缓冲器。
(5) 分区分时供电技术（电源）
嵌入式处理器的工作电压与外围芯片的工作电压通常不一致，可以将它们分别划在不同的供电区域内，并且可以部分关闭空闲分区内的电源，来降低系统功耗。
2 . 基于软件的低功耗设计 （降低软件占用CPU的时间）
在嵌入式系统的设计过程中，通过软件的设计优化，可在一定程度上降低系统的功耗，主要的技术措施有如下几种：
(1) 编译优化技术。
对于实现同样的功能，不同实现算法所消耗的时间不同：使用的指令不同，消耗功率也不同。
编译器可以通过特定处理器单条指令的功耗基本开销、连续执行不同指令开销的估算模型进行优化。
(2) 软件与硬件的协同设计。
可以通过软件与硬件的功能再分配，将用硬件实现的功能由软件实现，从而减少硬件电路的规模，进而达到降低功耗的目的。
这需要将基于软件实现某种功能的所需要功耗与硬件电路实现同样功能产生的功耗进行对比，详细分析之后进行综合考虑。
(3) 算法优化。
对于软件实现的功能，应尽量采用时间复杂度低的算法，例如，快速傅立叶变换和快速排序算法等，来降低算法执行时间，从而将低功耗。
备注：
低功耗设计与实时性设计大多数时候是矛盾的。
低功耗会牺牲一部分的实时性，而实时性也会牺牲一部分的低功耗特性。
351
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
