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

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

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

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

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

圖 1A

圖1B

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

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

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

圖2A

圖2B

此外，我們看到Logger任務的優(yōu)先級高于Server任務，因此日志記錄的服務調(diào)用會搶占Server任務。

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

圖3

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

圖4

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

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

圖5

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

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

審核編輯：湯梓紅