基于μC/OS-Ⅱ的線(xiàn)控轉向FlexRay通信控制

　　0 引言

　　近年來(lái)，隨著(zhù)汽車(chē)工業(yè)和電子工業(yè)的不斷發(fā)展，汽車(chē)線(xiàn)控轉向技術(shù)成為了研究的熱點(diǎn)，并提出了包括路感模擬、轉向穩定性以及總線(xiàn)技術(shù)等諸多關(guān)鍵性問(wèn)題并加以研究。其中的總線(xiàn)技術(shù)，已經(jīng)得到了眾多知名汽車(chē)公司的積極研究與應用。一些汽車(chē)制造商目前計劃采用FlexRay總線(xiàn)，這是一種特別適合下一代汽車(chē)應用的網(wǎng)絡(luò )通信總線(xiàn)，具有容錯功能和確定的消息傳輸時(shí)間，能夠滿(mǎn)足汽車(chē)控制系統的高速率通信要求。

　　FlexRaY是時(shí)間觸發(fā)的通信總線(xiàn)，對實(shí)時(shí)性要求較高，因此僅僅依靠由簡(jiǎn)單循環(huán)和中斷服務(wù)程序組成的嵌入式程序將無(wú)法滿(mǎn)足要求。同時(shí)，FlexRay通信在啟動(dòng)和運行過(guò)程中，需要利用循環(huán)對總線(xiàn)狀態(tài)進(jìn)行查詢(xún)，既浪費大量的系統資源，又容易造成程序死鎖，成為應用中的難點(diǎn)問(wèn)題。

　　基于上述問(wèn)題，本文基于μC／OS-II操作系統，設計了線(xiàn)控轉向中FlexRay總線(xiàn)的通信部分。在滿(mǎn)足實(shí)時(shí)性要求的基礎上，利用其多任務(wù)的特點(diǎn)，節約了系統資源，避免了死鎖問(wèn)題的出現，并增加了通信故障檢測報警功能，為今后開(kāi)發(fā)線(xiàn)控轉向系統奠定了基礎。

　　1 FlexRay總線(xiàn)技術(shù)

　　為了滿(mǎn)足汽車(chē)線(xiàn)控技術(shù)的需求，FlexRay聯(lián)盟于2005年發(fā)布了FlexRay總線(xiàn)協(xié)議。其主要特點(diǎn)有：雙通道傳輸，每個(gè)通道的傳輸速率高達lO Mb／s；具有靈活的使用方式，支持多種網(wǎng)絡(luò )拓撲結構；負載率高；提供冗余機制。

　　從開(kāi)放式系統互連參考模型角度來(lái)看，FlexRay通信協(xié)議定義了四層結構：物理層、傳輸層、表示層和應用層，各層功能描述見(jiàn)表1。表示層中，通信狀態(tài)切換控制整個(gè)FlexRay通信的運行過(guò)程，具有十分重要的作用。

　　FlexRay協(xié)議操作控制(Proposal Operation Control，POC)將通信狀態(tài)分為幾種狀態(tài)，分別為：配置狀態(tài)(默認配置、配置)；就緒狀態(tài)；喚醒狀態(tài)；啟動(dòng)狀態(tài)；正常狀態(tài)(正常主動(dòng)、正常被動(dòng))；暫停狀態(tài)。其狀態(tài)轉換圖如圖1所示。當控制器主機接口(Controller Host InteRFace，CHI)給通訊控制器(CC)發(fā)送命令后，CC從暫停狀態(tài)進(jìn)入默認配置狀態(tài)，滿(mǎn)足配置條件后進(jìn)入配置狀態(tài)，完成網(wǎng)絡(luò )初始化和節點(diǎn)通信任務(wù)初始化；之后可以進(jìn)入就緒狀態(tài)，完成節點(diǎn)內部通信設置，如果沒(méi)有滿(mǎn)足通信就緒條件，就返回配置狀態(tài)繼續配置；在就緒狀態(tài)，CC可以發(fā)送喚醒幀，喚醒網(wǎng)絡(luò )中沒(méi)有在通信的節點(diǎn)，也可以獲得CPU的啟動(dòng)通信命令，完成與FlexRay網(wǎng)絡(luò )時(shí)鐘同步；啟動(dòng)成功后進(jìn)入正常狀態(tài)，完成數據的收發(fā)；當出現錯誤時(shí)，可由正常狀態(tài)進(jìn)入暫停狀態(tài)，重新等待CHI命令。

