应用开发人员不需要每次都对他们编写的一项应用进行重复的劳动。工具和应用开发架构已获得了长足的发展，以便于应用开发人员能够集中精力创造他们的附加价值，而不需要担心底层的应用架构和细节。那么嵌入式系统的开发是否也朝着同样的方向发展？
开发人员需要利用有限的时间和/或资源来创建硬件/软件解决方案，这是现实情况；开发人员应该将时间和精力集中在创造产品的附加价值方面，而不是底层的细节。

回顾过去的几年，嵌入式系统通常是由工程师自行利用汇编语言设计，并且在定制硬件上运行，不需要任何通信技术或安全架构。这些系统会像独立设备一样运行，在许多情况下甚至不用操作系统的支持；事实上，这些系统只会运行一个专用的单任务或进程(现在的设备当然也是如此)，开发人员将负责系统的每个方面、系统与底层硬件的互动以及用户的输入和输出（若有必要）。设备的每个方面都需要由开发人员进行编码。一般来说，应用开发人员必须非常熟悉底层硬件，而且 或许还曾经参与硬件的设计。

随着时间的推移，开发人员不再使用汇编语言自行设计操作系统程序，他们改用C/C++等高级语言或利用软件库开发字符串处理、文件I/O、图形、音频和视频等常用的软件。许多知名的软件开发工具都提供软件库以协助应用软件开发，如Borland OWL和Microsoft Foundation Classes (MFC) 就是应用开发软件库的很好例子，它们让开发人员摆脱操作系统API的纠缠，并且提供各种函式和类别来支持常见的程序设计工作。我们可以将这些软件库视为操作系统和应用软件之间的中介层，但在许多情况下应用开发人员仍然需要控制对象的生命周期、线程和内存管理。

许多应用开发软件库其实就是应用软件和底层操作系统之间的中介层，而许多软件库还提供源代码以方便设计人员了解软件库的工作方式，并通过检查源代码来确定软件库调用本地操作系统API的速度有多快。应用开发软件库提供源代码的另一优点是设计人员可借此扩大软件库功能。只要将应用开发和操作系统抽象模型往前推进一步，我们就能得到 (在多数情况下) 与操作系统和处理器无关的应用开发模型，Java和.NET就是很好的例子。在这个模型里，应用开发人员与底层操作系统的距离会更远，对象生命周期是由应用软件的运行时间环境(JVM或.NET运行时间)、类别、对象、事件，以及与底层操作系统API没有多大关系的方法来处理的。从C/C++转向管理应用开发将带来更多好处，这就像应用开发人员从汇编语言转到C/C++语言后，就能加快产品开发的脚步一样。
底层硬件的抽象化是将应用软件开发从汇编语言通过C/C++转换到管理应用开发环境的附带效果之一。应用开发人员多半不需知道硬件细节，硬件抽象层则可搭配设备驱动程序将应用软件与实际硬件隔开。例如，一个串行端口可能作为UART或FPGA来执行，但这些硬件的相关问题都由驱动程序负责处理，应用软件只需要使用串行端口即可，完全不需要知道它的硬件细节。图形、音频和许多其它外围设备也是如此。

但这与嵌入式操作系统的发展有什么关系呢？

嵌入式设备的开发人员可以选择所需的设备开发工具和操作系统。在选择硬件、操作系统 (如果需要)和应用开发工具时，需要进行一个平衡。相关因素可能很复杂，决策过程当然是以商业和技术考虑为主，但最后多半仍然以时间、资源和成本为重点。凡是能减少时间、资源或成本的做法对于您的应用开发计划都有好处。

您的嵌入式系统价值在哪里？是运行设备的用户界面、应用软件、程序或服务，还是为设备传送和接收数据的服务器？大家都知道研发人员应该将时间用于增加产品价值的应用软件和技术上，但线程管理、内存管理、网络堆栈、媒体播放器、网络浏览器和各种服务器技术该怎么办？这些技术通常是由操作系统提供，您的研发团队是否应以数月的宝贵时间开发出一套比市场上TCP/IP协议堆栈小5kb和快10%的TCP/IP协议堆栈？或是将时间用于更新操作系统的网络服务，以便符合最新的规格？

问题在于让您的研发团队将时间用于编写、开发、测试和维护操作系统层级的软件组件是不是一种好的做法？答案或许不是！

一个必须回答的问题是：“发展嵌入式系统时，我要将时间和资源用在什么地方？”这个看似简单的问题当然有很多答案。我们可以将时间用于硬件方面，或许为了您的嵌入式系统编写硬件抽象层代码（如果需要）、以构建操作系统基础架构代码和其它低水平的支持代码，或者您的团队也会将时间用于高水平、定制的最终用户体验方面，并将您的产品特定的知识产权添加到现有的操作系统中。

