<listing id="62mou"><object id="62mou"></object></listing>
    <output id="62mou"><pre id="62mou"><dd id="62mou"></dd></pre></output>
  1. 新闻中心

    EEPW首页 > 牛人业话 > 合理设置MCU滴答 千万不要累着它

    合理设置MCU滴答 千万不要累着它

    作者:光华居士时间:2018-08-29来源:电子产品世界收藏

    2017年盛?#27169;?#21271;京?#28382;罰?#26228;空万里,无风。

    本文引用地址:http://www.09140960.com/article/201808/391345.htm

    近乎凝滞的空气中一点风都没有,恼人的知了无停无休地叫着,不疲也不厌,让人很是怀疑它们的?#26377;摹?#34987;太阳晒得发焦的柏油路面热气腾腾,像被晒干了肚皮的鱼儿一样无声地嘶嚎着。呼啸而过的汽车排着滚烫的尾气,急匆匆地想要逃离这个世界,偶尔响起的一声喇叭,就像向太阳求饶一般。地铁站和周围的建筑被晒得无精打采的,无可奈何地矗立在似火骄阳的暴晒之下。刚从地铁站出来的人们行色匆匆,难得悠?#20889;?#23481;的面孔,笔者被裹挟在滚滚人流之中,不由自主地加快着脚步。站在十字路口,一?#26194;?#28909;?#20284;?#38754;而来,我顶着发烫的头皮,在心中一片哀?#29275;?#21271;京真热啊!”

    笔者这次顶着大热天来帝都,是带着庄严而神圣的任务过来的:给一个车厂做了一款PEPS,领导让过来做总线

    出师不利,遇阻

    整车厂进行的总线包括通信测试、网路管理测试和诊断协议测试三大块,通信测试主要包括工作电压、上升沿、下降沿、采样点、报文周期准确性、Bus-off后的快速?#25351;?#21644;慢速?#25351;?#31561;测试项,网络管理测试主要包括CAN节点的网络建环、掉线、Bus-off、协同休眠、本地?#21483;?#21644;远程?#21483;?#31561;测试项,诊断协议测试主要包括多帧收发、响应超时、诊断会话切换、诊断服务等测试项。

    笔者其实是带着轻松愉快的心情过来测试的,因为做这款PEPS产品之前做了一款BCM,当时这款BCM已经量产,而且也在汽车厂进行过总线测试,对比来?#30679;?#36825;两家车厂的测试条目差不多,笔者就把当时BCM上的代码移植到了这款PEPS上,根据不同之处进行了相应修改。按照红?#21477;?#35272;器联合创始人的说法,虽然用的是开源代码,但是了解每一?#20889;?#30721;的含义并知道怎么修?#27169;?#23601;是自主可控,笔者盘算着,?#28909;籅CM的总线测试都通过了,而且我不仅知道怎么修?#24700;?#20123;代码,这些代码还完全是我自己写的,所以PEPS这?#23614;?#35797;也绝对是可控的,应该比较顺利。

    等到看测试结果的时候,?#39034;?#20914;的我?#36335;?#34987;浇了一?#38450;?#27700;,有两项测试没通过,这两项测试分别是用优先级最高和优先级最低的报文填充CAN总线带宽,让总线负载率达到100%,在全负荷的情况下检测PEPS周期发送报文的时间准确性。我扒拉着这两项测试条目的测试数据,眼睛都快看花了,终于发现,确实有一个周期为50ms的报文出现过一次报文漏发的情况,测试软件的判断条件是检查每个报文连续两次发送的时间间隔,如果时间间隔在45-55ms(报文周期的正负10%)之间,测试通过,反之测试失败。

    中断频?#20445;?a class="contentlabel" href="http://www.09140960.com/news/listbylabel/label/MCU">MCU不堪重负

    “不一样”的宫斗剧《延禧攻略》最近火得不得了,?#28304;?#26080;敌光环的延禧宫主子魏璎珞说过,事情来了就不要怕!但是,当我发现报文周期准确性测试失败?#20445;?#24515;中还是怕怕的,因为我本能地意识到,旅游计划肯定是泡汤了,总线负载率100%意味着CAN总线接收中断过于频?#20445;?#27979;试失败不是逻辑上的错误导致,而是性能限?#39057;?#33268;的系统性问题。在换不了的情况下,需要做大量优化才能降低MCU的负荷,将有限的性能用在CAN报文接收中断的处理上和周期报文的发送上。

    科学研究工作是严谨的,产品开发亦是如此,为了更好地量化MCU的负荷,我做了如?#36335;?#26512;:

    整车厂规定所有总线报文的数据场长度为8个字节,根据CAN报文格式,一个8字节数据场的CAN报文的位数为1(帧起始)+ 12(仲裁场)+ 6(控制场)+ 64(数据场)+ 16(CRC场)+ 2(应答场)+ 7(帧结尾)=108位。报文之间存在帧间空间INTERFRAME SPACE。帧间包括间歇场、总线空闲的?#24576; ?#38388;歇场包括3 个“隐性”的位。总线空闲的(时间)长度是?#25105;?#30340;。

    所以,一个8字节的数据帧至少需要(108+3+1)* 位时长的时间,总线波特率为125KHz,位时长为8us,经计算得知,一条总线报文的最短时间长度为0.896ms,为了计算方便,按0.9ms计。

    在这?#23614;?#35797;中,PEPS发送报文消耗的总线带宽大约为3%,这就意味着,在总线负载率是100%的情况下,CAN报文接收中断的周期为0.9/0.97=0.93ms,?#30679;琍EPS每隔0.93ms都会触发一次CAN接收中断,执行一次中断服务程序。由于成本限?#30130;?#36825;款PEPS选择的MCU是一款中档16位单片机,主频不过25MHz,却需要应付这么频繁的中断,心疼MCU三秒钟。。。

    降低中断频率

    肿么办?CAN报文接收中断服务程序写得非常简洁,根本不存在任何优化空间,这条测试项目制造出100%总线负载率,CAN报文接收中断频?#31034;?#26159;那么惨无人道地频?#20445;?#20063;是不可更?#27169;?#22240;此,只能从别处下?#24103;?/p>

    嵌入式系统有大量定时应用,所以无论用不用操作系统,都会有一个“系统?#20445;?#23427;以固定的时间间隔触发中断,为各种定时应用提供时间基准。这也是一个频繁发生的中断,我检查了这款PEPS上的,发现其周期设定为了2ms,之所以选择2ms,主要是出于代码复用,之前我在BCM上选择的系?#36710;?#31572;为2ms,它会牵扯到好多定时?#38382;?#30340;设置,为了把BCM上的一些代码直接拿?#38477;絇EPS上来用,于是也原封不动地把系?#36710;?#31572;设置成了2ms。

    CAN接收中断周期为0.93ms,滴答中断周期为2ms,假设不存在其它任何中断,系统的综合中断周期为0.64ms,?#24378;頑CM的MCU主?#28404;?4MHz,是现在这款MCU的25MHz主频的2.56倍,64MHz 主频可以顺利处理0.64ms周期性中断,25MHz主频就卡了壳了。

    顺着这条思路,笔者将系?#36710;?#31572;设置成了10ms,在CAN接收中断周期0.93ms,滴答中断周期为10ms的条件下,系统综合中断周期为0.85ms,将中断负荷降低了33%。系?#36710;?#31572;修改后好多地?#21483;?#35201;进行相应修?#27169;?#36825;么折腾了两天,再次进行通信测试,报文周期准确性测试通过,笔者悬着的心才放了下来,至于是不是堪堪通过,MCU负荷的余量是否其实已经非常小了,那?#22836;?#31508;者水平能够判断了。

    滴答更改的性能比较

    为了量化滴答由2ms提高至10ms带来的性能提升,笔者定义了一个32位全?#30452;?#37327;,在程序的主循环体中累加,每执行一次主循环体,该变量加一,然后根据单位时间(1秒)内的主循?#20998;蔥写问?#21028;断采用不同滴答的两个程序的运行效率。

    测试发现,滴答设置为2ms?#20445;?#27599;秒执?#20889;?#32422;22200次循环,滴答设置为10ms?#20445;?#27599;秒执?#20889;?#32422;25100次循环,效率大约提升了13个百分点。

    至于10ms的滴答是否合理,笔者接触过的ucos和FreeRTOS中的好多移植例程中都把系?#36710;?#31572;设置成了10ms,足可见10ms的滴答满足大多数嵌入式系统的需求。

    后记

    归程依然酷暑难?#20572;?#30001;于没有完成既定的旅游计划,笔者心中多多少少有那么一丢丢的小遗憾,但是这?#23614;?#35797;让我对中断、MCU性能又有了更?#30001;?#21051;的认识,也算是收获满满不虚此行了。高铁窗外的景色飞速向后退去,眼前只模模糊糊地留下一片绿色的影像,旁边座位上的小姑娘正在叽叽喳喳地和妈妈嬉笑打闹,?#21485;?#26524;人们像爱护小孩子那样爱护MCU,通过合理的设计减轻它的工作负荷,让它不要累着,那该是多么美好的机器世界啊。”我不禁暗暗想到。



    关键词: MCU 滴答 测试

    评论

    技术专区

    关闭