基于μC/OS-Ⅱ的線控轉向中的FlexRay總線通信設計
段建民 汪然 于涌川
摘要： 本文基于μC／OS-II操作系統，設計了線控轉向中FlexRay總線的通信部分。在滿足實時性要求的基礎上，利用其多任務的特點，節約了系統資源，避免了死鎖問題的出現，并增加了通信故障檢測報警功能，為今后開發線控轉向系統奠定了基礎。
Abstract：
Key words :
近年來，隨著汽車工業和電子工業的不斷發展，汽車線控轉向技術成為了研究的熱點，并提出了包括路感模擬、轉向穩定性以及總線技術等諸多關鍵性問題并加以研究。其中的總線技術，已經得到了眾多知名汽車公司的積極研究與應用。一些汽車制造商目前計劃采用FlexRay總線，這是一種特別適合下一代汽車應用的網絡通信總線，具有容錯功能和確定的消息傳輸時間，能夠滿足汽車控制系統的高速率通信要求。
FlexRaY是時間觸發的通信總線，對實時性要求較高，因此僅僅依靠由簡單循環和中斷服務程序組成的嵌入式程序將無法滿足要求。同時，FlexRay通信在啟動和運行過程中，需要利用循環對總線狀態進行查詢，既浪費大量的系統資源，又容易造成程序死鎖，成為應用中的難點問題。
基于上述問題，本文基于μC/OS-II實時操作系統，設計了線控轉向中FlexRay總線的通信部分。在滿足實時性要求的基礎上，利用其多任務的特點，節約了系統資源，避免了死鎖問題的出現，并增加了通信故障檢測報警功能，為今后開發線控轉向系統奠定了基礎。
1 FlexRay總線技術
為了滿足汽車線控技術的需求，FlexRay聯盟于2005年發布了FlexRay總線協議。其主要特點有：雙通道傳輸，每個通道的傳輸速率高達lO Mb／s；具有靈活的使用方式，支持多種網絡拓撲結構；負載率高；提供冗余機制。
從開放式系統互連參考模型角度來看，FlexRay通信協議定義了四層結構：物理層、傳輸層、表示層和應用層，各層功能描述見表1。表示層中，通信狀態切換控制整個FlexRay通信的運行過程，具有十分重要的作用。
FlexRay協議操作控制(Proposal Operation Control，POC)將通信狀態分為幾種狀態，分別為：配置狀態(默認配置、配置)；就緒狀態；喚醒狀態；啟動狀態；正常狀態(正常主動、正常被動)；暫停狀態。其狀態轉換圖如圖1所示。當控制器主機接口(Controller Host InteRFace，CHI)給通訊控制器(CC)發送命令后，CC從暫停狀態進入默認配置狀態，滿足配置條件后進入配置狀態，完成網絡初始化和節點通信任務初始化；之后可以進入就緒狀態，完成節點內部通信設置，如果沒有滿足通信就緒條件，就返回配置狀態繼續配置；在就緒狀態，CC可以發送喚醒幀，喚醒網絡中沒有在通信的節點，也可以獲得CPU的啟動通信命令，完成與FlexRay網絡時鐘同步；啟動成功后進入正常狀態，完成數據的收發；當出現錯誤時，可由正常狀態進入暫停狀態，重新等待CHI命令。
由此可見，控制器需要按照POC狀態進行相應操作，因此會出現對POC狀態的循環檢測，容易造成程序死鎖以及占用大量系統資源。按照操作系統的介紹，其任務是以循環的形式存在的，因此可以將檢測POC狀態放入任務中單獨執行，通過操作系統進行任務調度，可以避免影響到其他任務中程序的運行，并且提高程序的執行效率。
2 基于MC9S12XF512的μC／OS-Ⅱ移植
μC／OS-Ⅱ是源碼公開的操作系統，具有執行效率高、占用空間小和實時性能優良等特點。利用該操作系統的任務機制，設計實現Flex-Ray協議，可以大大提高系統的實時性和穩定性，并且可以避免檢測POC狀態時的死鎖現象。
目前市場上支持FlexRay通信的單片機較少，只有Freescale公司的技術比較成熟。考慮到成本問題，選擇16位單片機MC9S12XF512作為系統控制器芯片。操作系統的使用首先要解決的就是移植問題。根據μC／OS-Ⅱ的文件結構，移植時需要對OS_CPU．H，(OS_CPU_A．ASM和OS_CPUC．C三個文件進行修改，以適合MC9S12xF512芯片的需要。
2．1 修改OS_CPU．H文件
OS_CPU．H文件定義與CPU相關的硬件信息，包括各種數據類型對應的存儲長度等。針對MC9S12xF512中的堆棧是由高地址向低地址增長的，所以常量OS_STK_GROWTH必須設置為1。同時，定義任務調度函數OS_TASK_SW()設置為軟中斷源。
2．2 修改OS_CPU_A．ASM文件
OS_CPU_A．ASM文件是使用匯編語言編寫與任務調度部分有關的代碼。包括任務級任務切換函數OSCtxSw()、中斷級任務切換函數OSIntCtxSw()、以及讓優先級最高的就緒態任務開始運行的函數OS-StartHighRdy()。
MC9S12XF512芯片不僅設有FLASH頁面管理寄存器PPage，也有RAM頁面管理寄存器RPage、E2PROM頁面管理寄存器EPage以及全程寄存器GPage。當時鐘節拍中斷發生時，芯片會自動把CPU寄存器推入堆棧，但是并不包括上述各寄存器，因此在OS_CPU_A．ASM文件三個函數中，均需要加入將寄存器入棧和出棧的語句。由于篇幅有限，僅以PPage代碼為例：
寄存器的入棧必須按照GPage，EPage，RPage，PPage的順序，出棧則相反。
2．3 修改OS_CPUC．C文件
OS_CPUC．C文件是使用C語言編寫與任務調度部分有關的代碼，包括任務堆棧初始化函數OSTaskStklnit()和時鐘節拍中斷服務子程序OSTicklSR()。
2．3．1 修改任務堆棧初始化函數0STaskStkInit()
由于μC／OS-Ⅱ是利用中斷方式來實現任務調度的，因此需要使用函數OSTaskStklnit()來模擬發生一次中斷后的堆棧結構，按照中斷后的進棧次序預留各個寄存器存儲空間，而中斷返回地址指向任務代碼的起始地址。編寫時需要根據芯片的中斷后，X，Y，A，B，SP等寄存器入棧順序來進行代碼編寫。首先在例程OSTaskStkInit()函數處設置斷點，然后單步執行程序，觀察X，Y，A，B，SP等寄存器狀態是否與程序編寫的存儲值對應。發現對應于堆棧指針SP值的存儲區地址是模擬中斷時進棧的存儲地址，而其中保存任務程序指針地址的內容是錯誤的，即不是任務的指針地址，因此每次在需要調用任務執行時都進入了錯誤的地址進行執行，并沒有找到任務的代碼。通過單步執行OSTaskStkI-nit()函數，可以發現原程序在存儲任務代碼指針PC值時，只存儲了PC指針的高8位，但后8位未存，導致指針指向錯誤。因此修改程序為：
*--wstk=(INTl6U)((INT32U)task)；
2．3．2 修改時鐘節拍中斷服務子程序OSTickISR()
時鐘節拍中斷服務子程序OSTickISR()負責處理所有與定時相關的工作，如任務的延時、等待操作等。在時鐘中斷中將查詢處于等待狀態的任務，判斷是否延時結束，否則將重新進行任務調度?？梢酝ㄟ^調用OSIntEnter()。OS_SAVE_SP()，OSTimeTick()和OSIntExit()四個函數進行實現。OSintEnter()函數通知μC／OS-Ⅱ進入中斷服務子程序，OS_SAVE_SP()函數用來保存堆棧指針，OSTimeTick()函數給要求延時若干時鐘節拍的任務延遲計數器減1，當反復運行該程序后，計數器為0時，則表明該任務進入了就緒狀態，OSintExit()函數標志時鐘節拍中斷服務子程序結束。
之后最重要的一點，就是要將中斷服務子程序OSTickISR()與任務級任務切換函數OSCtxSw()添加到系統中斷向量表的相應位置中。這里使用的是實時時鐘中斷模塊(RTI)來實現時鐘中斷的產生，因此要將OSTickISR()連接到向量表RTI位置。OSCtxSw()函數是利用軟中斷來實現任務的切換功能的，因此軟中斷服務子程序的向量地址必須指向OSCtxSw()。
在進行上述程序編寫后，下載代碼到硬件中，μC／OS-Ⅱ就可以在本系統上實現運行了。
3 通信程序設計
利用任務形式來解決POC狀態的檢測問題，不僅可以提高程序效率以及避免死循環現象，同時，還可以建立通信故障檢測報警任務，在不同的通信狀態下，對駕駛員提供故障信息，方便處理。
線控轉向程序結構包括系統初始化、通信控制、數據采集和控制算法四大部分。這里只對其中的系統初始化及通信控制部分進行了設計。
3．1 系統初始化
在主程序main()中，首先對MC9S12XF512芯片進行初始化，包括：時鐘初始化、I／O口初始化、A／D模塊初始化、PWM模塊初始化以及FlexRay協議配置初始化。之后，調用OSInit()函數對μC／OS-Ⅱ操作系統進行初始化。接著創建三個任務，按照優先級順序9、1l、13，分別為FlexRay通信啟動任務、數據接收發送任務和故障檢測報警任務，由這三個任務實現線控轉向系統的通信部分功能，其他部分功能可通過創建其他任務進行擴展。最后調用OSStart()啟動內核運行，讓任務在操作系統的管理與調度下運行。
3．2通信任務設計
以Freescale公司開發的針對該芯片的FlexRay通訊傳輸層和表示層的驅動程序為基礎，進行應用層的程序設計，即編寫通信任務程序，完成協議的運行過程。
3．2．1 FlexRay通信啟動任務
按照上文介紹的FlexRay協議中定義的協議運行過程，當對FlexRay通信進行初始配置后，協議將進入就緒狀態，之后發送啟動節點命令等待協議狀態由啟動狀態變為正常主動狀態；在正常主動狀態中，首先發送關鍵幀啟動網絡中的其他節點，發送完成后進入到節點喚醒狀態，然后開啟FlexRay通信的各種中斷，包括：傳輸中斷、接收中斷、存儲區中斷以及定時器中斷等，最后掛起任務等待檢測到通信故障時進行喚醒；協議正常被動狀態是在通信出現故障時，重新配置協議，進行協議的重啟。需要注意的是用戶必須在多任務系統啟動以后再開啟時鐘節拍器，也就是在調用Osatart()之后，由任務優先級最高的那個任務開啟RTI中斷，否則系統容易死鎖。程序流程圖如圖2所示。
3．2．2 數據接收發送任務
FlexRay數據的接收發送是通過中斷服務程序進行的，因此在該任務中，只需判斷POC狀態是否進入正常主動狀態，如果是則使用全局變量對接收函數Fr_receive_da()和發送函數Fr_transmit_data()的消息緩沖區進行數據的讀取和更新。
3．2．3 故障檢測任務
在通信過程中，當其他節點因故障重啟或是通信線路中斷時，可以利用故障檢測任務檢查POC狀態，當協議運行在正常被動狀態時，則判斷為通信線路出現故障，將故障LED指示燈設定為閃爍狀態；當協議運行在暫停狀態時，則判斷為節點控制器故障，故障LED指示燈設定為常亮狀態，并對FlexRay通信啟動任務進行解掛，重新對協議進行配置，待故障解決，系統可以自動啟動節點運行。程序流程圖如圖3所示。
4 實驗驗證
使用Vector公司的CANoe軟件，可以方便地觀察FlexRay總線上的數據流情況。實驗中，將CANoe軟件提供的FlexRay接口板VN3600接入總線網絡中，之后參考MC9S12XF512芯片手冊中FlexRay通信的MicroTick定義為25 ns，因此在FlexRay初始化定義中，設置參數P_MICRO_PER_M-ACRO_NOM為40，則一個MareroTick等于40個MicroTick，也就是說，FlexRay通信配置的基準時間片為lμs。據此，配置通信周期為5 000 μs；1個靜態時槽長度為24μs，共有91個；1個動態時槽為5μs，共有289個；特征窗與網絡空閑時間為1 371μs。
程序中對節點Node_A和Node_B的時槽定義如表2所示。
實驗結果如圖4所示，運行時間2 289 s，時槽變化與周期數均與設計一致，數據收發正常。由圖5可知，幀速率為3 200幀／s，總計傳輸7 369 600幀，沒有出現無效幀與錯誤幀，達到了實時性和穩定性的要求。
在通信過程中，分別進行故障模擬實驗。
(1)突然斷開總線來模擬應用現場出現線路故障的情況，可以發現數據停止更新，故障檢測LED指示燈閃爍，說明程序檢測到了線路故障問題并進行報警。當再次連接總線后，故障檢測LED熄滅，數據繼續更新，說明通信自動重新啟動。
(2)將任意一個控制器進行掉電，模擬單一控制器故障情況，可以發現數據停止更新，故障檢測LED指示燈開始常亮，說明程序檢測到了任意節點故障導致通信中斷的問題并進行報警。當再次開啟掉電控制器后，故障檢測LED熄滅，數據繼續更新，說明通信自動重新啟動。通過以上兩個實驗，驗證了故障檢測報警功能良好。
5 結語
針對線控轉向系統FlexRay通信過程中存在的問題，將實時操作系統μC／OS-Ⅱ應用于系統中，進行了代碼移植和通信任務設計。之后通過硬件實驗，對數據結果和故障檢測進行了測試，從實驗結果可以看出，該系統解決了FlexRay總線應用的復雜問題，并利用μC／OS-Ⅱ操作系統保證了系統實時性、穩定性和安全性的要求，為今后實現線控轉向系統在汽車輔助駕駛和智能駕駛方面的應用奠定了基礎。
來源：現代電子技術
此內容為AET網站原創，未經授權禁止轉載。