2014-02-12 18 views
2

我正在接管一個「傳統」嵌入式系統應用程序,而不是傳統程序,我所關心的第一件事是我發現在在某種程度上,應用程序的時間限制因項目的需求而丟失。現在,我的任務是重構它,並按照它的實際情況進行實時操作。關於如何將傳統嵌入式應用程序約束到實時應用程序的建議

該項目針對C和C++中的ATMEL UC3完成。它運行FreeRTOS,有6個任務。 5用於管理外部設備,另一個則以最低優先級和最重要的任務作爲主程序。 我做的第一件事就是測量主要任務所花費的時間,有時它從死亡線上跳下並不奇怪,因此完成的任務在幾個週期內執行。

任何人都可以請建議我在這種情況下可能的要點是什麼?

你會怎麼做? 我知道我應該遵循所有執行路徑的流程並對指令進行計數,然後採用最差的執行路徑,並且使用該芯片的頻率可以實時執行。那在理論上,是否有任何工具,技巧或程序讓它更容易一些?

更新:

我不能共享機密的原因源。此外,我一直在深入挖掘,發現主要的延遲,顯然是由隊列大小產生的。大多數隊列是爲了保存2或3條消息而創建的。我需要做一些測試,以便在這裏提供更多信息。理論上,如果隊列被填滿,那麼剩下的進程不能再發送,直到再次有空閒空間用於更多消息。然後進程暫停,導致連續的重新調度。我的想法是將隊列大小增加到10,以查看它是否提高了性能和時間。

更新2 從建議中,我發現他們非常有幫助的,當我在黑暗中開始,我碰到了一個名爲「理解」它不是免費的工具,而是幫助我得到的分析和字符。您也可以看到複雜函數的字符流,因此您可以看到執行流程的最長路徑。

+0

這個問題是非常通用的。我很懷疑你會得到任何有用的答案(通用或不),而不提供一些更具體的細節。我可以建議你的主線程代碼開始嗎? –

+0

模擬?遠程調試? – Yakk

+1

研究「分析」。 –

回答

3

在這裏拋出一個答案,因爲搖滾比賽是有史以來最好的比賽之一。這就是說...

從你的措辭這裏聽起來像你正在測量的任務,絕對必須使其截止日期是最低優先級。那就是倒退。你希望你的任務需要保證它的完成作爲最高優先級的任務。那將是第一步。 如果我從我如何閱讀你的問題和你的線程中弄錯了,那麼需要讓這些最後期限成爲最高優先級,那麼還有其他事情要看。

確保中斷不會被任何其他任務長時間禁用,因爲這會影響線程調度。如果一個低優先級任務禁止中斷,然後在一個循環中旋轉一段時間,RTOS調度程序就無法取回控制權並將其提供給高優先級線程。

檢查優先倒置(http://en.wikipedia.org/wiki/Priority_inversion)。如果您的低優先級線程和此關鍵線程之間存在資源共享,那麼您可以進入一種情況,即使您的關鍵線程具有高優先級,它可能會阻止等待較低優先級線程完成使用資源。不確定FreeRTOS是否具有優先互斥/信號量,但這也是您可以檢查的。

另一件可能是最簡單的解釋是分析線程。這在嵌入式系統中很難做到,但是你可以製作某種光記錄緩衝器或類似的東西。找出什麼時候它有時會錯過它的最後期限那段代碼路徑與它使它成功的時間有什麼不同。你可能需要找到一種方法來加速這一路徑。例如,在運行緩慢的情況下,它可能會寫入比正常數據量更大的數據,因此可能會更改這些數據寫入以使用DMA而不是手動寫入線程。

這不是一個詳盡的清單,但一些好的提示開始。

+1

FreeRTOS實際上直接處理優先級反轉問題,如果一個較高優先級的任務在互斥量上被阻塞,則互斥可以暫時提高任務的優先級。 –

+0

好的很酷。在我發佈這個消息之後,我實際上看了一會兒。雖然這一直很好,但我認爲就像FreeRTOS上的文檔所說的,優先級繼承只是一個bandaid,特別是如果您需要真正的RT可靠性。設計完全不必使用它 – ThePosey

相關問題