避免MCU或编程语言的干扰设计

1、避免mcu或编程语言的干扰设计无数时候有人试图让你信服：他们的“东西”或最新的产品将成为或取代你的下一个产品设计。这是真的，天天我们都在采纳零星的技巧来改进设计，有些改进的确是挑战，但是，假如不从牢靠的、独特的设计开头，没有“新的技术”，产品不会胜利。摆在我们面前的问题是，设计需要时光，时光是一种易消失的资源，并且，全部这些新事物、新设备、新工具很重要，但并不是最重要的事情。需要防漏洞实时操作系统吗?需要更快的cpu内核吗?微控制器中需要更密集集成的外围设备吗?把这些问题找出来，找到答案并为之利用，但要知道“it”不是设计的关键。关键是设计成宛然你想要的一切已经存在，彻低取决于您的意愿，使您的

2、产品、系统根据您的需求、期望、要求精密“包装”，定义接口。根据您想要的方式，用layers和wrappers构建设计，你会发觉，采纳最新的最好的事情，会使产品更高端，更迅速，更廉价，更强大或者说随处满足需求，可以在以后浮现在您的后期设计时，甚至浮现在生产线上。该观点还在不断继续：此类或那类嵌入式设计采纳哪种cpu内核最好?开发嵌入式系统采纳什么语言最好?哪个编译器?对于容易的主循环和中断实时操作系统，应当购买，自己编写还是避免“操作系统”?作为阅历丰盛的嵌入式系统的开发人员，既有大型系统的阅历(波音777飞翔控制)又有小型单人项目(笔记本电脑热风扇控制)阅历，应避免单台机器或语言的详细利弊，将

3、更多的时光花在应用程序设计和构建上，并且自立于语言和cpu内核。这方面部分来自于对类似系统的工作，只是“再用于“下一个项目(虽然要求彻低不同，并且切换到了微控制器)。我也参加过由几个自立的设备组成的系统，每个设备都有自己的程序和微控制器，各部分常常在不同的子项目之间往返用法：某个子项目中的可能是另一个项目的测试器，或当完成自己的子项目的编码后，会投入另一个子项目，以协助完成项目。缺乏基于系统的设计办法会觉得这些状况很困难，难以根据方案完成。通过自立的系统设计可避开机器依靠性，让设计复用和基于团队的设计不仅成为可能，而且加大了胜利机会(如以后的增强要求)。最近的一个项目是我越发疑虑，几乎每次都是

4、，必需使设计适应(有时根本就是)所选的语言和机器。我们已经以某个系统架构和设计开头，只是按普通方式考虑了集成微控制器及其外围设备，我们只关注我们需要什么并不关怀它是如何实现的，起码我们是这么认为的。我们挑选了一些十分专业外设的新器件，并且开头编码时，发觉需要花费大量的时光来了解如何构建硬件，以及如何按照需求最好地利用。当我们发觉好的方式来利用设备的某特征时，设备的此特点通过代码嵌入了系统级设计。我们已不再坚持我们的系统，不得不让机器和详细操作转变了系统设计。于是只好停下来检查问题和实施计划，通过系统重新设计分别出依靠机器的“修复”，然后将“修复”融入系统四面的“包装”中。当设计某个应用时(甚至

5、单一微控制器)，以调温器为例，有一个创建好了的系统级视图，描述了硬件和实施某种方式的应用程序。该视图用于多种用途，例如，可作为与高层管理人员或另一个小组举行沟通的工具(不希翼知道全部详情)，如测试人员。假如仅将其视为“视图”而不是系统设计，并且实施不是从系统设计自上而下，而是将其用作起点，则问题就浮现了。考虑图1所示的温控系统。显示系统相对容易，却反映了许多嵌入式产品设计。在“温度传感”部分包含温度输入，其输出进入主系统“控制规律”部分。“控制规律”的其它输入是标志“用户输入”的部分，代表人机接口，也许设置了恒温器的温度调整。“控制规律”部分按照这些输入确定了如何指令供暖、通风和空调(hvac

6、)系统，以保持恒温器设定的温度，将这些指令发送到“热与冷指令”部分。最后一个部分是“显示输出”，将当前系统状态传递到用户。当前系统状态的一部分是恒温设置，另一部分是最新的温度读数，最后部分是正在执行的指令，以迫使温度返回恒温设置(即加热、冷却和/或打开或关闭风扇)。正如前面所述，这是一个挺直和相对容易的应用，十分容易以至于不需要考虑系统，而是很自然地跳到实施(我信任大多数读者甚至可以说出最喜爱的微控制器供给商的型号)。可以是用于次级市场的高端pc嬉戏图形系统的墙恒温器或温度管理装置。用于墙恒温器的微控制器的详细实施基本不需用于图形系统。重点是，无论设计显得多么容易，都有很好的理由先设计系统，然

