常用於RTOS（VXworks）的設計模式

任何人都可以幫助我瞭解常用於RTOS的設計模式嗎？
在VXworks中，哪種模式更可取？常用於RTOS（VXworks）的設計模式

2010-05-10 Sijith

方式。太。通用。 ...我說這是一個以前的VxWorks用戶。膝蓋混亂的答案是「任何模式解決問題。」 – 2010-05-10 04:24:22

更喜歡什麼！？每種模式都有不同的用途，它們不可互換。使用解決問題的人 – Clifford 2010-05-10 18:43:41

我不確定這個問題是否值得贊成，但我建議您根據我的建議對其進行修改，以防止其他合理的問題得到不好的分數。 – Clifford 2010-05-28 08:35:37

我們可以忽略你的問題，第二句？這是沒有意義的，也許是對設計模式的誤解。然而，第一部分很有趣。也就是說，我將其推廣到覆蓋實時系統而不是RTOS。

許多最熟悉的模式是機械的，但在實時系統中更高層次的架構模式也很重要。

Bruce Powell Douglass可能是對的模式進行實時系統這一主題的最重要作者。如果你想要的是什麼，他不得不在隨後的Embedded.com閱讀this article主題說的味道（這是三個系列的第三部分，請務必仔細閱讀前兩個爲好，因爲他們還對主題觸摸，(1)(2) ）。您也可以訪問Embedded.com並在搜索框中輸入「設計模式」，還有一些關於該主題的特定模式和一般文章的文章。

儘管我認爲您對「RTOS（VxWorks）」的請求模式的要求很高，但我特別使用的VxWorks模式是Facade和Adapter模式。部分提供OO API，並提供一定級別的RTOS不可知抽象。隨後爲Segger emBOS實現了最終的類（以允許我們運行更小，成本更低，免版稅的RTOS），並且Windows和Linux都允許在更強大的工具的更豐富的環境中測試，調試和模擬代碼。設置在Wikipedia，其中許多將適用於實時系統

的非窮盡很多模式的列表。列出的併發模式最爲明顯。

來源

2010-05-10 18:42:53 Clifford

正如Mike DeSimone所評論的那樣，過於通用。但是，對於RTOS（不僅僅是VxWorks），要記住幾件事情。

避免做過多的ISR。如果可能的話，將一些處理傳遞給等待的任務。
保持多線程最佳。太多，你有背景切換的開銷。太少，你的問題解決方案可能會很複雜。

來源

2010-05-10 04:30:04

+1。第一個實際上是RTOS的設計模式，但也是其他操作系統驅動程序。有人應該想出一個好名字和一個適當的模式描述。（即：你什麼時候需要它，準確地做什麼，等等） – MSalters 2010-05-10 10:44:38

許多操作系統中的第一個項目被稱爲「延期服務程序」。 – 2010-05-10 20:41:51

eCos將它們稱爲中斷服務例程和延期服務例程。 Linux調用然後是上半部分和下半部分，IIRC。但是這些不是RTOS的模式......這些模式是用於*驅動程序的。* – 2010-05-11 18:20:55

另一個重要方面是讓RTOS保持可預測性並且可以讓用戶理解。通常情況下，您會看到固定優先級的調度程序不會公平或不具有適應性，而是完全按照所講的方式執行，如果您搞砸優先級並捱餓某些任務，那就這樣做吧。完成內核操作的時間往往很短並且可以預測，通常記錄下它們最糟糕的執行時間。

來源

2010-06-09 18:30:23 jakobengblom2

常用於RTOS（VXworks）的設計模式

回答

相關問題