避免MCU、内核或编程语言干扰设计

很多时候有人试图让你信服：他们的“东西”或最新的产品将成为或取代你的下一个产品设计。这是真的，每天我们都在采用零星的技巧来改进嵌入式设计，有些改进确实是挑战，但是，如果不从可靠的、独特的设计开始，没有“新的技术”，产品不会成功。摆在我们面前的问题是，设计需要时间，时间是一种易消逝的资源，并且，所有这些新事物、新设备、新工具很重要，但并不是最重要的事情。需要防漏洞实时操作系统吗?需要更快的CPU内核吗?微控制器中需要更密集集成的外围设备吗?把这些问题找出来，找到答案并为之利用，但要知道“IT”不是设计的关键。关键是设计成仿佛你想要的一切已经存在，完全取决于您的意愿，使您的产品、系统按照您的需求、期望、要求精密“包装”，定义接口。按照您想要的方式，用layers和wrappers构建设计，你会发现，采用最新的最好的事情，会使产品更高端，更快速，更便宜，更强大或者说随处满足需求，可以在以后出现在您的后期设计时，甚至出现在生产线上。

该观点还在不断继续：

● 此类或那类嵌入式设计采用哪种CPU内核最好?

● 开发嵌入式系统采用什么语言最好?哪个编译器?

● 对于简单的主循环和中断实时操作系统，应该购买，自己编写还是避开“操作系统”?

作为经验丰富的嵌入式系统的开发人员，既有大型系统的经验(波音777飞行控制)又有小型单人项目(笔记本电脑热风扇控制)经验，应避开单台机器或语言的具体利弊，将更多的时间花在应用程序设计和构建上，并且独立于语言和CPU内核。这方面部分来自于对类似系统的工作，只是“再用于“下一个项目(虽然要求完全不同，并且切换到了微控制器)。我也参与过由几个独立的设备组成的系统，每个设备都有自己的程序和微控制器，各部分经常在不同的子项目之间来回使用：某个子项目中的编码器可能是另一个项目的测试器，或当完成自己的子项目的编码后，会投入另一个子项目，以帮助完成项目。缺乏基于系统的设计方法会觉得这些情况很困难，难以按照计划完成。通过独立的系统设计可避免机器依赖性，让设计复用和基于团队的设计不仅成为可能，而且加大了成功机会(如以后的增加要求)。

最近的一个项目是我更加疑虑，几乎每次都是，必须使设计适应(有时根本就是)所选的语言和机器。我们已经以某个系统架构和设计开始，只是按一般方式考虑了集成微控制器及其外围设备，我们只关注我们需要什么并不关心它是如何实现的，至少我们是这么认为的。我们选择了一些非常专业外设的新器件，并且开始编码时，发现需要花费大量的时间来了解如何构建硬件，以及如何根据需求最好地利用。当我们发现好的方式来利用设备的某特征时，设备的此特点通过代码嵌入了系统级设计。我们已不再坚持我们的系统，不得不让机器和具体操作改变了系统设计。于是只好停下来检查问题和实施方案，通过系统重新设计分离出依赖机器的“修复”，然后将“修复”融入系统四周的“包装”中。

当设计某个应用时(甚至单一微控制器)，以调温器为例，有一个创建好了的系统级视图，描述了硬件和实施某种方式的应用程序。该视图用于多种用途，例如，可作为与高层管理人员或另一个小组进行交流的工具(不希望知道所有细节)，如自动化测试人员。如果仅将其视为“视图”而不是系统设计，并且实施不是从系统设计自上而下，而是将其用作起点，则问题就出现了。考虑图1所示的温控系统。

显示系统相对简单，却反映了许多嵌入式产品设计。在“温度传感”部分包含温度输入，其输出进入主系统“控制逻辑”部分。“控制逻辑”的其它输入是标记“用户输入”的部分，代表人机接口，大概设置了恒温器的温度调节。“控制逻辑”部分根据这些输入确定了如何命令供暖、通风和空调(HVAC)系统，以保持恒温器设定的温度，将这些命令发送到“热与冷命令”部分。最后一个部分是“显示输出”，将当前系统状态传递到用户。当前系统状态的一部分是恒温设置，另一部分是最新的温度读数，最后部分是正在执行的命令，以迫使温度返回恒温设置(即加热、冷却和/或打开或关闭风扇)。

正如前面所述，这是一个直接和相对简单的应用，非常简单以至于不需要考虑系统，而是很自然地跳到实施(我相信大多数读者甚至可以说出最喜欢的微控制器供应商的型号)。可以是用于次级市场的高端PC游戏图形系统的墙恒温器或温度管理装置。