高效的開發基于FreeRTOS的固件需要理解任務、中斷和內核之間的交互以及時間序列。

Tracealyzer支持基于FreeRTOS應用的可視化分析，它提供了30多種相互關聯的視圖，觀測軟件運行時行為。

我們基于一個案例解析Tracealyzer如何幫助用戶解決實際問題。本例中， 用戶在ARM Cortex-M4微控制器上運行了FreeRTOS+TCP/IP+Flash文件系統的應用。系統中包含多個任務，一個Server任務用于響應網絡請求，一個Logger文件緩沖任務。網絡請求的響應時間一直不理想，最近一次構建，響應時間更加惡化。

為了解決響應時間問題，他們比較了兩個版本的源代碼，找不到任何明顯的原因導致響應時間變長。代碼有許多小的變化，但并沒有增加新的功能。因此，用戶決定使用Tracealyzer來比較新舊版本的運行時行為。

在相似的條件下記錄兩個版本的運行過程。使用Actor Statistics Report視圖進行比較 (圖1A和圖1B)，視圖中提供了時間統計信息，如CPU使用情況、執行次數、任務優先級和響應時間信息。

圖 1A

圖1B

Statistics Report顯示，新代碼版本中Server任務的響應時間（Response time）增加大約50%。而執行時間（Execution time）新版本中僅增長約7%。由此得出的結論，較長響應時間的主要原因一定是其他任務的干擾，但是哪個任務?

為了確定哪些任務干擾了Server任務，單擊Statistics Report中的極端值。跟蹤到主視圖中相應的位置，可以看到更多執行細節，打開Tracealyzer的并行實例，可以很容易地比較并發現差異。

由于Server任務執行了多個服務，因此我們添加了兩個用戶事件 (標記為ServerLog)來標記接收和應答請求，如圖2A和2B所示，圖例的縮放級別相同，可以清楚地看到新版本中響應時間更長，Logger任務搶占了Server任務11次，而舊版本中搶占只有6次。

圖2A

圖2B

此外，我們看到Logger任務的優先級高于Server任務，因此日志記錄的服務調用會搶占Server任務。

因此，新版本中似乎添加了新的日志記錄調用，導致Logger任務更多地干擾Server任務。為了查看記錄的內容，我們在日志任務中添加了一個User Event，在跟蹤視圖中顯示所有日志消息。可以看到除了Server之外的其他任務生成的日志消息，例如ADC_0任務。為了查看向日志任務發送消息的所有任務，我們使用Tracealyzer的通信流圖，如圖3所示。通信流圖顯示了跟蹤的任務和中斷對消息隊列、信號量和其他內核對象執行的所有操作，展示了上層應用程序設計以及運行時依賴關系。

圖3

在本例中，通信流圖顯示有五個任務發送日志消息。通過雙擊圖中的LoggerQueue節點，可以打開Kernel Object History視圖，查看該消息隊列上的所有操作(圖4)。正如預期的那樣，我們看到Logger任務頻繁地接收消息，每次接收一條消息，并且在每個消息之后被阻塞，如Event列中的紅色指示燈所示。

圖4

應用可能沒有必要將日志消息一條接一條地寫入文件。如果提升Server任務的調度優先級高于Logger任務，那么Server能夠更快地響應，日志消息可以被緩沖在LoggerQueue隊列中，直到Server和其他高優先級任務完成，Logger任務恢復執行并批量處理所有緩沖消息。

測試的結果如圖5所示。Server任務的最高響應時間現在只有5.4 ms，比早期版本(5.7 ms)還要快，Logger任務收到一條消息后不會立即搶占Server任務，而是在Server完成后批量處理所有掛起的消息。

圖5

我們還可以查看消息隊列操作的事件標簽，并且正如預期的那樣，多個xQueueSend調用，沒有引起阻塞或任務搶占。仍然有一些由A/D轉換任務引起的搶占，但這不再導致Logger任務的額外激活。

問題解決了！更多關于Tracealyzer的技術文檔，請關注BMR微信公號。

審核編輯：湯梓紅