?

　　近年來,ГOCT18977、1553B和ARINC429已成為我軍機載設備間、飛機與導彈間數據通信所廣泛采用的總線標準。這種多種總線標準并存的情況帶來一系列問題:一是在地面維護過程中,需要測試不同總線標準的數據;二是不同總線標準之間的協議轉換。因此如何實現地面檢測設備與多種不同總線標準機載設備之間的通信以及不同總線標準之間的協議轉換成為必須解決的問題。本文針對某型飛機加掛某型導彈的實際應用,設計了一個基于μC/OS-Ⅱ的1553B和ARINC429總線實時協議轉換系統。

　　1 協議轉換系統的需求分析和設計原則

　　1553B和ARINC429總線實時協議轉換系統是某型飛機發射架的一部分,主要完成以下功能:(1)完成對導彈加溫、準備和發射三個階段的實時控制;(2)在導彈準備和發射階段,把1553B格式的飛行任務轉換成ARINC429格式,并發送給導彈; (3)在導彈準備和發射階段,控制電源模塊輸出4路直流給導引頭;(4)完成對導彈故障的實時檢測,并上報給飛機。

　　顯然,該系統是一個典型的航空電子設備,因此,實時性和可靠性將是系統設計的基本要求。同樣,簡單化、模塊化也是設計中要遵循的思想。具體來說,設計時應遵循下列幾個原則:(1)實時性強;(2)可靠性高;(3)具有一定的擴展性;(4)維修性好;(5)通用性好。

　　2 1553B和ARINC429協議分析

　　2.1 1553B總線協議[1-3]

　　1553B總線的正式名稱為“時分制指令/響應式多路傳輸數據總線”(Time Division Command/ Response Multiplex Data Bus),是目前世界軍用飛機中應用最廣泛的數據傳輸系統。1553B高度的可靠性和靈活性使它在機載、艦載以及地面武器設備中得到了廣泛的應用,并逐漸應用到民用領域。

　　1553B總線的基本操作要求是:總線系統信息傳輸的控制權唯一歸總線控制器所有;總線系統的操作應是指令/響應型的異步操作;數據總線上的信息傳輸應以半雙工方式進行;數據總線上的信息流應由消息組成;總線系統應具有方式控制的能力。

　　1553B總線上只有3種字格式,分別是指令字、數據字和狀態字,如圖1所示。一個字的結構為“同步頭+16位數據位+奇偶校驗位”,總共20個位時。

?

　　1553B總線上的消息格式數量有限,可以分為非廣播消息和廣播消息兩大類。非廣播消息有6種消息格式,廣播消息有4種格式,除了這10種消息格式之外,不應使用任何別的消息格式。

　　2.2 ARINC429總線協議[4-6]

　　ARINC429總線是ARINC為航空電子系統之間進行數據傳輸而定義的航空工業標準,其正式名稱為MARK33數字式信息傳輸系統DITS(Digital Information Transfer System)技術標準,信號形式同ГОСТ18977。ARINC429 在國內被稱為HB6096-86 數字信息傳輸系統。

　　ARINC429總線的一個數據字有32位,它們被分為5段,采用2的補碼小數記法編碼(BNR)或ISO5 號字母表數字子集編碼(BCD),其數據格式如表1所示。

?

　　ARINC429的傳輸協議十分簡單,是點對點的傳輸協議,解決了原來419 規范的許多矛盾和沖突。根據規范,其數字信息通過一對單向、差分耦合、雙絞屏蔽線傳輸,屬于串行通信,實現32比特字傳輸格式。

　　3 協議轉換系統的硬件設計

　　3.1 總體設計方案和結構框圖

　　綜合協議轉換系統的功能需求及1553B和ARINC429的協議分析,提出如下設計方案:(1)硬件環境:采用“MCU+FPGA+外圍芯片”方案構建硬件系統,MCU采用TI 公司的DSP TMS320LF2407實現;FPGA采用Altera公司的Stratix FPGA軍用溫度級產品EP1S60F1020I6實現;外圍芯片主要包括1553B協議芯片BU61580等。(2)軟件環境:將嵌入式實時內核μC/OS-II移植到DSP控制器TMS320LF2407上從而構建一個低成本的通用嵌入式實時軟件平臺;基于DSP集成化軟件開發環境CCS,用C語言和匯編語言進行軟件開發。

　　1553B和ARINC429總線實時協議轉換系統實際上是一個嵌入式微型計算機應用系統,由控制器模塊、接口電路模塊和電源模塊三部分組成,其總體結構如圖2所示。

?

　　控制器模塊是協議轉換系統的核心,用于完成對導彈的實時控制、邏輯判斷、總線轉換以及串口通信等功能;接口電路模塊是協議轉換系統的外部接口(飛機、導彈接口)與控制器模塊之間的橋梁,其功能是信號隔離、電平轉換和功率信號時序控制等;電源模塊包括兩個部分,一部分用于產生協議轉換系統本身工作所需電源,另一部分用于產生導引頭工作所需電源。

