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

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

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

為了解決響應(yīng)時(shí)間問(wèn)題，他們比較了兩個(gè)版本的源代碼，找不到任何明顯的原因?qū)е马憫?yīng)時(shí)間變長(zhǎng)。代碼有許多小的變化，但并沒(méi)有增加新的功能。因此，用戶決定使用Tracealyzer來(lái)比較新舊版本的運(yùn)行時(shí)行為。

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

圖 1A

圖1B

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

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

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

圖2A

圖2B

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

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

圖3

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

圖4

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

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

圖5

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

問(wèn)題解決了！更多關(guān)于Tracealyzer的技術(shù)文檔，請(qǐng)關(guān)注BMR微信公號(hào)。

審核編輯：湯梓紅