2017年盛夏，北京街头，晴空万里，无风。
近乎凝滞的空气中一点风都没有，恼人的知了无停无休地叫着，不疲也不厌，让人很是置疑它们的存心。被太阳晒得发焦的柏油路面热火朝天，像被晒干了肚皮的鱼儿相同无声地嘶嚎着。呼啸而过的轿车排着滚烫的尾气，急匆匆地想要逃离这个国际，偶然响起的一声喇叭，就像向太阳求饶一般。地铁站和周围的修建被晒得萎靡不振的，百般无奈地矗立在似火烈日的暴晒之下。刚从地铁站出来的人们行色匆匆，可贵清闲沉着的面孔，笔者被威胁在滚滚人流之中，情不自禁地加速着脚步。站在十字路口，一股股热浪扑面而来，我顶着发烫的头皮，在心中一片哀号，“北京真热啊！”
笔者这次顶着大热天来帝都，是带着庄重而崇高的使命过来的：给一个车厂做了一款PEPS，领导让过来做总线测验。
出师不利，测验遇阻
整车厂进行的总线测验包含通讯测验、网路办理测验和确诊协议测验三大块，通讯测验首要包含作业电压、上升沿、下降沿、采样点、报文周期准确性、Bus-off后的快速康复和慢速康复等测验项，网络办理测验首要包含CAN节点的网络建环、掉线、Bus-off、协同休眠、本地唤醒和长途唤醒等测验项，确诊协议测验首要包含多帧收发、呼应超时、确诊会话切换、确诊服务等测验项。
笔者其实是带着轻松愉快的心境过来测验的，因为做这款PEPS产品之前做了一款BCM，其时这款BCM现已量产，并且也在轿车厂进行过总线测验，比照来看，这两家车厂的测验条目差不多，笔者就把其时BCM上的代码移植到了这款PEPS上，依据不同之处进行了相应修正。依照红芯浏览器联合创始人的说法，尽管用的是开源代码，可是了解每一行代码的意义并知道怎样修正，便是自主可控，笔者盘算着，已然BCM的总线测验都经过了，并且我不只知道怎样修正这些代码，这些代码还完全是我自己写的，所以PEPS这次测验也肯定是可控的，应该比较顺畅。
比及看测验成果的时分，兴冲冲的我似乎被浇了一头冷水，有两项测验没经过，这两项测验分别是用优先级最高和优先级最低的报文填充CAN总线带宽，让总线负载率到达100%，在全负荷的状况下检测PEPS周期发送报文的时刻准确性。我扒拉着这两项测验条目的测验数据，眼睛都快看花了，总算发现，的确有一个周期为50ms的报文呈现过一次报文漏发的状况，测验软件的判别条件是查看每个报文接连两次发送的时刻距离，假如时刻距离在45-55ms（报文周期的正负10%）之间，测验经过，反之测验失利。
中止频频，MCU不堪重负
“不相同”的宫斗剧《延禧攻略》最近火得不得了，自带无敌光环的延禧宫主子魏璎珞说过，作业来了就不要怕！可是，当我发现报文周期准确性测验失利时，心中仍是怕怕的，因为我天性地意识到，旅行方案肯定是落空了，总线负载率100%意味着CAN总线接纳中止过于频频，测验失利不是逻辑上的过错导致，而是MCU功能约束导致的体系性问题。在换不了MCU的状况下，需求做很多优化才干下降MCU的负荷，将有限的功能用在CAN报文接纳中止的处理上和周期报文的发送上。
科学研究作业是谨慎的，产品开发亦是如此，为了更好地量化MCU的负荷，我做了如下剖析：
整车厂规则一切总线报文的数据场长度为8个字节，依据CAN报文格式，一个8字节数据场的CAN报文的位数为1（帧开始）+ 12（裁定场）+ 6（操控场）+ 64（数据场）+ 16（CRC场）+ 2（应对场）+ 7（帧结束）=108位。报文之间存在帧间空间INTERFRAME SPACE。帧间包含间歇场、总线闲暇的位场。间歇场包含3 个“隐性”的位。总线闲暇的（时刻）长度是恣意的。
所以，一个8字节的数据帧至少需求（108+3+1）* 位时长的时刻，总线波特率为125KHz，位时长为8us，经核算得知，一条总线报文的最短时刻长度为0.896ms，为了核算便利，按0.9ms计。
在这次测验中，PEPS发送报文耗费的总线带宽大约为3%，这就意味着，在总线负载率是100%的状况下，CAN报文接纳中止的周期为0.9/0.97=0.93ms，即，PEPS每隔0.93ms都会触发一次CAN接纳中止，履行一次中止服务程序。因为本钱约束，这款PEPS挑选的MCU是一款中档16位单片机，主频不过25MHz，却需求敷衍这么频频的中止，疼爱MCU三秒钟。。。
下降滴答中止频率
肿么办？CAN报文接纳中止服务程序写得十分简练，底子不存在任何优化空间，这条测验项目制造出100%总线负载率，CAN报文接纳中止频率便是那么惨绝人寰地频频，也是不行更改，因而，只能从别处下手。
嵌入式体系有很多守时使用，所以不管用不用操作体系，都会有一个“体系滴答”，它以固定的时刻距离触发中止，为各种守时使用供给时刻基准。这也是一个频频产生的中止，我查看了这款PEPS上的滴答，发现其周期设定为了2ms，之所以挑选2ms，首要是出于代码复用，之前我在BCM上挑选的体系滴答为2ms，它会牵扯到很多守时参数的设置，为了把BCM上的一些代码直接拿到到PEPS上来用，所以也原封不动地把体系滴答设置成了2ms。
CAN接纳中止周期为0.93ms，滴答中止周期为2ms，假定不存在其它任何中止，体系的归纳中止周期为0.64ms，那款BCM的MCU主频为64MHz，是现在这款MCU的25MHz主频的2.56倍，64MHz 主频可以顺畅处理0.64ms周期性中止，25MHz主频就卡了壳了。
顺着这条思路，笔者将体系滴答设置成了10ms，在CAN接纳中止周期0.93ms，滴答中止周期为10ms的条件下，体系归纳中止周期为0.85ms，将中止负荷下降了33%。体系滴答修正后很多当地需求进行相应修正，这么折腾了两天，再次进行通讯测验，报文周期准确性测验经过，笔者悬着的心才放了下来，至所以不是堪堪经过，MCU负荷的余量是否其实现已十分小了，那就非笔者水平可以判别了。
滴答更改的功能比较
为了量化滴答由2ms进步至10ms带来的功能提高，笔者界说了一个32位全局变量，在程序的主循环体中累加，每履行一次主循环体，该变量加一，然后依据单位时刻（1秒）内的主循环履行次数，判别选用不同滴答的两个程序的运转功率。
测验发现，滴答设置为2ms时，每秒履行大约22200次循环，滴答设置为10ms时，每秒履行大约25100次循环，功率大约提高了13个百分点。
至于10ms的滴答是否合理，笔者触摸过的ucos和FreeRTOS中的很多移植例程中都把体系滴答设置成了10ms，足可见10ms的滴答满意大多数嵌入式体系的需求。
跋文
归程仍然盛暑难耐，因为没有完结既定的旅行方案，笔者心中多多少少有那么一丢丢的小惋惜，可是这次测验让我对中止、MCU功能又有了愈加深入的知道，也算是收成满满不虚此行了。高铁窗外的风光飞速向后退去，眼前只模模糊糊地留下一片绿色的印象，周围座位上的小姑娘正在叽叽喳喳地和妈妈嬉笑打闹，“假如人们像保护小孩子那样保护MCU，经过合理的规划减轻它的作业负荷，让它不要累着，那该是多么夸姣的机器国际啊。”我不由暗暗想到。