　　3.2 控制器模塊的設計

　　控制器模塊的結構原理圖如圖3所示。整個控制器模塊主要由控制器、422總線通信電路、1553B協議轉換電路、隔離變壓器電路、FPGA控制邏輯及ARINC429電平轉換電路等組成。

?

　　FPGA控制邏輯用Verilog HDL在QuartusII環境下編程實現,主要完成以下功能:(1)產生對1553B協議芯片BU61580操作的所有控制信號;(2)產生對ARINC429接收模塊和ARINC429發送模塊操作的所有控制信號; (3)為1553B協議芯片BU61580、ARINC429接收模塊和ARINC429發送模塊產生各自的工作時鐘,其中分頻數N可通過軟件進行賦值,實現可編程時鐘模塊;(4)建立FIFO模塊,在數據傳輸中緩沖和存儲數據;(5)實現ARINC429信號接收和發送,包括同步處理、字頭檢驗、奇偶校驗、串并轉換和并串轉換等。

　　4 實時操作系統的移植、構建和優化

　　將嵌入式實時內核μC/OS-II移植到DSP控制器TMS320LF2407上構建一個低成本的通用嵌入式實時軟件平臺,以進行系統軟件的開發。引入μC/OS-II實時內核的目的是要以很小的系統代價,大大降低DSP系統軟件開發的難度,同時使系統的實時性得到保證。

　　4.1 μC/OS-II移植的可行性分析

　　所謂移植,就是使一個實時內核能在某個處理器上運行[7]。因為C語言是跨平臺的,各種編譯器都支持,所以μC/OS-II和其他嵌入式操作系統一樣,和處理器無關的代碼主要用C語言寫。雖然μC/OS-II系統的大部分源代碼都是用C 語言實現的,但仍需要使用X86 匯編語言來完成一些與處理器、寄存器相關的代碼[8]。這是因為μC/OS-II在讀寫處理器寄存器時只能通過匯編語言來實現。

　　要順利移植μC/OS-II,處理器必須滿足以下要求:(1)處理器的C編譯器能產生重入代碼,利用C語言就可以打開和關閉中斷;(2)處理器支持中斷,并能產生定時中斷;(3)處理器支持足夠的RAM(可能是幾千字節)作為數據存儲的硬件堆棧; (4)處理器有將堆棧指針和其他CPU寄存器讀出和存儲到堆棧或內存中的指令。

　　顯然,采用的控制器TMS320LF2407及編譯器CCS均可滿足要求,因此完全可以在TMS320LF2407上移植嵌入式實時內核μC/OS-II。

　　4.2 μC/OS-II的代碼結構和移植步驟

　　μC/OS-II的代碼結構以及它與硬件的關系如圖4所示,其全部代碼可以分為三個部分[9]:

　　(1)與處理器無關的代碼。包括\SOFTWAREμC/OS-IISOURCE目錄下的文件,主要提供μC/OS-II的系統服務、任務管理、任務間通信與內存管理等。這部分代碼可完全移植到處理器上。

?

　　(2)與應用相關的代碼。包括OS_CFG.H和INCLUDES.H頭文件。OS_CFG.H文件包含μC/OS-II的初始化配置項,由一系列#define constant語句構成。INCLUDES.H是一個頭文件,在所有.C文件的第一行被包含。用戶可以通過編輯INCLUDES.H來增加自己的頭文件,但是用戶的頭文件必須添加在頭文件列表的最后。

　　(3) 與處理器相關的代碼。即OS_CPU.H、OS_CPU_A.ASM及OS_CPU_C.C,絕大部分的移植工作都集中在這里。

　　移植μC/OS-II的具體步驟是:(1)在OS_CPU.H中設置一個常量來標識堆棧增長方向;(2)在OS_CPU.H中聲明幾個用于開關中斷和任務切換的宏;(3)在OS_CPU.H中針對具體處理器的字長重新定義一系列數據類型;(4)在OS_CPU_A.ASM中改寫4個匯編語言的函數:OSStartHighRdy()、OSCtxSw()、OSIntCtxSw()和OSTickISR();(5)在OS_CPU_C.C中用C 語言重新編寫6個簡單的C函數: OSTaskStk Init()、OSTaskCreateHook()、OSTaskDelHook()、OSTaskSwHook()、OSTaskStatHook()和OSTimeTick Hook();(6)修改主頭文件INCLUDES.H,將上面的三個文件和其他的頭文件加入。

　　4.3 實時操作系統軟件平臺的優化

　　移植后的實時操作系統可根據具體硬件和性能需求進行優化,以獲得更高的執行效率。

　　(1) 裁剪[9]

