|
闡述μC/OS-II多任務信息流關鍵技術與中斷處理的一般方法和PC體系中斷的基本概念；以CAN總線為例，詳細分析在x86實模式下基于μC/OS-II的CAN總線驅動的實現過程。 μC/OS-II是美國人Jean Labrosse編寫的一個免費的、源碼公開的嵌入式實時內核。對于開發計算機嵌入式應用產品的技術人員來說是一個實用價值很高的實時嵌入式操作系統ERTOS（Embedded Real Time Operation System）。 要開發出完善的ERTOS，就要在多任務的調度和對I/O設備操作的穩定性、協調性方面做出大量的工作，這也是我在開發ERTOS過程中深深體會到的重點所在。希望本文能對開發ERTOS的技術人員在多任務信息流和I/O驅動方面有所啟迪。 1 多任務信息流關鍵技術 在討論多任務信息流之前，先討論一下多任務的工作狀態。在μC/OS中，每個任務都是無限循環的，每個任務都處在以下五種狀態之一： 休眠態、就緒態、運行態、掛起態和中斷態，如圖1所示。 在多任務的調度和驅動程序的編寫過程中，必然要涉及到公用代碼段和共享存儲區的保護問題。即使是原有的C函數，可重用性方面在沒有得到理論和實踐的驗證情況下也需要對其進行保護。這樣就需要合理的算法對公用代碼段、共享存儲區進行保護，避免操作系統在運行過程中產生重用性問題而導致運行結果不可預測。 系統在開發過程中，既要考慮到減少系統的復雜程度，也要兼顧其穩定性與運行效率的要求。這就需要我們對各種算法進行合理的選擇：在穩定性可以保障的情況下，選擇相對簡單，占用CPU時間少的算法；在穩定性不能保障的情況下，考慮選擇周全的算法。只有這樣才能使操作系統在一定的配置環境下達到最高的運行效率。 接下來分別用void CanSendMessageProcess(void *data)、void CanSendMessage(void *data)、void CanReceiveMessageProcess(void *data)和void CanReceiveMessage(void *data)這四個任務來描述在采用消息隊列、郵箱和信號量通信機制時的信息流的傳遞過程。 （1）消息隊列通信機制 消息隊列在初始化的時候，建立一個指定空間大小的數組，這個數組在使用的時候取得了環形緩沖區的概念。這個數組在運行期間不會被消除，這樣就避免了重復建立數組的時候內存空間的泄漏問題。當一個任務向消息隊列發送一個信息的時候，相應的指針加1（OSQIn+1），隊列滿時(OSQEntries = OSQSize)，OSQIn則與OSQOut指向同一單元。如果在OSQIn指向的單元內插入新的指向消息的指針，就構成FIFO（First-In-First-Out）隊列。相反，如果在OSQOut指向單元的下一個單元插入新的指針，就構成LIFO隊列（Last-In-First-Out）。在本實例中，我們定義FIFO隊列。消息指針總是從OSQOut指向的單元取出。OSQStart和OSQEnd定義了消息指針數組的頭和尾，以便在OSQIn和OSQOut到達隊列的邊緣時，進行邊界檢查和必要的指針調整，實現其循環功能。 消息隊列數據結構如下： typedef struct os_q { struct os_q *OSQPtr; /* 在空閑隊列控制塊中鏈接所有的隊列控制塊*/ void *OSQStart; /*指向消息隊列的指針數組的起始地址的指針*/ void *OSQEnd; /* 指向消息隊列結束單元的下一個地址的指針*/ void *OSQIn; /* 指向消息隊列中插入下一條信息位置的指針*/ void *OSQOut; /* 指向消息隊列中下一個取出消息位置的指針*/ INT16U OSQSize; /* 消息隊列中總的單元數*/ INT16U OSQEntries; /*消息隊列中總的消息數量*/ } OS_Q; 圖2為消息隊列信息流的演示說明。 ① CanSendMessageProcess任務完成信息的計算工作以后，將要發送的信息送進消息隊列1。 ② CanSendMessage任務負責取得消息隊列1里面的信息。 ③ 通過CAN總線I/O端口將數據發送到總線上去。如果消息隊列中沒有信息，則該任務由運行狀態進入等待狀態，直到從消息隊列中接收到信息為止。 ④ CanReceiveMessage任務負責讀取總線上面的信息。 ⑤ CanReceiveMessage任務將讀取到的信息送入消息隊列2。 ⑥ CanReceiveMessageProcess任務是從消息隊列2中取出信息開始計算工作，如果消息隊列為空的話，該任務進入等待狀態。 消息隊列適用于一對一、一對多、多對多和多對一的關系。也就是說，消息隊列可以作為一塊共享的公共區域，為實施互斥，任務間需要同步；為了合作，進程間需要交換信息，這樣也就實現了同步和通信。 （2）郵箱通信機制 郵箱的概念和管道（管線）有相似的定義，一個任務或者中斷服務子程序向另一個任務發送一個指針型的變量，該指針指向一個包含了特定“消息”的數據結構。在源端的任務只能向郵箱寫，在目的端的任務只能從郵箱讀。郵箱傳輸流數據，即連續的字節串或流。因此，訪問一個郵箱就像是訪問一個順序文件。郵箱可以用來通知一個事件的發生（發送一條信息），也可以用來共享某些資源，這樣郵箱就被當成一個二值信號量。 圖3為郵箱信息流的演示說明。 ① CanSendMessageProcess任務將計算好的數據發送給CanSendMessage任務，然后進入就緒態等待應答信號。CanSendMessage在接收的同時發送應答握手信號給CanSendMessageProcess，確認信息接收完畢。 ②CanSendMessage任務將CanSend MessageProcess任務發送來的信息發送到CAN總線，發送結束后進入就緒態等待下一次傳輸工作。 ③ CanReceiveMessage任務接收來自總線的信息流，將接收到的信息發送到Can ReceiveMessageProcess任務，進入就緒態等待應答信號。 ④ CanReceiveMessageProcess任務收到信息后發送應答握手信號。 （3）信號量通信機制 信號量（semaphore）是一種約定機制：兩個或多個任務通過簡單的信號進行合作，一個任務可以被迫在某一位置停止，直到它接收到一個特定的信號。在多任務內核中普遍將信號量用于： ◇ 標志某事件的發生； ◇ 控制共享資源的使用權（滿足互斥條件）； ◇ 使兩個任務的行為同步。 信號量主要實施三種操作： ◇ 一個信號量可以初始化為非負數； ◇ 等待（wait）操作使信號量減1。如果值變成負數，則執行等待的任務被阻塞。 ◇ 得到CPU使用權的任務singal操作使信號量加1。如果值不是正數，則被等待操作阻塞的任務被解除阻塞。 為了滿足信息傳遞過程中實時高效的原則，在消息隊列中部分地引入信號量的概念。也就是CanSendMessageProcess任務，把若干個字節的信息一次性地發送到消息隊列，令信號量加1并由運行態進入等待掛起狀態。在CanSendMessage任務獲得信號量后進入就緒態，等待CPU的使用權進入運行態。進入運行態后，該任務使信號量減1并從消息隊列中取出信息后通過I/O端口發送到CAN總線。CanReceiveMessage任務和CanReceive MessageProcess任務執行與上面相反的操作。這個實例說明了信號量用于標志某事件的發生。（見圖2。） 2 μC/OS-II的中斷處理 μC/OS-II中，中斷服務程序一般用匯編語言來寫。以下是中斷服務程序的示意代碼。 用戶中斷服務程序: 保存全部CPU寄存器； 調用OSIntEnter或OSIntNesting直接加1； 執行用戶代碼做中斷服務； 調用OSIntExit； 恢復所有CPU寄存器； 執行中斷返回指令； 這里μC/OS-II提供了兩個ISR與內核的接口函數：OSIntEnter和OSIntExit。OSIntEnter通知μC/OS-II內核，中斷服務程序開始運行了。實際上，此函數做的工作是把一個全局變量OSIntNesting加1。在x86等有累加指令的CPU中，可以用指令代替OSIntEnter： INC BYTE PTR OSIntNesting 此中斷嵌套計數器可以確保所有中斷處理完成后再作任務調度。另一個接口函數OSIntExit則通知內核，中斷服務已結束。根據相應情況，返回被中斷點（可能是一個任務或者被嵌套的中斷服務程序）或由內核作任務調度。 用戶編寫的ISR必須被安裝到某一位置，以便中斷發生后，CPU根據相應的中斷號運行準確的服務程序。許多實時操作系統都提供了安裝、卸載中斷服務程序的API接口函數，有些成熟的RTOS甚至對中斷控制器的管理都有相應的API函數。但 μC/OS-II內核沒有提供類似的接口函數，需要用戶在對應的CPU移植中自己實現。這些接口函數與具體的硬件環境有關，接下來PC體系下的中斷處理對此有詳細的說明。 3 PC體系下的中斷 X86系列的處理器可支持256個中斷，并用向量表的方法來關聯每個中斷和相應ISR的位置。在實模式下，中斷向量表（IVT）存于內存的低端1K。每個向量表條目占4字節，保存一個ISR的段地址和偏移信息。PC系統使用兩個級聯的可編程中斷控制器82C59A。一個82C59A能連接8個硬件中斷，編號為IRQ0"IRQ7。 PC總共可管理15個外部中斷源，PC的中斷控制器如圖4所示。（關于82C59A的詳細使用可參見有關資料。） 在μC/OS下，CAN總線I/O端口中斷向量設置偽代碼： void CanInitHW(UI segment,BYTE Irq0,BYTE Irq1){ 保存原有的中斷向量 保存掩碼寄存器的值 使82C59A的掩碼寄存器（0x21）各位置1，關閉中斷輸入 關閉CPU中斷 設置新的中斷向量 正在服務的中斷禁止再次響應服務(假定當前服務中斷是IRQ5) 開CPU中斷 清除82C59A的掩碼寄存器（0X21、0XA1）各位，開啟中斷輸入 } 4 信號量與緩沖隊列支持下的CAN總線驅動 前面介紹了μC/OS-II內核下多任務調度的關鍵技術、中斷與PC體系下中斷的一般方法。又以82C59A的中斷5（IRQ5）、0x0D中斷向量為例，介紹了中斷服務子程序的重新分配和響應SJA1000控制器收發的中斷服務子程序。 下面介紹信號量配合下的環形緩沖隊列與中斷處理程序之間的關系問題，這也是設備驅動部分的核心內容。 ERTOS的驅動程序與其它操作系統有所不同。比如Windows、Unix、Solaris、Linux等操作系統弱化了設備的概念，用戶進程對設備的使用可以通過文件系統來完成。然而，在μC /OS-II上開發CAN總線驅動程序沒有那么嚴格，只要滿足設備在連續的CPU時間上使用時不發生時間重疊就可以了。 串行設備或者其它字符型設備都存在外設處理速度和CPU速度不匹配的問題，所以需要建立相應的緩沖區。向CAN口發送數據時，只要把數據寫到緩沖區，然后由SJA1000控制器逐個取出往外發。從CAN口接收數據時，往往等收到若干個字節后才需要CPU進行處理，所以這些預收的數據可以先存于緩沖區。緩沖區可以設置收到若干個字節后再中斷CPU，這樣避免了因為CPU的頻繁中斷而降低系統的實時性。 在對緩沖區讀寫的過程中，經常會遇到想發送數據時，發送緩沖已滿；想去讀時，接收緩沖卻是空的。對于用戶程序端，可以采用查詢工作方式，即放棄無法讀寫的操作，然后再頻繁地去嘗試這個操作直到成功，這樣程序效率顯然降低。如果引入讀、寫兩個信號量分別對緩沖區兩端的操作進行同步，問題將迎刃而解。用戶任務想寫但緩沖區滿時，在信號量上睡眠，讓CPU運行別的任務，待ISR從緩沖區讀走數據后喚醒此睡眠的任務；類似地，用戶任務想讀但緩沖區空時，也可以在信號量上睡眠，待外部設備有數據來了再喚醒。由于μC/OS-II的信號量提供了超時等待機制，CAN口當然也具有超時讀寫能力。 接口函數總結如下。 void CanInitHW(UI segment,BYTE irq0,BYTE IRQ1) /*設置SJA1000控制器端口中斷向量*/ int canReleaseHW() /* 清除SJA1000控制器端口中斷向量*/ int canSendMsg( CANBYTE port, MSG_STRUCT msg) /* 向定制SJA1000控制器端口發送數據*/ int canReceiveMsg( CANBYTE port, MSG_STRUCT msg_ptr) /*從定制SJA1000控制器端口接收數據 int canConfig( CANBYTE port, CAN_STRUCT can) /*初始化和配置SJA1000控制器 */ int canNormalRun( CANBYTE port ) /*設置SJA1000正常(Normal)運行模式 */ int canReset( CANBYTE port ) /* SJA1000控制器端口重新設置，緩沖區置位0xff*/ CANBYTE can0r( CANBYTE addr) /*讀取SJA1000控制器端口0的定制寄存器的值 */ CANBYTE can1r( CANBYTE addr) /*讀取SJA1000控制器端口1的定制寄存器的值 */ 接收和發送數據緩沖區數據結構定義： typedef struct { INT16U RingBufRxCtr; /* 接收緩沖中字符數目 */ OS_EVENT RingBufRxSem; /* 接收信號量 */ INT8U RingBufRxInPtr; /* 接收緩沖中下一字符的寫入位置 */ INT8U RingBufRxOutPtr; /* 接收緩沖中下一待讀出字符的位置 */ INT8U RingBufRx[CAN_RX_BUF_SIZE]; /* 接收環形緩沖區*/ INT16U RingBufTxCtr; /* 發送緩沖中字符數目 */ OS_EVENT *RingBufTxSem; /* 發送信號量 */ INT8U *RingBufTxInPtr; /* 發送緩沖中下一字符的寫入位置 */ INT8U *RingBufTxOutPtr; /* 發送緩沖中下一待讀出字符的位置 */ INT8U RingBufTx[CAN_TX_BUF_SIZE]; /* 發送環形緩沖區*/ } CAN_RING_BUF; 結 語 本文是在嵌入式計算機技術領域的應用背景下提出的，整個工程開發結束以后，系統正常運作時間超過27天。希望本文的提出對開發嵌入式操作系統的技術人員能有所幫助，同時也希望同一領域的開發人員共同探討、共同發展。 |
