1 引言

　　μC/OS-II是由美國人Jean Labrosse 編寫的一個源碼公開的嵌入式實時操作系統內核。它從1992年開始為人所知。μC/OS-II是一種占先式的多任務操作系統，可固化，可裁減，移植性好。μC/OS-II功能強大，支持56個用戶任務，支持信號量、消息郵箱、消息隊列等多種常用的進程間通信機制，現已成功應用到眾多商業嵌入式系統中，其穩定性與可靠性已經得到檢驗［1］。

　　各類電動車的研究與開發目前在國內已經掀起了高潮，國家、地方以及越來越多的汽車公司都投入到這個前途光明的朝陽產業的研究中。混合動力電動車、燃料電池純電動車是當前研發的主要方向。蓄電池不可避免地成為電動車輔助能源。鎳氫電池、鋰離子電池等因為其容量大、體積小、動力性較好而成為目前電動車研發的首選動力電池。對電池的過充電過放電很容易造成電池的損壞，并大大降低電池壽命。而如何能根據所用電池的特性，對其安全有效的使用即電池管理系統（Battery Management System，BMS）的設計成為關鍵。BMS負責實時地估測當前的電池容量，即荷電狀態（State of Charge，SOC），以及對各電池組進行電壓均衡，判斷是否出現不正常電池單元，并發送報警信號。SOC估測方法的準確性已成為電動車研發的瓶頸之一，在世界范圍內都未取得重大突破。限于篇幅，本文對SOC估測方法不做詳細介紹，而主要描述電池管理系統的軟硬件實現。

　　2 BMS的構成與硬件實現

　　2.1 基于光纖CAN總線的電動車分布式控制系統

　　電池管理系統BMS是電動車控制系統的組成部分之一。控制局域網CAN總線因為其結構簡單，通信方式靈活，抗干擾能力強，目前已經在工業控制，汽車電子領域得到了廣泛的應用。CAN總線最初即是德國的Bosch公司為汽車的監測、控制系統而設計的。CAN網絡在電動車上的應用能使得各電控單元（ECU）之間的通信極為方便。如果通信介質采用光纖，那么通信介質上的干擾將被完全消除。本文所描述的對電池管理系統的研究是燃料電池電動車研發的子課題。電池采用的是容量為12安時（AH）的鎳氫電池。

　　電動車控制系統一般包括能量流管理系統，電機控制器，燃料電池控制器，顯示系統，電池管理系統等，若為混合動力車，還應包括發動機控制器等其他控制器。本文所描述的鎳氫電池管理系統ECU（Electronic control unit）與這些控制系統采用光纖構成上層CAN網。而電池管理系統ECU又與24組電池組信息檢測ECU構成下層CAN網絡。我們所采用的鎳氫電池每個基本電池單元提供1.2V左右的電壓，10個單元串聯構成一個電池組，24個電池組再串聯產生約280V的高電壓，作為車用輔助電源。設計的電池管理系統BMS及電動車控制系統基本結構如圖1所示。

　　2.2 電池管理ECU的硬件方案

　　電池管理ECU采用TI公司的TMS320LF2407 DSP作為其CPU。主要原因在于其體積小，處理速度快，片內集成了A/D模數轉換器和CAN總線控制器［2］。如圖1所示，電池管理ECU需要兩個CAN控制器。DSP內部集成的CAN控制器（CAN1）接上層光纖CAN網絡；我們為系統另外擴展的Philip公司的SJA1000獨立CAN控制器（CAN2）作為與下層電池組CAN網絡通信用。電池管理ECU的結構框圖如圖2所示。

　　由于DSP的數據和地址線是分開的，而SJA1000的數據和地址線是分時復用的。其相互接口是本系統的難點之一。可通過將SJA1000映射為DSP的I/O地址，通過模擬SJA1000的讀寫時序對其進行讀寫訪問。

　　3 采用前后臺系統的軟件設計方法