　　μC/OS-II具有源代碼開放的優點,是一個可裁剪的操作系統。在實際應用時可根據需要對源代碼進行取舍,去掉不需要的服務以及不需要的變量和函數,甚至可以根據需要改寫相關函數。代碼的削減可通過設置OS_CFG.H中的#define OS_×××_EN為0來實現。本系統中取消了不需要的郵箱服務、任務掛起等功能,使得代碼非常簡練,可靠性更好。此外,在μC/OS-II的源代碼中,函數執行中有許多條件判斷,作用是防止參數的錯誤傳遞。作為通用系統,這些條件判斷是完全必要的,避免出現錯誤時系統崩潰。但作為具體的應用,只要在程序設計時保證參數傳遞的正確性,完全可以不用條件判斷,所以在本系統程序設計時,取消了全部的條件判斷,從而提高了函數的執行速度。

　　(2) 改進內存管理

　　μC/OS-II在內存管理上顯得過于簡單,其任務棧空間和內存分區的創建采用了定義全局數組的方法,即定義一維或二維的全局數組,在創建任務或內存分區時,將數組名作為內存地址指針傳遞給生成函數。這樣實現起來固然簡單,但是不夠靈活有效。

　　編譯器會將全局數組作為未初始化的全局變量,放到應用程序映像的數據段。數組大小是固定的,生成映像后不可能在使用中動態地改變。對于任務棧空間來說,數組定義大了會造成內存浪費,定義小了任務棧溢出會造成系統崩潰。對于內存分區,在不知道系統初始化后給用戶留下了多少自由內存空間的情況下,很難定義內存分區所用數組的大小。可見,利用全局數組來分配內存空間是不合理的。另外,目前的μC/OS-II只支持固定大小的內存分區,容易造成內存浪費。所以應該改進以支持可變大小的內存分區。

　　因此,在本系統中采用如下方法來對內存進行管理:①系統初始化時,正確安排代碼段和數據段的位置,從而確定用戶自由空間的起始地址;②用目標板(LF2407)內存最高端地址減去起始地址得到用戶自由空間的大小;③在自用空間中建立和使用內存分區,分配好任務堆棧、事件控制塊和消息隊列等各自內存大小。

　　(3) 堆棧的使用和管理

　　在μC/OS-II中,各任務的堆棧在邏輯上是相互獨立的,這樣在分配每一個任務堆棧區的大小時,不但要考慮本任務中的局部變量和函數嵌套所需要的堆棧空間,還要考慮系統中所可能發生的最大層數的中斷嵌套所需的堆棧空間,從而要占用較多的RAM空間,在系統中有多個任務同時存在時尤其嚴重。如果對此考慮不足,則可能會出現運行中的任務堆棧空間不足、溢出的情形,從而導致系統崩潰。

　　針對上述問題,本系統采用以下方法使用和管理堆棧:各任務棧相互分離,且不考慮中斷使用;另外分配一個工作棧,可滿足所需堆棧空間最大的任務在最大可能層數的中斷嵌套下使用。運行時,將當前任務的任務堆棧內容拷貝至工作棧中,在工作棧中運行;當發生任務切換時,先將工作棧中的有用內容保存到當前任務棧,然后將待運行任務的任務棧調入工作棧,在工作棧中運行。在此過程中,堆棧指針始終指在工作棧區域內。

　　5 協議轉換系統的軟件設計

　　協議轉換系統是一個多任務系統,并且各個任務之間很可能同時進行,其整個軟件按功能可以分成兩個模塊:導彈加溫、準備工作子程序和導彈發射子程序。流程圖分別如圖5、圖6所示。

?

?

　　6 協議轉換系統的測試和驗證

　　系統參數和設置如下:晶振頻率為11 059.2kHz,鎖相環(PLL)倍增器值設置為4,存儲器加速開啟,中斷類型為IRQ中斷。在此條件下,其中斷響應時間即為從中斷發生起,到執行中斷處理程序的第一條指令所用的時間,約為0.76μs;飛機控制指令發出到導彈動作實際執行,最大時間延遲約為1.43μs,系統實時性完全符合要求。將該協議轉換系統安裝在發射架內,進行實際的聯機驗證,實際運行結果表明,能有效實現參數、數據的傳輸和轉換以及飛機對導彈的實時控制等。

　　1553B和ARINC429總線實時協議轉換系統硬件部分采用“MCU+FPGA+外圍芯片”進行構建;軟件部分是將嵌入式實時內核μC/OS-II移植到DSP控制器上從而構建一個低成本的通用嵌入式實時軟件平臺,基于此平臺以C語言和匯編語言在DSP集成化軟件開發環境CCS上加以實現。協議轉換系統在滿足實時性和可靠性要求的前提下,軟、硬件盡可能地簡化;在結構上盡量模塊化,同時便于監測、安裝、維護和檢修。為了驗證協議轉換系統的功能和性能是否完全符合要求,對協議轉換系統進行了測試,并最終實現了聯機驗證。結果表明,該系統完全符合設計要求,完成了系統所應具有的所有功能。