开发人员需要利用有限的时间和/或资源来创建硬件/软件解决方案，这是存在的情况；开发人员应该将时间和精力集中在创造产品的附加价值方面，而不是底层的细节。 

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

　　随着时间的推移，开发人员不再使用汇编语言自行设计操作系统程序，他们改用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协议堆栈？或是将时间用于更新操作系统的网络服务，以便符合最新的规格？ 

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

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

　　希望您能看到应用开发技术进步和嵌入式系统设计与发展方向之间的相似处。 

　　有多种操作系统可以选择。或许您在使用几年前开发且在不断发展的自主开发的操作系统，或许您正在使用一个商用“台式”操作系统、一个商用嵌入式操作系统，或者在使用一个开放资源的操作系统。无论是哪种情况，您都要做出许多评估才能为您的嵌入式设备找出最合适的操作系统。评估内容包括程序大小、处理器支持、本地硬实时支持、硬件设备支持的范围  ......

>>返回讨论的主题