基于μCOS-Ⅱ的線控轉向中的FlexRay總線通信設計_第1頁
基于μCOS-Ⅱ的線控轉向中的FlexRay總線通信設計_第2頁
基于μCOS-Ⅱ的線控轉向中的FlexRay總線通信設計_第3頁
基于μCOS-Ⅱ的線控轉向中的FlexRay總線通信設計_第4頁
基于μCOS-Ⅱ的線控轉向中的FlexRay總線通信設計_第5頁
已閱讀5頁,還剩1頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、    基于C/OS-的線控轉向中的FlexRay總線通信設計        段建民 汪然 于涌川 時間:2010年05月05日     字 體: 大 中 小        關鍵詞:         通信 FlexRaY是時間觸發的通信總線,對實時性要求較高,

2、因此僅僅依靠由簡單循環和中斷服務程序組成的嵌入式程序將無法滿足要求。同時,FlexRay通信在啟動和運行過程中,需要利用循環對總線狀態進行查詢,既浪費大量的系統資源,又容易造成程序死鎖,成為應用中的難點問題。 基于上述問題,本文基于C/OS-II實時操作系統,設計了線控轉向中FlexRay總線的通信部分。在滿足實時性要求的基礎上,利用其多任務的特點,節約了系統資源,避免了死鎖問題的出現,并增加了通信故障檢測報警功能,為今后開發線控轉向系統奠定了基礎。 1 FlexRay總線技術 為了滿足汽車線控技術的需求,FlexRay聯盟于2005年發布了FlexRay總線協議

3、。其主要特點有:雙通道傳輸,每個通道的傳輸速率高達lO Mbs;具有靈活的使用方式,支持多種網絡拓撲結構;負載率高;提供冗余機制。 從開放式系統互連參考模型角度來看,FlexRay通信協議定義了四層結構:物理層、傳輸層、表示層和應用層,各層功能描述見表1。表示層中,通信狀態切換控制整個FlexRay通信的運行過程,具有十分重要的作用。  FlexRay協議操作控制(Proposal Operation Control,POC)將通信狀態分為幾種狀態,分別為:配置狀態(默認配置、配置);就緒狀態;喚醒狀態;啟動狀態;正常狀態(正常主動、正常被動);暫停狀態。其狀態轉

4、換圖如圖1所示。當控制器主機接口(Controller Host InteRFace,CHI)給通訊控制器(CC)發送命令后,CC從暫停狀態進入默認配置狀態,滿足配置條件后進入配置狀態,完成網絡初始化和節點通信任務初始化;之后可以進入就緒狀態,完成節點內部通信設置,如果沒有滿足通信就緒條件,就返回配置狀態繼續配置;在就緒狀態,CC可以發送喚醒幀,喚醒網絡中沒有在通信的節點,也可以獲得CPU的啟動通信命令,完成與FlexRay網絡時鐘同步;啟動成功后進入正常狀態,完成數據的收發;當出現錯誤時,可由正常狀態進入暫停狀態,重新等待CHI命令。由此可見,控制器需要按照POC狀態進行相應操作,因此會出現

5、對POC狀態的循環檢測,容易造成程序死鎖以及占用大量系統資源。按照操作系統的介紹,其任務是以循環的形式存在的,因此可以將檢測POC狀態放入任務中單獨執行,通過操作系統進行任務調度,可以避免影響到其他任務中程序的運行,并且提高程序的執行效率。 2 基于MC9S12XF512的COS-移植COS-是源碼公開的操作系統,具有執行效率高、占用空間小和實時性能優良等特點。利用該操作系統的任務機制,設計實現Flex-Ray協議,可以大大提高系統的實時性和穩定性,并且可以避免檢測POC狀態時的死鎖現象。 目前市場上支持FlexRay通信的單片機較少,只有Freescale公司的技術比較成