　　由此可見(jiàn)，控制器需要按照POC狀態(tài)進(jìn)行相應操作，因此會(huì )出現對POC狀態(tài)的循環(huán)檢測，容易造成程序死鎖以及占用大量系統資源。按照操作系統的介紹，其任務(wù)是以循環(huán)的形式存在的，因此可以將檢測POC狀態(tài)放入任務(wù)中單獨執行，通過(guò)操作系統進(jìn)行任務(wù)調度，可以避免影響到其他任務(wù)中程序的運行，并且提高程序的執行效率。

　　2 基于MC9S12XF512的μC／OS-Ⅱ移植

　　μC／OS-Ⅱ是源碼公開(kāi)的操作系統，具有執行效率高、占用空間小和實(shí)時(shí)性能優(yōu)良等特點(diǎn)。利用該操作系統的任務(wù)機制，設計實(shí)現Flex-Ray協(xié)議，可以大大提高系統的實(shí)時(shí)性和穩定性，并且可以避免檢測POC狀態(tài)時(shí)的死鎖現象。

　　目前市場(chǎng)上支持FlexRay通信的單片機較少，只有Freescale公司的技術(shù)比較成熟?？紤]到成本問(wèn)題，選擇16位單片機MC9S12XF512作為系統控制器芯片。操作系統的使用首先要解決的就是移植問(wèn)題。根據μC／OS-Ⅱ的文件結構，移植時(shí)需要對OS_CPU．H，(OS_CPU_A．ASM和OS_CPUC．C三個(gè)文件進(jìn)行修改，以適合MC9S12xF512芯片的需要。

　　2．1 修改OS_CPU．H文件

　　OS_CPU．H文件定義與CPU相關(guān)的硬件信息，包括各種數據類(lèi)型對應的存儲長(cháng)度等。針對MC9S12xF512中的堆棧是由高地址向低地址增長(cháng)的，所以常量OS_STK_GROWTH必須設置為1。同時(shí)，定義任務(wù)調度函數OS_TASK_SW()設置為軟中斷源。

　　2．2 修改OS_CPU_A．ASM文件

　　OS_CPU_A．ASM文件是使用匯編語(yǔ)言編寫(xiě)與任務(wù)調度部分有關(guān)的代碼。包括任務(wù)級任務(wù)切換函數OSCtxSw()、中斷級任務(wù)切換函數OSIntCtxSw()、以及讓優(yōu)先級最高的就緒態(tài)任務(wù)開(kāi)始運行的函數OS-StartHighRdy()。

　　MC9S12XF512芯片不僅設有FLASH頁(yè)面管理寄存器PPage，也有RAM頁(yè)面管理寄存器RPage、E2PROM頁(yè)面管理寄存器EPage以及全程寄存器GPage。當時(shí)鐘節拍中斷發(fā)生時(shí)，芯片會(huì )自動(dòng)把CPU寄存器推入堆棧，但是并不包括上述各寄存器，因此在OS_CPU_A．ASM文件三個(gè)函數中，均需要加入將寄存器入棧和出棧的語(yǔ)句。由于篇幅有限，僅以PPage代碼為例：

　　寄存器的入棧必須按照GPage，EPage，RPage，PPage的順序，出棧則相反。

　　2．3 修改OS_CPUC．C文件

　　OS_CPUC．C文件是使用C語(yǔ)言編寫(xiě)與任務(wù)調度部分有關(guān)的代碼，包括任務(wù)堆棧初始化函數OSTaskStklnit()和時(shí)鐘節拍中斷服務(wù)子程序OSTicklSR()。

　　2．3．1 修改任務(wù)堆棧初始化函數0STaskStkInit()

　　由于μC／OS-Ⅱ是利用中斷方式來(lái)實(shí)現任務(wù)調度的，因此需要使用函數OSTaskStklnit()來(lái)模擬發(fā)生一次中斷后的堆棧結構，按照中斷后的進(jìn)棧次序預留各個(gè)寄存器存儲空間，而中斷返回地址指向任務(wù)代碼的起始地址。編寫(xiě)時(shí)需要根據芯片的中斷后，X，Y，A，B，SP等寄存器入棧順序來(lái)進(jìn)行代碼編寫(xiě)。首先在例程O(píng)STaskStkInit()函數處設置斷點(diǎn)，然后單步執行程序，觀(guān)察X，Y，A，B，SP等寄存器狀態(tài)是否與程序編寫(xiě)的存儲值對應。發(fā)現對應于堆棧指針SP值的存儲區地址是模擬中斷時(shí)進(jìn)棧的存儲地址，而其中保存任務(wù)程序指針地址的內容是錯誤的，即不是任務(wù)的指針地址，因此每次在需要調用任務(wù)執行時(shí)都進(jìn)入了錯誤的地址進(jìn)行執行，并沒(méi)有找到任務(wù)的代碼。通過(guò)單步執行OSTaskStkI-nit()函數，可以發(fā)現原程序在存儲任務(wù)代碼指針PC值時(shí)，只存儲了PC指針的高8位，但后8位未存，導致指針指向錯誤。因此修改程序為：

　　*--wstk=(INTl6U)((INT32U)task)；

　　2．3．2 修改時(shí)鐘節拍中斷服務(wù)子程序OSTickISR()

　　時(shí)鐘節拍中斷服務(wù)子程序OSTickISR()負責處理所有與定時(shí)相關(guān)的工作，如任務(wù)的延時(shí)、等待操作等。在時(shí)鐘中斷中將查詢(xún)處于等待狀態(tài)的任務(wù)，判斷是否延時(shí)結束，否則將重新進(jìn)行任務(wù)調度?？梢酝ㄟ^(guò)調用OSIntEnter()。OS_SAVE_SP()，OSTimeTick()和OSIntExit()四個(gè)函數進(jìn)行實(shí)現。OSintEnter()函數通知μC／OS-Ⅱ進(jìn)入中斷服務(wù)子程序，OS_SAVE_SP()函數用來(lái)保存堆棧指針，OSTimeTick()函數給要求延時(shí)若干時(shí)鐘節拍的任務(wù)延遲計數器減1，當反復運行該程序后，計數器為0時(shí)，則表明該任務(wù)進(jìn)入了就緒狀態(tài)，OSintExit()函數標志時(shí)鐘節拍中斷服務(wù)子程序結束。

　　之后最重要的一點(diǎn)，就是要將中斷服務(wù)子程序OSTickISR()與任務(wù)級任務(wù)切換函數OSCtxSw()添加到系統中斷向量表的相應位置中。這里使用的是實(shí)時(shí)時(shí)鐘中斷模塊(RTI)來(lái)實(shí)現時(shí)鐘中斷的產(chǎn)生，因此要將OSTickISR()連接到向量表RTI位置。OSCtxSw()函數是利用軟中斷來(lái)實(shí)現任務(wù)的切換功能的，因此軟中斷服務(wù)子程序的向量地址必須指向OSCtxSw()。

　　在進(jìn)行上述程序編寫(xiě)后，下載代碼到硬件中，μC／OS-Ⅱ就可以在本系統上實(shí)現運行了。

　　3 通信程序設計

　　利用任務(wù)形式來(lái)解決POC狀態(tài)的檢測問(wèn)題，不僅可以提高程序效率以及避免死循環(huán)現象，同時(shí)，還可以建立通信故障檢測報警任務(wù)，在不同的通信狀態(tài)下，對駕駛員提供故障信息，方便處理。

　　線(xiàn)控轉向程序結構包括系統初始化、通信控制、數據采集和控制算法四大部分。這里只對其中的系統初始化及通信控制部分進(jìn)行了設計。

　　3．1 系統初始化

　　在主程序main()中，首先對MC9S12XF512芯片進(jìn)行初始化，包括：時(shí)鐘初始化、I／O口初始化、A／D模塊初始化、PWM模塊初始化以及FlexRay協(xié)議配置初始化。之后，調用OSInit()函數對μC／OS-Ⅱ操作系統進(jìn)行初始化。接著(zhù)創(chuàng )建三個(gè)任務(wù)，按照優(yōu)先級順序9、1l、13，分別為FlexRay通信啟動(dòng)任務(wù)、數據接收發(fā)送任務(wù)和故障檢測報警任務(wù)，由這三個(gè)任務(wù)實(shí)現線(xiàn)控轉向系統的通信部分功能，其他部分功能可通過(guò)創(chuàng )建其他任務(wù)進(jìn)行擴展。最后調用OSStart()啟動(dòng)內核運行，讓任務(wù)在操作系統的管理與調度下運行。

　　3．2通信任務(wù)設計

　　以Freescale公司開(kāi)發(fā)的針對該芯片的FlexRay通訊傳輸層和表示層的驅動(dòng)程序為基礎，進(jìn)行應用層的程序設計，即編寫(xiě)通信任務(wù)程序，完成協(xié)議的運行過(guò)程。

　　3．2．1 FlexRay通信啟動(dòng)任務(wù)

　　按照上文介紹的FlexRay協(xié)議中定義的協(xié)議運行過(guò)程，當對FlexRay通信進(jìn)行初始配置后，協(xié)議將進(jìn)入就緒狀態(tài)，之后發(fā)送啟動(dòng)節點(diǎn)命令等待協(xié)議狀態(tài)由啟動(dòng)狀態(tài)變?yōu)檎Ｖ鲃?dòng)狀態(tài)；在正常主動(dòng)狀態(tài)中，首先發(fā)送關(guān)鍵幀啟動(dòng)網(wǎng)絡(luò )中的其他節點(diǎn)，發(fā)送完成后進(jìn)入到節點(diǎn)喚醒狀態(tài)，然后開(kāi)啟FlexRay通信的各種中斷，包括：傳輸中斷、接收中斷、存儲區中斷以及定時(shí)器中斷等，最后掛起任務(wù)等待檢測到通信故障時(shí)進(jìn)行喚醒；協(xié)議正常被動(dòng)狀態(tài)是在通信出現故障時(shí)，重新配置協(xié)議，進(jìn)行協(xié)議的重啟。需要注意的是用戶(hù)必須在多任務(wù)系統啟動(dòng)以后再開(kāi)啟時(shí)鐘節拍器，也就是在調用Osatart()之后，由任務(wù)優(yōu)先級最高的那個(gè)任務(wù)開(kāi)啟RTI中斷，否則系統容易死鎖。程序流程圖如圖2所示。

