要点
* 嵌入系统的工程不仅是要使它们实现某些性能，而且还要防止它们表示出不需要的性能。
* 设计者可能会用调试工具作为设计辅助方法，因为没有更好的方式完成任务。
* 嵌入系统的调试是一个跨学科的活动，跨越了硬件、软件和领域知识的界限。
《嵌入系统设计》每年都有针对嵌入系统开发人员的年度市场调查，其中对设计活动的改进要求最多的一个领域就是调试工具（参考文献1）。在为期三年的调查中，有这种要求的受访者百分比一直稳定在大约32%。与之相比，寻求改进编程工具的受访者比例则从高达25%下降到10%。为什么现代调试工具未能像软件编程工具一样做得那么好，这是值得探讨的问题，尤其是每年的调查亦证实，测试与调试阶段仍是项目计划中耗时最多的部分，达24%。在全部三年的调查中，居第三位的改进要求是进度安排的项目管理功能（见附文“COCOMO与基于事实的进度安排”）。
工程的一个明确方向是针对某个问题，建立能完成和提交一个实用方案的系统。软件编程工具注重于软件工程的创建方面。调查结果表明，在提高创建能解决问题代码的生产率方面，编程工具走对了路。而调试工具的百分比没有随编程工具呈下降趋势成为一个主要的问题，这表明软件调试工具不只是编程工具的扩展，不只是用于帮助工程师改正错误或不正确的编码。
关于工程有一种不太清晰，几乎是隐含的问题，即设计者不仅要设计出能完成所需功能的系统，而且还要消除或减轻环境不确定性和可变性可能带来的不良状态，因此系统要在各种工作条件下保持一致的性能。工程的这个隐秘一面可能揭示了软件调试工具所面临的挑战，尤其是对嵌入系统设计者。除了要应对处理器架构对性能、功能、通信、延迟和功耗的实际约束以外，嵌入系统一般还要处理与真实世界的接口，这些接口展现的行为更难以对整个使用场景作出预测或特性描述。
如果调试只涉及寻找和改正软件的逻辑错误，那么一个指令集仿真器与周期精确的仿真器相结合，就能为嵌入系统行为提供足够的可见度，支持调试工作。很多处理器架构和软件开发工具套件都已有了这类仿真器。仿真器还可以使系统停止运行，以便检查仿真系统的任何部分。遗憾的是，这些类型仿真器一般不能对内存、总线架构、外设、传感器和促动器之间的精确交互与延迟提供完整的可见性，并会使仿真器运行得更慢。
系统级仿真器有能力超越软件执行引擎，仿真系统其它部分的相互作用，如Vast公司的虚拟系统原型工具和Virtutech公司的Simics虚拟平台。这些类型的开发工具使软件开发人员能够在物理硬件可用以前就在目标产品上工作；它们还通过系统级故障注入以及与其它开发活动的并行增量整合，帮助开发人员完成系统集成和测试工作。对于复杂的高端系统，这些类型的系统可以用作先期工具，或支持硬件在环仿真。这些工具支持预建的系统，并将预建的部件或块装配成一个系统。通过附加工具，它们还提供建立新部件并集成到系统中的能力。
系统级仿真要面临的一个障碍是成本，它的价格可能会比现有针对处理器的仿真器高出数千美元。在调查中，调试工具没有跟随编程工具的下降趋势，可能并非因为它们不能满足嵌入系统设计者的功能需求，而是因为具备所需功能支持的高端调试工具价格仍然超出了某些关键性的门限。有意思的是，这个价格门限低于硬件设计工具，尽管多数软件开发工具似乎支持在新系统中增加更多的复杂内容。
过去十年来，基于专利金的操作系统与开发工具许可模型已受到严重侵蚀。Linux作为一种嵌入系统操作系统日益成功，这主要源于开源软件的价格优势。另外，芯片供应商的很多嵌入系统工具都采用开源Eclipse平台管理自己的开发工具，显著降低了建立这些工具的成本，简化了最终用户对工具的配置，使他们在工作中专注于工具特性，而不是主控环境的观感。这种说法并非表明调试工具不会在定价方面追随相同的下跌趋势。极端来说，很多处理供应商都提供小型评估套件，开发者花不到100美元就能对系统作实验。事实上你会发现，今天很多数百美元开发套件包含的功能在十年前只出现在贵得多的工具中。 |