6、熟??紤]到成本問題,選擇16位單片機MC9S12XF512作為系統控制器芯片。操作系統的使用首先要解決的就是移植問題。根據COS-的文件結構,移植時需要對OS_CPUH,(OS_CPU_AASM和OS_CPUCC三個文件進行修改,以適合MC9S12xF512芯片的需要。21 修改OS_CPUH文件OS_CPUH文件定義與CPU相關的硬件信息,包括各種數據類型對應的存儲長度等。針對MC9S12xF512中的堆棧是由高地址向低地址增長的,所以常量OS_STK_GROWTH必須設置為1。同時,定義任務調度函數OS_TASK_SW()設置為軟中斷源。 22 修改OS_CPU_AASM文件OS

7、_CPU_AASM文件是使用匯編語言編寫與任務調度部分有關的代碼。包括任務級任務切換函數OSCtxSw()、中斷級任務切換函數OSIntCtxSw()、以及讓優先級最高的就緒態任務開始運行的函數OS-StartHighRdy()。MC9S12XF512芯片不僅設有FLASH頁面管理寄存器PPage,也有RAM頁面管理寄存器RPage、E2PROM頁面管理寄存器EPage以及全程寄存器GPage。當時鐘節拍中斷發生時,芯片會自動把CPU寄存器推入堆棧,但是并不包括上述各寄存器,因此在OS_CPU_AASM文件三個函數中,均需要加入將寄存器入棧和出棧的語句。由于篇幅有限,僅以PPage代碼為例:&

8、#160;寄存器的入棧必須按照GPage,EPage,RPage,PPage的順序,出棧則相反。 23 修改OS_CPUCC文件OS_CPUCC文件是使用C語言編寫與任務調度部分有關的代碼,包括任務堆棧初始化函數OSTaskStklnit()和時鐘節拍中斷服務子程序OSTicklSR()。 231 修改任務堆棧初始化函數0STaskStkInit()由于COS-是利用中斷方式來實現任務調度的,因此需要使用函數OSTaskStklnit()來模擬發生一次中斷后的堆棧結構,按照中斷后的進棧次序預留各個寄存器存儲空間,而中斷返回地址指向任務代碼的起始地址。編寫時需要根據芯片的中斷

9、后,X,Y,A,B,SP等寄存器入棧順序來進行代碼編寫。首先在例程OSTaskStkInit()函數處設置斷點,然后單步執行程序,觀察X,Y,A,B,SP等寄存器狀態是否與程序編寫的存儲值對應。發現對應于堆棧指針SP值的存儲區地址是模擬中斷時進棧的存儲地址,而其中保存任務程序指針地址的內容是錯誤的,即不是任務的指針地址,因此每次在需要調用任務執行時都進入了錯誤的地址進行執行,并沒有找到任務的代碼。通過單步執行OSTaskStkI-nit()函數,可以發現原程序在存儲任務代碼指針PC值時,只存儲了PC指針的高8位,但后8位未存,導致指針指向錯誤。因此修改程序為: *-wstk=(INT

10、l6U)(INT32U)task); 232 修改時鐘節拍中斷服務子程序OSTickISR()時鐘節拍中斷服務子程序OSTickISR()負責處理所有與定時相關的工作,如任務的延時、等待操作等。在時鐘中斷中將查詢處于等待狀態的任務,判斷是否延時結束,否則將重新進行任務調度??梢酝ㄟ^調用OSIntEnter()。OS_SAVE_SP(),OSTimeTick()和OSIntExit()四個函數進行實現。OSintEnter()函數通知COS-進入中斷服務子程序,OS_SAVE_SP()函數用來保存堆棧指針,OSTimeTick()函數給要求延時若干時鐘節拍的任務延遲計數器減1,當反復運

11、行該程序后,計數器為0時,則表明該任務進入了就緒狀態,OSintExit()函數標志時鐘節拍中斷服務子程序結束。 之后最重要的一點,就是要將中斷服務子程序OSTickISR()與任務級任務切換函數OSCtxSw()添加到系統中斷向量表的相應位置中。這里使用的是實時時鐘中斷模塊(RTI)來實現時鐘中斷的產生,因此要將OSTickISR()連接到向量表RTI位置。OSCtxSw()函數是利用軟中斷來實現任務的切換功能的,因此軟中斷服務子程序的向量地址必須指向OSCtxSw()。 在進行上述程序編寫后,下載代碼到硬件中,COS-就可以在本系統上實現運行了。  