　　在前后臺系統中，應用程序被設計成一個無限的循環，循環中調用相應的函數完成相應的操作，這部分可看作是后臺行為。中斷服務程序處理異步事件，這部分可看作是前臺行為。后臺行為也稱作任務級，前臺也稱作中斷級。時間相關性很強的工作一般是靠中斷服務子程序來保證的。中斷服務所提供的信息（如標志）一直要等到后臺程序（即循環）運行到處理該信息這一步時才能得到處理。這中間的時間間隔稱任務級響應時間。這個時間具有不確定性，有時候會很長。可見前后臺系統的實時性較差。

　　本系統的軟件須完成的主要功能包括：中斷方式接收24個電池組的ECU通過下層CAN總線傳出的電壓與溫度信息，并對數據進行處理；定時采樣電池的總電壓與電流（采樣頻率越高則SOC估測效果越好）；通過電壓、電流、溫度等信息通過一定的算法計算電池SOC值；每隔50ms通過上層光纖CAN總線向控制系統中其他CAN節點發送一次SOC值以及其他信息；每隔1s通過上層光纖CAN總線發送一次所接收的電池組的電壓溫度信息;對電壓偏高或偏低的電池組進行電壓均衡；監測不正常情況，隨時發送報警信號。

　　若采用前后臺的方法對本系統進行軟件設計，有兩種方案供選擇。其一，可以將所有的工作都在后臺的無限循環中處理，中斷服務服務程序只提供標志信息。這樣也就會出現上文所述的任務級響應時間的不確定性，實時性較差。其二，可以將大部分的工作，如A/D采樣，SOC算法，CAN數據發送等系統中大部分的工作都在中斷服務程序中處理。這種方法看起來實時性很好，但由于處理中斷服務程序的時間較長，關中斷的時間也就較長，所以不可避免的會引起中斷事件的頻繁丟失。

　　而若采用μC/OS-II操作系統進行軟件設計，則所有的函數與任務的處理與執行時間具有可確定性，因而系統的可靠性將大大提高。下文筆者將詳細介紹嵌入式實時多任務操作系統μC/OS-II的移植與應用。

　　4 移植 μC/OS-II

　　TMS320LF2407滿足μC/OS-II移植的條件［3］。TI公司提供的編譯軟件Code Composer V4.10.36也支持C語言與匯編語言混合編程［4］。筆者即在此編譯器中進行μC/OS-II移植。

　　μC/OS-II操作系統的組成文件分為三類，一類是與處理器無關的代碼文件，另一類是處理器有關的代碼文件以及μC/OS-II與應用相關的設置文件。當然移植工作完成后編寫應用程序，還應包括應用文件。移植所需要做的工作僅僅是修改部分與處理器有關的文件。這類文件包括：OS_CPU.H，OS_CPU_A.ASM，OS_CPU_C.C等三個文件。限于篇幅，本文僅描述移植過程的重點與難點。

　　TMS320LF2407 芯片本身的堆棧只有8級，從AR0到AR7。該C編譯器將內部寄存器AR0、AR1保留，AR1作為堆棧指針SP，AR0被作為堆棧中的臨時變量指針FP。所以在匯編語言中不要使用這兩個寄存器，若一定要用，必須關中斷，并注意保存和恢復。TI公司的Code Composer 編譯軟件里，中斷要調用I

　　SAVE保存所有寄存器，各寄存器壓入堆棧的先后順序為：空字、，ST1、ST0、ACCH、ACCL、PREGH、PREGL、TREG、AR0、AR2、AR3、AR4、AR5、AR6、AR7、TOS、6個硬件堆棧，共22個。返回時“跳轉”到ISAVE保存所有寄存器，各寄存器壓入堆棧的先后順序為：空字、，ST1、ST0、ACCH、ACCL、PREGH、PREGL、TREG、AR0、AR2、AR3、AR4、AR5、AR6、AR7、TOS、6個硬件堆棧，共22個。返回時“跳轉”到I

　　REST函數，恢復這些寄存器的值，順序與I

　　SAVE相反。這里用“跳轉“而不是調用，是因為ISAVE相反。這里用“跳轉“而不是調用，是因為I

　　REST執行完后不一定能返回到開始執行時的地址。

