我正在接管一個「傳統」嵌入式系統應用程序,而不是傳統程序,我所關心的第一件事是我發現在在某種程度上,應用程序的時間限制因項目的需求而丟失。現在,我的任務是重構它,並按照它的實際情況進行實時操作。關於如何將傳統嵌入式應用程序約束到實時應用程序的建議
該項目針對C和C++中的ATMEL UC3完成。它運行FreeRTOS,有6個任務。 5用於管理外部設備,另一個則以最低優先級和最重要的任務作爲主程序。 我做的第一件事就是測量主要任務所花費的時間,有時它從死亡線上跳下並不奇怪,因此完成的任務在幾個週期內執行。
任何人都可以請建議我在這種情況下可能的要點是什麼?
你會怎麼做? 我知道我應該遵循所有執行路徑的流程並對指令進行計數,然後採用最差的執行路徑,並且使用該芯片的頻率可以實時執行。那在理論上,是否有任何工具,技巧或程序讓它更容易一些?
更新:
我不能共享機密的原因源。此外,我一直在深入挖掘,發現主要的延遲,顯然是由隊列大小產生的。大多數隊列是爲了保存2或3條消息而創建的。我需要做一些測試,以便在這裏提供更多信息。理論上,如果隊列被填滿,那麼剩下的進程不能再發送,直到再次有空閒空間用於更多消息。然後進程暫停,導致連續的重新調度。我的想法是將隊列大小增加到10,以查看它是否提高了性能和時間。
更新2 從建議中,我發現他們非常有幫助的,當我在黑暗中開始,我碰到了一個名爲「理解」它不是免費的工具,而是幫助我得到的分析和字符。您也可以看到複雜函數的字符流,因此您可以看到執行流程的最長路徑。
這個問題是非常通用的。我很懷疑你會得到任何有用的答案(通用或不),而不提供一些更具體的細節。我可以建議你的主線程代碼開始嗎? –
模擬?遠程調試? – Yakk
研究「分析」。 –