别让MCU、内核或编程语言干扰设计

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

该观点还在不断继续:  

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

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

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

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

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

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


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

正如前面所述,这是一个直接和相对简单的应用,非常简单以至于不需要考虑系统,而是很自然地跳到实施(我相信大多数读者甚至可以说出最喜欢的微控制器供应商的型号)。可以是用于次级市场的高端PC游戏图形系统的墙恒温器或温度管理装置。用于墙恒温器的微控制器的具体实施基本不需用于图形系统。重点是,无论设计显得多么简单,都有很好的理由先设计系统,然后实现它。将其尽量设计成适合通常应用。  

开始时,需要考虑理想的系统设计,然后生成layers,在理想的系统和实际实施之间构建wrappers(有时是杂乱的)。“控制逻辑”部分作为框图的核心是有充分理由的-因为它是系统的内核。周围的每个部分都服务于“控制逻辑”部分,要根据需要提供“服务”。  

应自“温度传感器”部分开始。其理由是获得当前/瞬时温度,并以一致的格式提供出来。从“控制逻辑”的角度来看,其作用是“获取温度”,并以格式化的值(xxx.xx摄氏度)返回当前温度值。温度传感器部分的硬件wrappers将包括实施中任何需要用来将原温度传感输入“翻译”成预期格式的摄氏度。这可能意味着需要考虑获得新读数的最佳时间,如果温度读数中有太多的噪音(无论何种原因),应添加过滤算法,并且如果温度硬件出现故障,应采用决策逻辑。重点是,“温度传感器”部分的输出是什么,而且传递到“控制逻辑”应为理想的温度,所有的噪音,实际隐藏的细节都应很容易的由wrapper代替。  

如果设计需要从系统中三个不同的点测量三个温度值(对于计算机箱内的计算机很普遍)怎么办?处理这三个温度是控制逻辑问题(例如,何时多路输出也将受到控制)?如果是这样,从1个温度转换到3个温度首先意味着“温度传感器”部分要更新,以提供3个温度和为每个温度实施创建的wrappers(允许多种类型的输入),然后控制逻辑也因为多个输出而更新。这可能意味着三个不同的“GetTemperature_n”服务或需要更新服务以确定是识别哪个温度的参量。  

如果三个温度仅仅用于加权以得到一个“更真实”的系统温度,控制逻辑不需要改变,只需将含wrappers的温度传感块以统一格式输入这三个温度,然后通过一个wrappers来对这三个温度进行加权,生成控制逻辑所需的单一温度。这种方法易于包含来自不同的温度输入(例如,图形处理器的二极管结测量和连接到PCB的模拟热敏电阻),因为wrappers将系统逻辑与硬件隔离开。  

让我们以两个不同的实现例子验证这个论点:一个用于墙恒温器,另一个是显卡上的温度控制子系统。首先对于墙恒温器,如图2所示,假定使用基于8051的赛普拉斯PSoC3设备。“温度传感器”部分的硬件由连接到ADC(16位Δ-Σ转换器)的热敏电阻组成。“用户输入”部分的硬件由5个常开按键开关组成,一边连接到电路接地端,另一边连接到含内部上拉电阻的5输入数字端口。“热和冷命令”模块的硬件部分包括三个功率场效应管,由配置为开漏低输出的3输出端口驱动。最后,“显示输出”块的硬件实现是串行字符液晶显示器,能够根据需要显示字母数字字符串。  


  
对于第2个应用,即显示卡,将用户输入从离散开关变为I2C基于寄存器的从接口(由主CPU而不是人类直接控制),并将串行LCD显示变为SPI-从控制显示器(使用一系列的寄存器和指令,可能是安装在主计算机外壳前面板上的远程变频显示,未安装到显卡上)。温度输入和HVAC命令保持不变。图3显示了早期实施的变化,假定使用基于8051的赛普拉斯PSoC3设备。  


  
用户输入的两种实现均可服务于“GetThermostatSetting”、“IsHeaterEnabled”、“IsCoolerEnabled”和“IsFanOn”。对于第一个墙恒温器应用,“用户输入”将数字端口包装到所列的服务中,当设备被调用时,提供端口的实时读数(一种可能的实施)。对于另一个应用,基于I2C从机的实现,相同的服务将来自I2C主机写入的寄存器的最新值返回到“控制逻辑”部分,也许经常返回也许仅在上电时返回。并且这些实现还有很多其它特点,包括用作切换键的墙上按钮开关而不是瞬间读数,甚至在“用户输入”部分的wrappers深层进行边沿触发异步处理。  

综合上述的关键是:系统设计隐藏了硬件细节;硬件和实施细节被系统设计包装并隐藏。通过外端设计(即代码)的实施细节,可以保护这些应用实现时避免分裂,可以做到个性化的设计,权衡利弊,保证项目成功交付,并仍然能够提供可复用性和组设计。不要让卖方牵引注意力——先设计系统,然后加强保护系统设计实现细节不被抄袭。
本文地址:https://www.eechina.com/thread-22457-1-1.html     【打印本页】

本站部分文章为转载或网友发布,目的在于传递和分享信息,并不代表本网赞同其观点和对其真实性负责;文章版权归原作者及原出处所有,如涉及作品内容、版权和其它问题,我们将根据著作权人的要求,第一时间更正或删除。
您需要登录后才可以发表评论 登录 | 立即注册

厂商推荐

相关视频

关于我们  -  服务条款  -  使用指南  -  站点地图  -  友情链接  -  联系我们
电子工程网 © 版权所有   京ICP备16069177号 | 京公网安备11010502021702
快速回复 返回顶部 返回列表