12、          3 通信程序設計    利用任務形式來解決POC狀態的檢測問題,不僅可以提高程序效率以及避免死循環現象,同時,還可以建立通信故障檢測報警任務,在不同的通信狀態下,對駕駛員提供故障信息,方便處理。         線控轉向程序結構包括系統初始化、通信控制、數據采集和控制算法四大部分。這里只對其中的系統初始化及通信控制部分進行了設計。    

13、     31 系統初始化    在主程序main()中,首先對MC9S12XF512芯片進行初始化,包括:時鐘初始化、IO口初始化、AD模塊初始化、PWM模塊初始化以及FlexRay協議配置初始化。之后,調用OSInit()函數對COS-操作系統進行初始化。接著創建三個任務,按照優先級順序9、1l、13,分別為FlexRay通信啟動任務、數據接收發送任務和故障檢測報警任務,由這三個任務實現線控轉向系統的通信部分功能,其他部分功能可通過創建其他任務進行擴展。最后調用OSStart()啟動內核運行,讓任務在

14、操作系統的管理與調度下運行。         32通信任務設計    以Freescale公司開發的針對該芯片的FlexRay通訊傳輸層和表示層的驅動程序為基礎,進行應用層的程序設計,即編寫通信任務程序,完成協議的運行過程。         321 FlexRay通信啟動任務    按照上文介紹的FlexRay協議中定義的協議運行過程,當

15、對FlexRay通信進行初始配置后,協議將進入就緒狀態,之后發送啟動節點命令等待協議狀態由啟動狀態變為正常主動狀態;在正常主動狀態中,首先發送關鍵幀啟動網絡中的其他節點,發送完成后進入到節點喚醒狀態,然后開啟FlexRay通信的各種中斷,包括:傳輸中斷、接收中斷、存儲區中斷以及定時器中斷等,最后掛起任務等待檢測到通信故障時進行喚醒;協議正常被動狀態是在通信出現故障時,重新配置協議,進行協議的重啟。需要注意的是用戶必須在多任務系統啟動以后再開啟時鐘節拍器,也就是在調用Osatart()之后,由任務優先級最高的那個任務開啟RTI中斷,否則系統容易死鎖。程序流程圖如圖2所示。  

16、       322 數據接收發送任務    FlexRay數據的接收發送是通過中斷服務程序進行的,因此在該任務中,只需判斷POC狀態是否進入正常主動狀態,如果是則使用全局變量對接收函數Fr_receive_da()和發送函數Fr_transmit_data()的消息緩沖區進行數據的讀取和更新。         323 故障檢測任務     

17、60;  4 實驗驗證    使用Vector公司的CANoe軟件,可以方便地觀察FlexRay總線上的數據流情況。實驗中,將CANoe軟件提供的FlexRay接口板VN3600接入總線網絡中,之后參考MC9S12XF512芯片手冊中FlexRay通信的MicroTick定義為25 ns,因此在FlexRay初始化定義中,設置參數P_MICRO_PER_M-ACRO_NOM為40,則一個MareroTick等于40個MicroTick,也就是說,FlexRay通信配置的基準時間片為ls。據此,配置通信周期為5 000 s;1個靜態時槽

18、長度為24s,共有91個;1個動態時槽為5s,共有289個;特征窗與網絡空閑時間為1 371s。    程序中對節點Node_A和Node_B的時槽定義如表2所示。        實驗結果如圖4所示,運行時間2 289 s,時槽變化與周期數均與設計一致,數據收發正常。由圖5可知,幀速率為3 200幀s,總計傳輸7 369 600幀,沒有出現無效幀與錯誤幀,達到了實時性和穩定性的要求。                 在通信過程中,分別進行故障模擬實驗。    (1)突然斷開總線來模擬應用現場出現線路故障的情況,可以發現數據停止更新,故障檢測LE

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論