<listing id="dgcc5"></listing>
<address id="dgcc5"><progress id="dgcc5"><font id="dgcc5"></font></progress></address>
<video id="dgcc5"><big id="dgcc5"><nobr id="dgcc5"></nobr></big></video>
<address id="dgcc5"></address>
<th id="dgcc5"><big id="dgcc5"><listing id="dgcc5"></listing></big></th>
<thead id="dgcc5"><meter id="dgcc5"></meter></thead>

<th id="dgcc5"><address id="dgcc5"></address></th>

<track id="dgcc5"><progress id="dgcc5"><listing id="dgcc5"></listing></progress></track>

<nobr id="dgcc5"><menuitem id="dgcc5"><var id="dgcc5"></var></menuitem></nobr>
<address id="dgcc5"><progress id="dgcc5"></progress></address>
      
      

        <th id="dgcc5"><meter id="dgcc5"><dfn id="dgcc5"></dfn></meter></th>

        <thead id="dgcc5"></thead>

        <track id="dgcc5"><address id="dgcc5"></address></track><address id="dgcc5"><meter id="dgcc5"></meter></address>
        <address id="dgcc5"><progress id="dgcc5"></progress></address>

            <sub id="dgcc5"></sub>

            <th id="dgcc5"></th>

            <sub id="dgcc5"><meter id="dgcc5"><cite id="dgcc5"></cite></meter></sub>

                <address id="dgcc5"><progress id="dgcc5"></progress></address>

                  <sub id="dgcc5"><progress id="dgcc5"></progress></sub>

                    <th id="dgcc5"><progress id="dgcc5"><listing id="dgcc5"></listing></progress></th>
                      <th id="dgcc5"><address id="dgcc5"><dfn id="dgcc5"></dfn></address></th>

                        <output id="dgcc5"><ins id="dgcc5"></ins></output>
                        <dl id="dgcc5"></dl>

                        1. <output id="dgcc5"><font id="dgcc5"><thead id="dgcc5"></thead></font></output>
                          1. <dl id="dgcc5"><ins id="dgcc5"></ins></dl>
                            <output id="dgcc5"></output>

                            新聞中心

                            EEPW首頁 > 牛人業話 > 合理設置MCU滴答 千萬不要累著它

                            合理設置MCU滴答 千萬不要累著它

                            作者:光華居士時間:2018-08-29來源:電子產品世界收藏

                            2017年盛夏,北京街頭,晴空萬里,無風。

                            本文引用地址:http://www.uavs.tw/article/201808/391345.htm

                            近乎凝滯的空氣中一點風都沒有,惱人的知了無停無休地叫著,不疲也不厭,讓人很是懷疑它們的居心。被太陽曬得發焦的柏油路面熱氣騰騰,像被曬干了肚皮的魚兒一樣無聲地嘶嚎著。呼嘯而過的汽車排著滾燙的尾氣,急匆匆地想要逃離這個世界,偶爾響起的一聲喇叭,就像向太陽求饒一般。地鐵站和周圍的建筑被曬得無精打采的,無可奈何地矗立在似火驕陽的暴曬之下。剛從地鐵站出來的人們行色匆匆,難得悠閑從容的面孔,筆者被裹挾在滾滾人流之中,不由自主地加快著腳步。站在十字路口,一股股熱浪撲面而來,我頂著發燙的頭皮,在心中一片哀號,“北京真熱啊!”

                            筆者這次頂著大熱天來帝都,是帶著莊嚴而神圣的任務過來的:給一個車廠做了一款PEPS,領導讓過來做總線

                            出師不利,遇阻

                            整車廠進行的總線包括通信測試、網路管理測試和診斷協議測試三大塊,通信測試主要包括工作電壓、上升沿、下降沿、采樣點、報文周期準確性、Bus-off后的快速恢復和慢速恢復等測試項,網絡管理測試主要包括CAN節點的網絡建環、掉線、Bus-off、協同休眠、本地喚醒和遠程喚醒等測試項,診斷協議測試主要包括多幀收發、響應超時、診斷會話切換、診斷服務等測試項。

                            筆者其實是帶著輕松愉快的心情過來測試的,因為做這款PEPS產品之前做了一款BCM,當時這款BCM已經量產,而且也在汽車廠進行過總線測試,對比來看,這兩家車廠的測試條目差不多,筆者就把當時BCM上的代碼移植到了這款PEPS上,根據不同之處進行了相應修改。按照紅芯瀏覽器聯合創始人的說法,雖然用的是開源代碼,但是了解每一行代碼的含義并知道怎么修改,就是自主可控,筆者盤算著,既然BCM的總線測試都通過了,而且我不僅知道怎么修改這些代碼,這些代碼還完全是我自己寫的,所以PEPS這次測試也絕對是可控的,應該比較順利。

                            等到看測試結果的時候,興沖沖的我仿佛被澆了一頭冷水,有兩項測試沒通過,這兩項測試分別是用優先級最高和優先級最低的報文填充CAN總線帶寬,讓總線負載率達到100%,在全負荷的情況下檢測PEPS周期發送報文的時間準確性。我扒拉著這兩項測試條目的測試數據,眼睛都快看花了,終于發現,確實有一個周期為50ms的報文出現過一次報文漏發的情況,測試軟件的判斷條件是檢查每個報文連續兩次發送的時間間隔,如果時間間隔在45-55ms(報文周期的正負10%)之間,測試通過,反之測試失敗。

                            中斷頻繁,不堪重負

                            “不一樣”的宮斗劇《延禧攻略》最近火得不得了,自帶無敵光環的延禧宮主子魏瓔珞說過,事情來了就不要怕!但是,當我發現報文周期準確性測試失敗時,心中還是怕怕的,因為我本能地意識到,旅游計劃肯定是泡湯了,總線負載率100%意味著CAN總線接收中斷過于頻繁,測試失敗不是邏輯上的錯誤導致,而是性能限制導致的系統性問題。在換不了的情況下,需要做大量優化才能降低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,通過合理的設計減輕它的工作負荷,讓它不要累著,那該是多么美好的機器世界啊。”我不禁暗暗想到。



                            關鍵詞: MCU 滴答 測試

                            推薦閱讀

                            評論

                            技術專區

                            關閉
                            青海11选5开奖结果