希望您能看到应用开发技术进步和嵌入式系统设计与发展方向之间的相似处。
有多种操作系统可以选择。或许您在使用几年前开发且在不断发展的自主开发的操作系统，或许您正在使用一个商用“台式”操作系统、一个商用嵌入式操作系统，或者在使用一个开放资源的操作系统。无论是哪种情况，您都要做出许多评估才能为您的嵌入式设备找出最合适的操作系统。评估内容包括程序大小、处理器支持、本地硬实时支持、硬件设备支持的范围 (或参考硬件)、源代码存取，以及是否有开发商和合作伙伴可以帮助您进行嵌入式系统的开发。

上市时间越来越重要；加快上市时间的方法之一是将时间用于提高设备的附加价值部份。但是操作系统要怎么办？嵌入式操作系统有各种不同的类型和大小，有些操作系统仅提供源代码，研发人员必须先建立一套工具链，然后才开始发展设备；还有些操作系统则提供完整的操作系统镜像文件，研发人员可直接开发应用软件。前者让您将宝贵的人力和时间浪费在操作系统和工具链的建立及配置，后者才能加快设备的开发和上市时间。

让我们分析两种选择，第一种是使用市场上销售的操作系统和现成的参考电路板(毕竟人们早就在发展以CPM/80、MS-DOS、OS/2和Windows 3.x到Windows XP为基础的嵌入式设备)。这种做法的优点是让您得到操作系统的所有功能，只需把您的应用、服务和驱动程序加在操作系统之上就算大功告成。这种做法的缺点同样是让您得到操作系统的所有功能，这表示您的操作系统会比您所需还要庞大，其中包含许多您的嵌入式系统不会用到的功能(媒体播放器、网络浏览器、网络功能等)，而且无法针对嵌入式系统应用进行定制(例如只能从只读媒体引导)。

第 二种选择是使用一个能够进行定制、可满足您的嵌入式设计需要的操作系统，您可把它称为一种组件化的操作系统。或许闪存引导能力、快速引导时间、支持多种处理器架构、本地硬实时支持和程序大小等对于您的设计都很重要。除此之外，还有许多其它理由让功能完整的台式操作系统或服务器市场专用的操作系统不适合您的嵌入式设备。或许能够提供设备相关功能的操作系统正是满足各种嵌入式系统市场需求的理想选择，微软的Windows CE和Windows XP Embedded就是组件化嵌入式操作系统的最好实例，它们可以通过所支持的处理器、硬件、实时、网络和媒体技术彼此互补搭配。

定制不表示您一定要花很多时间或克服许多困难才能完成操作系统配置以满足您的设备需求。典型的Windows XP Embedded设计从概念到交货通常仅需12-14周。

安 装Windows XP Professional SP2大约需要1.5GB的硬盘空间。这是因为Windows XP是一种通用台式操作系统，支持广泛的硬件设备（不是即插即用！）和 最 终用户应用软件。微软还为嵌入式系统提供专用的Windows XP Professional SP2操作系统，称为Windows XP E mbedded。这套组件化操作系 统大约能分割为12,000种软件组件、9,000个驱动程 序 以及3,000种系统功能。嵌入式系统开发人员 可选择嵌入式设备所需的个别组件或技术。通过这种方式，您不用安装整套操作系统就能得到网络、多媒体和安全功能的所有最新优点。

W indows XP Embedded和W indows XP Professional一样，都是使用以x86处理器和PC架构为基础的硬件电路。当然，它们引导媒体的要求完全不同。Windows XP Embedded可从网络(PXE引导t)、光盘(El-Torito)、闪存或硬盘进行引导。由 于操作系统已经组件化，您可以选择适当的程序大小来满足设备的需求。

广泛的硬件和软件支持是使用Windows XP Embedded操作系统的优点之一，只要操作系统镜像文件包含适当的操作系统依赖性，任何能在Windows XP上运行的驱动程序就能在Windows XP Embedded上运行。就此而言，依赖性是开发人员必须考虑的重要问题之一。
您在建立嵌入式操作系统镜像文件时或许已经知道您的用户界面、应用软件和服务都要依赖特定的操作系统功能，但增加这些功能和熟悉所有的操作依赖性却需要很长时间。Windows CE和Windows XP Embedded所提供的工具都包含许多操作系统功能(称为组件)，这些组件含有所需的依赖性信息。例如，假设您正在使用Windows CE，并想把80kb左右的HTTP Web Server加入操作系统。您只要从组件目录把这个组件加入到您的工作区 (workspace)，该组件的依赖性信息也会自动地进行添加。

使用组件、依赖性和操作系统配置模板就能迅速完成嵌入式操作系统的配置和测试。例如以x86为基础的参考电路板可在30分钟内完成Windows XP Embedded操作系统的配置、构建和引导。Windows CE Emulator或相关BSP所提供的Windows CE 5.0操作系统也能在30分钟内完成配置、构建和引导。

我们看到应用开发人员可以通过各种应用开发工具和架构加速产品上市的时间，使用组件化的嵌入式操作系统也能将产品更快地推出。以小观大，设计人员只要把最新的应用开发工具和程序架构以及最新的组件化嵌入式操作系统融为一体，必定能够发挥出惊人的威力！