使用實時操作系統(tǒng)開發(fā)軟件時，如何測量性能？

性能分析非常重要的一個方面是響應時間，例如，從一個任務被激活到運行完成的時間?？梢酝ㄟ^多種方式來測量響應時間，如反轉I/O引腳并使用邏輯分析儀進行測量，或通過添加一些額外的代碼來測量兩點之間時鐘周期數(shù)。但這些測量措施只能檢測兩點之間的處理器時間，無法獲知影響時間的因素，例如中斷或其他任務搶占導致的干擾。

性能分析的另一個重要內(nèi)容是執(zhí)行時間，一段特定代碼實際使用的處理器時間。我們通?？梢詫Τ绦蛴嫈?shù)器進行采樣獲取使用的處理器時間，許多IDE支持該功能，大多數(shù)基于ARM的MCU為此提供了硬件支持。然而，通過該方式獲取的數(shù)據(jù)是平均測量值，對于頻率較低的函數(shù)或任務是不準確的。此外，這些信息不能指示異常長的執(zhí)行可能會導致問題，例如超時。

使用RTOS知識進行跟蹤

要獲得RTOS行為的準確信息，你需要一個RTOS感知跟蹤的解決方案。但許多工具僅支持指定的操作系統(tǒng)。它們通常使用水平甘特圖顯示任務執(zhí)行隨時間的變化，但其跟蹤信息很難并行顯示其他事件，例如RTOS API的調(diào)用。

圖1 Tracealyzer主視圖

Tracealyzer 的主視圖（圖1）使用垂直時間軸，不僅顯示RTOS調(diào)度過程和中斷，還通過文本標簽顯示RTOS調(diào)用的事件或自定義用戶事件。這些標簽“浮動”顯示并均勻分布。調(diào)度軌跡中的矩形框對應于一次連續(xù)的執(zhí)行，稱為Fragment（分片）。參與者（Actor）表示被跟蹤系統(tǒng)中的所有執(zhí)行上下文，例如任務和中斷處理程序。任務調(diào)度可以不同的方式呈現(xiàn)或查看。圖1中，每個參與者一列，分片在多列中排序。

圖2 執(zhí)行時間和響應時間變化

一個參與者，在捕獲視圖中有多個實例。實例表示參與者的一次執(zhí)行，即從任務被觸發(fā)到完成的過程。在Tracealyzer 主視圖中點擊參與者的分片，參與者實例通過藍色矩形框突出顯示，如圖1。

此外，執(zhí)行時間和響應時間等性能指標基于每個實例計算，并可視化為圖2所示的詳細圖表。例如如果捕獲任務的最大響應時間是為 3255 μs，而最大執(zhí)行時間僅為1087 μs，這意味著大部分響應時間被其他任務或中斷占用。

Tracealyzer中的所有視圖都是相互關聯(lián)的，通過單擊繪制的數(shù)據(jù)點，你會找到主跟蹤視圖中的相應位置，以及統(tǒng)計數(shù)據(jù)背后的詳細RTOS行為。

任務調(diào)度事件如何分組到任務實例中？對于周期RTOS任務來說，一個實例對應一個迭代循環(huán)，由RTOS阻塞調(diào)用分隔，例如，循環(huán)中的隊列接收調(diào)用QueueRecieve或延時調(diào)用DelayUntil。但是一個任務可能會執(zhí)行多個這樣的調(diào)用，那么Tracealyzer如何知道從哪里結束當前實例并開始一個新的實例？

Tracealyzer 有一個“實例完成事件”（IFE）概念，通過兩種方式定義。用戶在大多數(shù)情況下不需要為此煩惱，因為有一組標準規(guī)則，用于指定RTOS調(diào)用的內(nèi)容作為IFE，例如延遲調(diào)用和 QueueRecieve調(diào)用。不需要額外的配置。但是，對于規(guī)則不合適的情況，可能會需要生成顯式事件 (IFE) 標記實例完成，需要調(diào)用記錄庫中的特定函數(shù)實現(xiàn)。

圖 3顯示了一個示例，其中墨綠色控制任務分為多個實例，盡管這些點上沒有發(fā)生任務切換。你可以手動決定如何將事件分組到實例中，從而控制時序統(tǒng)計的解釋。

圖3 實例結束事件IFE允許自定義間隔

總結

使用RTOS帶來的復雜性，使得應用的運行時行為難以通過閱讀代碼的方式理解。基于Tracealyzer的可視化分析，可以幫助我們理解和控制軟件的運行時行為。關于如何使用Tracezlyzer，捕獲系統(tǒng)行為的信息，可以參考《嵌入式實時操作系統(tǒng)-基于STM32Cube、FreeRTOS和Tracealyzer的應用開發(fā)》

歡迎關注微信公眾號【麥克泰技術】