　　3．2．2 數據接收發(fā)送任務(wù)

　　FlexRay數據的接收發(fā)送是通過(guò)中斷服務(wù)程序進(jìn)行的，因此在該任務(wù)中，只需判斷POC狀態(tài)是否進(jìn)入正常主動(dòng)狀態(tài)，如果是則使用全局變量對接收函數Fr_receive_da()和發(fā)送函數Fr_transmit_data()的消息緩沖區進(jìn)行數據的讀取和更新。

　　3．2．3 故障檢測任務(wù)

　　在通信過(guò)程中，當其他節點(diǎn)因故障重啟或是通信線(xiàn)路中斷時(shí)，可以利用故障檢測任務(wù)檢查POC狀態(tài)，當協(xié)議運行在正常被動(dòng)狀態(tài)時(shí)，則判斷為通信線(xiàn)路出現故障，將故障LED指示燈設定為閃爍狀態(tài)；當協(xié)議運行在暫停狀態(tài)時(shí)，則判斷為節點(diǎn)控制器故障，故障LED指示燈設定為常亮狀態(tài)，并對FlexRay通信啟動(dòng)任務(wù)進(jìn)行解掛，重新對協(xié)議進(jìn)行配置，待故障解決，系統可以自動(dòng)啟動(dòng)節點(diǎn)運行。程序流程圖如圖3所示。