　　改寫OSTaskStkInit（）：該函數任務堆棧初始化函數，在創建任務的時候被調用。TMS320LF2407的堆棧是從低地址往高地址遞增的。該函數首先獲取該任務棧的棧頂地址。然后對該地址進行遞增并賦初值。從棧頂地址開始的前兩個地址分別裝載棧頂地址，數據區地址，第三個地址保留。后面依次為上述寄存器值，從ST1到TOS，TOS裝載的是中斷的返回地址或任務起始地址，后面再保留6個硬件堆棧地址。該函數返回堆棧指針值，即最尾的地址。

　　改寫OSStartHighRdy（）：該函數啟動最高優先級的任務。將當前就緒的最高優先級任務的堆棧指針賦于AR1，跳轉到I

　　REST函數，即可轉到最高優先級任務的起始地址。改寫OSCtxSw（）：該函數進行任務間切換，為OSSched（）函數所調用。任務切換用8號軟中斷來實現。第一步：調用IREST函數，即可轉到最高優先級任務的起始地址。改寫OSCtxSw（）：該函數進行任務間切換，為OSSched（）函數所調用。任務切換用8號軟中斷來實現。第一步：調用I

　　SAVE函數壓棧。第二步：為將當前原任務的堆棧指針保存到當前原任務的任務控制塊（TCB）中；將處于就緒態的最高優先級新任務TCB地址賦給當前TCB；新任務的優先級賦給當前優先級；將新任務TCB中的堆棧指針賦給AR1。第三步：跳轉到I$$REST。

　　改寫OSIntCtxSw（）：該函數只能在中斷子程序中被OSIntExit（）函數調用。由于中斷可能會引起任務切換，所以在中斷服務程序的最后調用OSIntExit（）來檢查是否需要進行任務切換。若有比被中斷任務的優先級更高的任務處于就緒態，則調用此函數進行任務切換。該函數首先通過執行POP指令彈出調用OSIntCtxSw（）時的返回地址，然后調整堆棧指針，然后轉到OSCtxSw（）函數的第二步執行。要調整堆棧指針的原因是在調用OSIntExit（）時保存了返回地址和幀指針等相關的值，所以在進行任務切換前必須將先前任務的指針值恢復到中斷前的位置。通過查看進中斷后堆棧指針AR1的變化，我們發現程序運行到任務切換時，AR1增加了5個地址，故需要在此函數中將AR1減5，以恢復被中斷前任務堆棧的指針。

　　改寫OSTickISR（）：時鐘節拍中斷服務子程序，可采用定時器1周期中斷作為系統時鐘節拍，這部分編寫沒有什么難點。但要注意的是一定不要在調用中斷嵌套加1函數OSIntEnter（）之前開中斷。因為這樣可能導致直接從非最后層的高優先級中斷里切換到任務，這將導致致命后果，程序再也不能進某中斷。

　　改寫OS_CPU.H，關鍵語句如下：

　　#define OS_STK_GROWTH 0

　　#define OS_ENTER_CRITICAL（） asm（“SETC INTM”）;

　　#define OS_EXIT_CRITICAL（） asm（“CLRC INTM”）;

　　#define OS_TASK_SW（） asm（“INTR 8”）;

　　按需配置OS_CFG.H。至此，μC/OS-II在TMS320LF2407上的移植就基本完成了。最后的工作是對部分代碼進行改寫和優化，從而提高運行速度，減少代碼空間。本文對此不進行描述，讀者可自行嘗試處理。

　　5 應用程序改寫

　　在本應用中，筆者建立了四個應用任務，優先級分別為4、5、6、7。同時為每個任務分配了一個消息郵箱，使用基于消息郵箱事件的通信機制進行任務間通信與任務切換。整個軟件的基本結構如圖2所示。

　　任務AdQTask（）：采樣總電壓、電流信號，并對電池進行容量（電量）累積。分配郵箱：pAdQMbox。

　　任務SocTask（）：進行電池的SOC算法。分配郵箱：pSocMbox。

　　任務SendTask（）：通過DSP內部CAN發送SOC值以及電池電壓溫度信息。分配郵箱：pSendMbox。

