2011-02-23 10:20:58
分享到：
首先，我想給這兩種方法乙個較為「貼切」的定義，對於
fifo處理方法，一般稱之為「非同步雙緩衝」；對於第二種方法，則稱為「即時狀態處理」
對於「非同步雙緩衝」方法來說，其根本思想是占用最小的系統時間完成資料的接收，而
處理部分及其實時性的保證則由其他任務（裸機模式下主迴圈中的任務或者作業系統模
式下某個對應的任務）來處理。這種情況下，串列埠被作為一種資源，中斷處理程式負責
簡單的採集資源，採集的過程與實際應用是剝離的。應該說，非同步雙緩衝模式的耦合度
最小，因此對於資源的消費者來說，資源採集自何方，如何採集並不重要，是透明的。
因而符合系統模組化的需求。從實時性的角度來說，資源的採集事件是乙個實時性要求
較高的事件，但是資源的處理往往並不緊急，因此在乙個緊急的採集事件中做不那麼緊急
的資料處理，實在是一種不明智的選擇。因此，在大多數情況下，非同步雙緩衝模式是乙個
值得推薦的方法。
但是，當我們說「大多數情況」這樣的限定時，往往存在較為特殊的情形。這也就是即時
狀態處理大顯身手的狀況：即：資料採集是緊急事件，資料的處理也是緊急的事件。或者
資料的處理本身由緊急的前期處理和非緊急的後期處理兩部分組成。或者資料的採集本身
是受到控制的，即採集的過程是緊急的，資料的處理分為緊急和非緊急兩部分，但是如果
不處理完，就不會繼續採集資源——對於這種情況，通常將資料的處理放在資料採集中，
因為分開反而意義不大。據乙個例子：上位機傳送給下位機的資料是存在某種簡單的幀結構
的，而這一幀結構對於資料處理程式來說「必須是透明的」——也就是說，資料處理程式
需要的是幀結構裡面的一部分資料（也就是幀所包裝的內容），那麼，我們說，這類情況下
資料的採集是緊急的，楨解析如果本身不複雜，也可以詩作允許放在緊急任務中處理的，而
解寶以後的資料，則可以放到fifo中，留給主迴圈慢慢享用——當然你要說，如果我全部用
fifo接收下來，然後主迴圈做乙個任務來解包不也可以麼？這還是有區別的，因為幀的作用
就是包裝資料，如果通訊環境不穩定，幀容易出錯，或者幀之間有其它資料（比如某些匯流排
環境下，復合幀傳輸）那麼，無用的資料就會給fifo以及系統任務帶來負擔；如果在資源採集
的時候花費較小的代價進行簡單的資料提取（過濾），比如，等待幀頭部，否則所有資料丟棄，
則可以大大降低系統綜合的開銷。
綜上所述，要根據具體的系統要求，選取其一，或者綜合。簡單的下結論都是不好的。選擇的
原則，就是要搞清楚，哪些任務是緊急的，哪些不是。避免在緊急事件處理程式中做不緊急的
事情。如果資源處理程式某些部分緊急，某些部分次要，那麼應該嘗試分為兩個子任務。
第6章 中斷和中斷處理程式 學習筆記
1 硬體傳送乙個中斷碼給cpu，該中斷碼被稱為中斷請求線 2 中斷服務例程 isr 他是裝置驅動程式的一部分，裝置驅動程式是用於管理裝置的核心 isr是被核心呼叫來響應中斷的，它執行於中斷上下文 3 中斷上下文 如網絡卡接收到資料告訴核心包到了，網絡卡在等核心的回答 同時網絡卡還有優化吞吐量等工作要...
8086中斷知識以及編寫0號中斷處理程式
int n指令的格式為 int n，n為中斷型別碼 cpu執行int中斷，實際上就相當於引發乙個n號中斷的中斷過程，他的大致執行過程如下 取中斷型別n 標誌暫存器入棧，置if 0,tf 0 為什麼要這一步，後面有解釋 這一步可以模擬為 pushf 標誌暫存器入棧 下面的步驟完成置if和tf push...
Linux2 6 中斷處理函式和申請中斷函式的變化
linux2.6 中斷處理函式和申請中斷函式的變化 2009 07 29 08 46 今天練習了中斷。linux裝置驅動開發技術及應用 作者使用的是2.6.4，現在看來也很古老了，按照書上的例子，免不了很多錯。例如 裡 自己定義的中斷處理函式 irqreturn t int interrupt in...