　　4 實(shí)驗驗證

　　使用Vector公司的CANoe軟件，可以方便地觀(guān)察FlexRay總線(xiàn)上的數據流情況。實(shí)驗中，將CANoe軟件提供的FlexRay接口板VN3600接入總線(xiàn)網(wǎng)絡(luò )中，之后參考MC9S12XF512芯片手冊中FlexRay通信的MicroTick定義為25 ns，因此在FlexRay初始化定義中，設置參數P_MICRO_PER_M-ACRO_NOM為40，則一個(gè)MareroTick等于40個(gè)MicroTick，也就是說(shuō)，FlexRay通信配置的基準時(shí)間片為lμs。據此，配置通信周期為5 000 μs；1個(gè)靜態(tài)時(shí)槽長(cháng)度為24μs，共有91個(gè)；1個(gè)動(dòng)態(tài)時(shí)槽為5μs，共有289個(gè)；特征窗與網(wǎng)絡(luò )空閑時(shí)間為1 371μs。

　　程序中對節點(diǎn)Node_A和Node_B的時(shí)槽定義如表2所示。

　　實(shí)驗結果如圖4所示，運行時(shí)間2 289 s，時(shí)槽變化與周期數均與設計一致，數據收發(fā)正常。由圖5可知，幀速率為3 200幀／s，總計傳輸7 369 600幀，沒(méi)有出現無(wú)效幀與錯誤幀，達到了實(shí)時(shí)性和穩定性的要求。