　　任務SjaRxTask（）：對從SJA1000接收過來的電池組信息進行處理與故障診斷。分配郵箱：pSjaRxMbox。

　　由上節對堆棧的分析可看出，任務棧最少需要25個地址。筆者為每個任務分配了100個地址（200個字節）的任務棧空間。使用函數OSTaskCreate（）進行創建各任務，該函數的第三個參數為棧頂地址，為OSTaskStkInit（）所調用。要注意TMS320LF2407的堆棧是遞增的，故應傳遞任務棧的最低地址。而又由于任務程序是采用C語言編寫，編譯器對AR1的偏移范圍可能會超過任務棧棧頂。雖然在這種情況下AR1是可恢復的，但仍可能會影響最低地址之前的地址內容。所以筆者建議對其進行適當后移。

　　中斷1為SJA1000從CAN總線上接收到數據所引發。在中斷1中讀取SJA1000緩沖區的數據，然后向郵箱pSjaRxMbox發送標志信號。在中斷處理完后即可到任務SjaRxTask（）執行。

　　中斷2為定時器1周期中斷。周期設為1ms。每10ms做一次時鐘節拍。每個周期1ms向郵箱pAdQMbox發送數據1（標志信號），以使AdQTask（）任務列為就緒態，中斷退出時若其為最高優先級任務則轉到該任務執行。每50ms發送數據2，以就緒AdQTask（）任務和SocTask（）任務。每1s發送標志數據3，以就緒AdQTask（）任務，SocTask（）任務和SendTask（）任務。

　　各任務均等待相應郵箱以及相應標志信號。任務恢復后判斷郵箱中的標志信號，從而轉到相應的功能程序中。

　　下面列舉SjaRxTask（）任務與中斷1的中斷服務程序的簡化代碼來描述μC/OS-II的郵箱通信機制，供讀者參考。

　　void SjaRxTask（void data） /*接收任務*/

　　{ INT8U *FlagSjaRx=0;

　　INT8U error;

　　data=data;

　　while（1） {

　　FlagSjaRx=OSMboxPend（pSjaRxMbox，1，&error）; /*等待郵箱中的消息*/

　　if（*FlagSjaRx） /*判斷標志信號是否為1*/

　　SjaRxProcess（）; /*接收數據處理函數*/

　　}

　　}

　　void c_int1（） /*SJA1000的中斷服務程序*/

　　{ OSIntEnter（）; /*中斷嵌套層加1*/

　　count=1; /*標志信號置1*/

　　…… /*讀取SJA1000緩沖區的數據，代碼省略*/

　　OSMboxPost（pAdQMbox，（void*）&count）; /*發送標志信號*/

　　…… /*清中斷標志并釋放SJA1000緩沖區，代碼省略*/

　　OSIntExit（）; /*檢查是否需進行任務切換，若需要，則進行切換*/

　　asm（“ CLRC INTM ”）; /*開總中斷*/

　　}

　　6 結語

　　如今，PC時代已經到來，嵌入式系統的應用開始無處不在，采用嵌入式操作系統的手機、信息家電等眾多的嵌入式產品已經出現。而在相關場合，嵌入式實時操作系統（RTOS）的應用也愈加廣泛。采用RTOS的最大好處就是可以提高系統的可靠性與實時性，同時也提高了軟件開發的效率，縮短了開發周期。在本系統的軟件設計中引入μC/OS-II以后，相比以前的前后臺系統，所增加的代碼空間為數據約1.5K字，程序約3.5K字，額外消耗的存儲器資源較小。而因為μC/OS-II本身的實時特性，使本應用系統的實時性需要能得以滿足，從而系統的可靠性也隨之大大提高。因此，在一般的中小型實時嵌入式系統中，μC/OS-II是一種理想的選擇。

　　本文從應用與實用的角度出發，詳細介紹了μC/OS-II在基于TMS320LF2407內核的電動車電池管理系統中的應用，希望對相關的研究開發人員有所幫助。實驗結果表明，該電池管理系統具有設計合理、性能穩定、實時性好、可靠性高等優點，取得了令人滿意的工作效果。