嵌入式有什么不同吗？一个转行去做嵌入式的设计师的经验之谈

　　在以往的岗位我已经估计到这种分歧，就是嵌入式系统的发展相对于应用系统的发展是不怎么受关注度的，而且作为一项产业，由于缺乏明确的目标，我们正在付出一个日益明显的代价。当在多年前我转到嵌入式系统领域里我自己已经了解了一些这两种发展形式之间的不同点。

　　我没想到大部分这些差异已作为一个公众话题，直到有人问我，为什么越来越多的嵌入式开发人员是不出席多核会议。这个问题使我认识到，在多核或多处理器方面至少有两种非常不同的观点，这种情况意味着对这些人们对嵌入式系统所起的兴趣和我在多核会议上看到的主要焦点（将来的话题）是不一样的 。
　　
　　当我知道这些不相关的言论而不是说几十年的机遇后我不得不指出这些不同的需求，大学课程仍然没有为嵌入式系统设计者们准备充分的课程。对我来说尽管这个转折点是通过对嵌入式系统开发者的几年的调查，更好的调试工具仍然是这些调查中的焦虑点，而且看起来没有人知道为什么，我嗅到了这种分离。

　　我将把我的转行的经验作为一个起点渗入到嵌入式世界里，来使嵌入式软件开发者的需求变得更加明显。我其中一个目标是请你回想你是怎样进入嵌入式设计世界且又不得不深入进去的。我正在写一篇９月４日发表的文章，我希望能指出这是怎么回事以及满足嵌入式系统设计者的需求的系统调试工具是怎样的。我想请您分享您的任何深刻的见解，您可以在这里留言或者发电子邮件给我。这是一个机会，我们可以得到一些调查结果而且这些调查能使工具开发者获得这些另一层面的信息可以更好的帮助你

　　在我如何看待软件和硬件方面，对嵌入式设计的这种过渡是需要有更深刻的变化的。在产生这种过渡之前，我已经在给多种平台形式开发软件方面有了十年的经验。上至分时中央处理器下至8-bit 计算机。我开发了汇编语言、编译语言、操作系统、解释程序、数据库引擎、自动操作工具、甚至电脑游戏。事后，对所有这些软件的一个普遍的描述是它是一个应用系统或者最终产品软件，所有的软件使用者都是一些直接或间接的接口了解并使用软件的。

　　首要的事情之一是我不得不使其内化，向嵌入式系统设计的过渡是我的软件在最终的系统中是隐藏的。最终用户不知道这是他们比有以往任何时候都需要的。我相信这是嵌入式系统的一个必不可少的组成部分。我的价值和我的能力告诉人们我对生活方式所做的是有着深渊的意义的。我笑对这样的哲学"当你不得不要过分简单化的向普通人描述你的工作时你知道你是一个嵌入式系统设计者"。我发现自己只是告诉别人我在为航天飞机或飞机工作，因为试图去解释系统中看不到那部分给别人实在是太令人泄气了，事实上我就工作在系统的这些类型的系统。

　　在系统中隐藏的部分工作在设计限制方面有深刻的重要性，因为去获得最终客户的奖励是很困难的，他们看不到你，但是它所从事的是必须要求产品能够做到的。我相信这是一个为什么嵌入式系统做的尽可能的便宜的根本原因。便宜而且小的执行机构是肯定不能被嵌入的，事实上你也不能从它更便宜的需求之外取得额外的收入。

　　另一个直接的不同点是我必须学习真实世界的错误。在公开的世界里，错误是相当简单的－－－你写代码对API或者是一个逻辑注册或者一个成功操作的不相关的指示表示疑问。为了那么多的嵌入式设计者，我必须学会对无把握的、莫能两可的、非线性的、和如何去应用多种过滤形式去解决这些设计挑战。在闭环控制系统中，正确的和不正确的运作并非总是轻而易举或显而易见的被辨明。

　　作为一个例子，我在抛弃为自治手段做雏形研究上花费了一年的大部分时间，当我们运行一个测试，它经常花另外一周的时间或者做更密集的数据分析报告在这个工作上，来确定如果这种手段表现为为了恰当的原因做校正。研究这个综合系统是不充足的因为在大量生产形式中将没有可见的人工干涉去帮助系统解决这些莫能两可和不确定。数据分析报告的选择工具是一个电子制表软件程序外加本国制造系统软件模拟器。

　　我相信这方面的经验开始针对一个可能的原因进行发言，这个原因就是嵌入式设计者不断要求更好的调试工具。同时，更好更快的目标处理器的软件模拟器是值得拥有的，在一个输出影响输入的系统里取得并形象化这个复杂的关系是完全不够的，例如在闭环控制系统。因为我们没有这样的工具，除了那些我们为我们自己建制的，我们测试了迭代逼近开环数据，如果我们足够幸运有预算和时间，我们建设闭环硬件模拟器。我期望这种情况今天仍然十分普遍。

　　我猜想"更好的调试工具" ，不仅意味着对于中央处理器资源的更好的能见度，但是更好的可视性和整个系统可视化，尤其是现实世界的界面，如漂移、迟滞、坚持的价值观、和非线性反应。这使我或许是过渡到我的嵌入式设计最深刻的转移。

　　当我第一次开始做嵌入式设计工作，我们总是碰到设计问题。即使我相当负责的按照说明书去做的软件，几乎每一个单独的设计问题都作为软件错误来标示。首先，带给我无尽烦恼的是因为大部分问题的源头是在性质上更明确的硬件。在我过渡带最后，我把下述的哲学进行了完满的转换：如果该软件能够侦测、补偿、避免、或纠正一个在这个系统中不规则的条件，这是根据定义，一个软件的问题，不管根源。在长远来说，对于大多数类别的问题，在软件里修复比在硬件里修复要便宜很多。

　　这种做法使调试软件的任务混乱，因为它需要跨学科的技能，熟练于设计师或跨学科合作和软硬件开发者之间，它通常在最终系统或者应用软件开发方面是不必要的。在我进入嵌入式开发世界之前，我从不使用电路内模拟器、逻辑笔、或者示波器。这些对于嵌入式设计是有价值的工具，但是他们对于软件调试工具是独立的。所以除了具有跨学科的问题外，调试嵌入式设计包括协调不能彼此很好的结合的工具混杂物。

　　我希望分享我的经验能引发你的一些思考，你可以选择在这里和大家分享你的想法也可以发电子邮件告诉我。进一步而言我遵循着这个理论的思路，我更确信我们是间接的选择了这些嵌入式开发者的需要，但是相反的，我们间接的选择了那些直接选择应用开发者们的需求的人们。遗憾的是，嵌入式系统开发包括一个额外的跨学科问题的层级，已经超越了软件调试。帮助我帮你分享你的关于在今天的嵌入式工具里丢失的东西的烦恼。我猜想当足够多的人回答的话这些模式将会变得明显。

　　如上所述，我正在写九月发表的关于嵌入式调试的文章，我希望可以您能偶尔发现的问题。为了09年的文章我也计划了一个亲手实践的项目，这篇文章将解决在软件领域的这中质疑去与中央处理器风格做区别。我猜想这两篇文章使你的意见更具影响力将是一个机会。

译者：郭郭