　　在通信過(guò)程中，分別進(jìn)行故障模擬實(shí)驗。

　　(1)突然斷開(kāi)總線(xiàn)來(lái)模擬應用現場(chǎng)出現線(xiàn)路故障的情況，可以發(fā)現數據停止更新，故障檢測LED指示燈閃爍，說(shuō)明程序檢測到了線(xiàn)路故障問(wèn)題并進(jìn)行報警。當再次連接總線(xiàn)后，故障檢測LED熄滅，數據繼續更新，說(shuō)明通信自動(dòng)重新啟動(dòng)。

　　(2)將任意一個(gè)控制器進(jìn)行掉電，模擬單一控制器故障情況，可以發(fā)現數據停止更新，故障檢測LED指示燈開(kāi)始常亮，說(shuō)明程序檢測到了任意節點(diǎn)故障導致通信中斷的問(wèn)題并進(jìn)行報警。當再次開(kāi)啟掉電控制器后，故障檢測LED熄滅，數據繼續更新，說(shuō)明通信自動(dòng)重新啟動(dòng)。通過(guò)以上兩個(gè)實(shí)驗，驗證了故障檢測報警功能良好。

　　5 結語(yǔ)

　　針對線(xiàn)控轉向系統FlexRay通信過(guò)程中存在的問(wèn)題，將實(shí)時(shí)操作系統μC／OS-Ⅱ應用于系統中，進(jìn)行了代碼移植和通信任務(wù)設計。之后通過(guò)硬件實(shí)驗，對數據結果和故障檢測進(jìn)行了測試，從實(shí)驗結果可以看出，該系統解決了FlexRay總線(xiàn)應用的復雜問(wèn)題，并利用μC／OS-Ⅱ操作系統保證了系統實(shí)時(shí)性、穩定性和安全性的要求，為今后實(shí)現線(xiàn)控轉向系統在汽車(chē)輔助駕駛和智能駕駛方面的應用奠定了基礎。