眾所周知，單獨的源代碼并不給出基于RTOS的固件實際行為的全貌表現(xiàn)。實時行為還取決于許多其他因素，如任務(wù)和中斷的定時，輸入和實時操作系統(tǒng)的配置。

Tracealyzer提供了前所未有的洞察基于RTOS的軟件的運行世界功能，從而改善開發(fā)效率，減少上市時間，及更好的軟件質(zhì)量。使用Tracealyzer，可以記錄RTOS及應(yīng)用的實時行為，并具有強大的可視化功能，提供前所未有的洞察運行時狀態(tài)的能力。這有助于加速基于RTOS的軟件開發(fā)、驗證和調(diào)試。

Tracealyzer支持FreeRTOS，uC/OS-III，VxWorks以及Linux的跟蹤。

近日，由《嵌入式系統(tǒng)編程》雜志的前任主編兼行業(yè)資深人士邁克爾?巴爾(Michael Barr)撰寫的三本關(guān)于軟件漏洞主題的書籍，不僅列出了錯誤，還提出了避免它們的設(shè)計模式。

良好的設(shè)計模式是非常寶貴的，但無論如何錯誤總是難以避免的。在調(diào)試嵌入式軟件時，使用Percepio Tracealyzer等RTOS跟蹤工具可以找到并分析這些錯誤中的至少五個。

1、抖動

如果軟件系統(tǒng)中有一項需要定期執(zhí)行的任務(wù)，例如每10毫秒讀取一次模數(shù)轉(zhuǎn)換器，那么它就擁有一個對隨機延遲敏感的系統(tǒng) - 也稱為抖動。如果10 ms間隔降低到10±2 ms，則計算精度會相應(yīng)降低。

為了最大限度地減少抖動，邁克爾?巴爾指出需要微調(diào)任務(wù)優(yōu)先級，并可能使用定時器中斷來處理最敏感的代碼。Tracealyzer在定位系統(tǒng)中的抖動方面非常有用。

2、優(yōu)先級分配不正確

設(shè)置合適的任務(wù)優(yōu)先級對于基于RTOS的系統(tǒng)的性能和可靠性至關(guān)重要，因為采用過高優(yōu)先級運行的任務(wù)可能會導(dǎo)致其他任務(wù)中出現(xiàn)無法接受的延遲。

邁克爾?巴爾指出，速率單調(diào)分析（RMA）是一種在具有固定優(yōu)先級和搶占式調(diào)度的系統(tǒng)中分配任務(wù)優(yōu)先級的正式方法。但是，這需要有足夠的有關(guān)任務(wù)行為的信息，并且任務(wù)的行為符合此分析方法的假設(shè)。

找到在所有情況下都能正常工作的任務(wù)優(yōu)先級的正確組合可能非常困難，除非有一個良好的跟蹤工具來顯示RTOS中正在發(fā)生的事情。 Tracealyzer允許檢查執(zhí)行時間，執(zhí)行模式以及任務(wù)的最終響應(yīng)時間。這使開發(fā)者可以評估和優(yōu)化其優(yōu)先級分配，以實現(xiàn)更快的響應(yīng)時間和更可靠的行為。

3、優(yōu)先級反轉(zhuǎn)

具有固定優(yōu)先級調(diào)度程序的RTOS的核心思想是，應(yīng)該在具有較低優(yōu)先級的任務(wù)之前安排高優(yōu)先級任務(wù)，但是當兩個或多個任務(wù)需要協(xié)調(diào)其工作與全局數(shù)據(jù)區(qū)等共享資源或外圍設(shè)備時，可能會導(dǎo)致系統(tǒng)出錯。

其中一個可能出錯的事情就是優(yōu)先級反轉(zhuǎn)(priority inversion)，低優(yōu)先級任務(wù)無意中阻止了具有更高優(yōu)先級的任務(wù)。 如果你意識到這個陷阱，這也很容易地避免。 但是，如果發(fā)現(xiàn)系統(tǒng)的響應(yīng)性偶爾會出現(xiàn)延遲，則可能是因為優(yōu)先級反轉(zhuǎn)。 使用Tracealyzer，可以通過繪制任務(wù)的響應(yīng)時間來發(fā)現(xiàn)此類延遲。 要查看此圖中任何極端值的原因，只需雙擊以顯示相應(yīng)的任務(wù)執(zhí)行跟蹤。

4、死鎖

死鎖是兩個或多個任務(wù)之間的循環(huán)依賴。 例如，如果任務(wù)1已經(jīng)獲得A，并且被阻止等待B，而任務(wù)2先前已獲得B，并且被阻止等待A，則這兩個任務(wù)都不會被喚醒。 盡管沒有更高優(yōu)先級的任務(wù)正在運行，但是當多個任務(wù)突然停止執(zhí)行時，可能是出現(xiàn)死鎖問題的明確跡象。 同樣，死鎖的檢測是Tracealyzer可以展示的內(nèi)容。

如果希望避免死鎖，首先要注意的是，只有當任務(wù)試圖同時持有兩個資源時才會發(fā)生死鎖。 因此：構(gòu)建代碼時，使任何任務(wù)在同一時間都不會持有多個共享資源，這樣不會產(chǎn)生死鎖。

5、內(nèi)存泄漏

通常不建議在嵌入式軟件中進行動態(tài)內(nèi)存分配，但有時會出于各種原因（對或錯）進行動態(tài)內(nèi)存分配。問題在于，如果使用它，則必須確保一旦內(nèi)存塊不再使用時，就釋放每個已分配的內(nèi)存塊。如果在某些情況下遺漏了這一點，就會出現(xiàn)內(nèi)存泄漏，并最終耗盡內(nèi)存。請記?。杭词乖陧椖恐薪箘討B(tài)內(nèi)存分配，也可能有第三方軟件庫或外部開發(fā)團隊在不知情的情況下使用動態(tài)內(nèi)存分配。

如果內(nèi)存泄漏只是偶爾發(fā)生，那么它就特別危險，因為在功能測試期間很容易錯過“緩慢”的內(nèi)存泄漏，但在部署單元一段時間后，可能會導(dǎo)致嚴重錯誤。考慮到許多嵌入式系統(tǒng)的長期運行特性，以及一些安全關(guān)鍵系統(tǒng)可能存在的致命或嚴重故障，內(nèi)存泄漏是絕對不希望在軟件中出現(xiàn)的一個錯誤。

Tracealyzer可以監(jiān)視RTOS對動態(tài)內(nèi)存分配的調(diào)用，并可以突出顯示可疑的內(nèi)存泄漏。