7、后实现它。将其尽量设计成适合通常应用。开头时，需要考虑抱负的系统设计，然后生成layers，在抱负的系统和实际实施之间构建wrappers(有时是杂乱的)。“控制规律”部分作为框图的核心是有充分理由的-由于它是系统的内核。周围的每个部分都服务于“控制规律”部分，要按照需要提供“服务”。应自“温度”部分开头。其理由是获得当前/瞬时温度，并以全都的格式提供出来。从“控制规律”的角度来看，其作用是“猎取温度”，并以格式化的值(xxx.xx摄氏度)返回当前温度值。部分的硬件wrappers将包括实施中任何需要用来将原温度传感输入“翻译”成预期格式的摄氏度。这可能意味着需要考虑获得新读数的最佳时光，假如

8、温度读数中有太多的噪音(无论何种缘由)，应添加过滤算法，并且假如温度硬件浮现故障，应采纳决策规律。重点是，“温度传感器”部分的输出是什么，而且传递到“控制规律”应为抱负的温度，全部的噪音，实际躲藏的详情都应很简单的由wrapper代替。假如设计需要从系统中三个不同的点测量三个温度值(对于计算机箱内的计算机很普遍)怎么办?处理这三个温度是控制规律问题(例如，何时多路输出也将受到控制)?假如是这样，从1个温度转换到3个温度首先意味着“温度传感器”部分要更新，以提供3个温度和为每个温度实施创建的wrappers(允许多种类型的输入)，然后控制规律也由于多个输出而更新。这可能意味着三个不同的“gett

9、emperature_n”服务或需要更新服务以确定是识别哪个温度的参量。假如三个温度仅仅用于加权以得到一个“更真切”的系统温度，控制规律不需要转变，只需将含wrappers的温度传感块以统一格式输入这三个温度，然后通过一个wrappers来对这三个温度举行加权，生成控制规律所需的单一温度。这种办法易于包含来自不同的温度输入(例如，图形处理器的结测量和衔接到的模拟热敏)，由于wrappers将系统规律与硬件隔离开。让我们以两个不同的实现例子验证这个论点：一个用于墙恒温器，另一个是显卡上的温度控制子系统。首先对于墙恒温器，2所示，假定用法基于8051的p3设备。“温度传感器”部分的硬件由衔接到(1

10、6位-转换器)的热敏电阻组成。“用户输入”部分的硬件由5个常开按键开关组成，一边衔接到接地端，另一边衔接到含内部上拉电阻的5输入数字端口。“热和冷指令”模块的硬件部分包括三个功率，由配置为开漏低输出的3输出端口驱动。最后，“显示输出”块的硬件实现是串行字符液晶，能够按照需要显示字母数字字符串。对于第2个应用，即显示卡，将用户输入从离散开关变为i2c基于寄存器的从接口(由主cpu而不是人类挺直控制)，并将串行显示变为spi-从控制显示器(用法一系列的寄存器和命令，可能是安装在主计算机外壳前面板上的远程变频显示，未安装到显卡上)。温度输入和hvac指令保持不变。图3显示了早期实施的变幻，假定用法基于8051的赛普拉斯3设备。用户输入的两种实现均可服务于“getthermostatsetting”、“isheaterenabled”、“iscoolerenabled”和“isfanon”。对于第一个墙恒温器应用，“用户输入”将数字端口包装到所列的服务中，当设备被调用时，提供端口的