謝文彬,殷紅梅,張 欽
(1.淮安生物工程高等職業學校,江蘇 淮安 223200;2.淮安信息職業技術學院 機械工程學院,江蘇 淮安 223003)
數控系統是一種多任務操作系統,實時性要求較高,標準的Linux系統實時性較弱,無法滿足要求。根據實時性要求的不同,實時性可分為硬實時和軟實時兩種,無論是哪種存在問題都會給系統和機床帶來嚴重破壞。Linux內核2.6版本在支持實時性任務方面做出了大量的改進,但仍然無法達到實時嵌入式系統的要求[1-2],如內核不具備完全可搶占性、時鐘粒度粗糙不能滿足要求等。Linux的實時性能改造主要通過內核內部改造與雙內核實時化改造。其中,較為常用的雙內核改造方案使用一定方法能夠使Linux系統對硬實時性進行支持,降低了任務切換延遲和中斷延遲,使應用程序的運行有了充分的時間保證。但依然存在以下缺點:①使用非實時性標準Linux內核的驅動程序來調用處理器資源,雙內核改造方案過多,系統的實時可靠性受到影響;②實時和非實時任務在調用時需要分開考慮,增加了系統設計的復雜性[3-4]。當前,雙內核實時性改造項目中比較具有代表性的有Xenomai、RT-Linux和RTAI等。本文針對基于FPGA數控系統的實時要求,完成基于Xenomai的Linux實時化內核的移植,為基于Linux+Xenomai的實時多任務操作系統的構建乃至數控系統整個軟件平臺的開發奠定基礎。
Xenomai以Adeos(Adaptive Domain Environment for Operating System)為基礎,采用雙內核機制——Linux內核的強實時擴展。其優先級高于Linux內核,它負責處理系統的實時任務,使開發者可以將依賴于傳統RTOS的應用程序性能穩定,并快速地移植到GNU/Linux體系下,這樣可以盡可能地減少應用程序的重新編寫。為了實現以上功能,同時系統仍具有較高的實時性,Xenomai在系統中構建了一個可以用來模擬傳統實時操作系統API的模擬器。該模擬器也被稱作實時微內核,而使用此內核模擬傳統實時API的技術被稱作“Skin”(皮膚),此技術是Xenomai的核心技術之一。通過“Skin”技術,Xenomai實現了多種傳統RTOS的應用編程接口,為在GNU/Linux環境中傳統RTOS的移植提供了極大的方便[5]。
圖1為Xenomai的組成結構,可以看出Xenomai實時內核由多個抽象層組成:工作在系統硬件之上的是Adeos,在Adeos上面的是硬件抽象層HAL,該層和系統所用處理器的體系架構關系最為密切,實時內核層在硬件抽象層HAL之上,它是系統的中間部分,它可以實現通用RTOS基本服務。這些服務可以通過本地和客戶API實現,本地API也被稱作Native。客戶API是建立在實時內核上的,并為傳統RTOS用戶專門設計,比較常用的有RTAI、POSIX、VxWorks、uITRON和pSOS+等。客戶API設計的目的是在Xenomai/Linux體系下做應用程序移植時,傳統RTOS應用程序可以被兼容,同時減少代碼重寫,此種特性盡可能地使Xenomai的穩健性得到保證。Xenomai/Linux架構為系統提供了通過系統接口實現的用戶空間模式和由實時內核實現的內核空間模式。系統穩定、可靠的軟實時性由用戶空間執行模式保證,同時優秀的硬實時性能則通過內核空間模式實現。時鐘模塊管理、定時器處理、同步支持和實時線程調度等實時API所要用到的操作系統服務和資源都是由Xenomai構造的通用模塊提供[6]。
在Adeos模式下,標準Linux和Xenomai被設計為兩個不同的域,Linux域(根域)為Xenomai域提供動態注冊、堆棧分配等必要的基本功能。Adeos系統以Linux為基礎的實現方式決定了Adeos在Linux運行之后啟動,但是為了保證系統啟動階段的實時性,Adeos在啟動階段就要獲得系統中斷管理的控制權。在初始化完成之后,Xenomai和Linux的協調運行方式可以分為兩種:主動運行方式與被動運行方式。主動運行方式的特征是:當前域在處理任務和中斷請求的過程中不會被高優先級的域打擾,此域在任務完成之后被主動掛起。與之相反的是被動運行方式,指當前域被系統出現的優先級別更高的域中斷運行,從而該域被動掛起。

圖1 Xenomai的組成結構
域的切換工作在ipipe_suspend_domain()函數中實現,在Linux系統中cpu_idle()會調用此函數,同時在Xenomai域中即使系統處在空閑階段時也會一直運行此函數[7]。域切換函數ipipe_suspend_domain()的執行模式是在當前域下首先檢測下一個域中是否存在需要處理的任務,如果存在則將程序執行權交給該域對任務進行處理,如果沒有則跳過該域繼續沿著中斷管道向下查找有任務需要處理的域。域中有需要處理的中斷任務和該域擁有比當前域更高的優先級是域能夠被切換進入的兩個必備條件。在Adeos系統中,Xenomai負責管理實時任務,為了使實時任務運行時不會受到Linux內核任務的影響,確保實時任務能夠在指定的時間內完成,Xenomai域優先級的設置要比Linux域的高。
根據上文敘述及Xenomai的工作原理,基于Xenomai的Linux實時系統改造方案框架如圖2所示。將Xenomai移植到標準的Linux系統內核中主要有以下兩個步驟:構建Linux實時內核系統和交叉編譯Xenomai的庫文件。

圖2 基于Xenomai的Linux實時系統改造方案框架
在官方網站上下載“潔凈”的內核文件Linux2.6.4,同時下載Xenomai-2.4.3源碼包,Xenomai源碼提供了修改Linux內核時需要的Adeos的內核補丁。在虛擬機中端執行以下命令:
#$Xenomai_root/scripts/prepare-kernelsh-arch=arm
-adeos=Sxenomai_root/ksrc/arch/arm/patches/adeos-ipie-2.6.20-arm-1.8-03.patch-linux=$linux_tree
其中:$Linux_tree代表Linux源碼包的位置;$Xenomai_root代表Xenomai源碼包的位置;-arch=arm用來指定目標平臺是基于ARM架構的;-adeos指定選擇使用的補丁文件和文件的位置。
成功打好補丁之后,可以看到內核中新增加了Real-time選項,如圖3所示。

圖3 Xenomai配置信息
內核配置過程中,為防止標準內核與實時內核的配置中發生沖突,一些配置選項需要重新設置:
將內核“可搶占式”模式開啟,關閉Power Management support(Power management option(ACPI,APM);關閉Module versioning support;關閉CPU Frequency scalling。因為ARM處理器不具備浮點數處理單元(FPU),所以CONFIG_XENO_HW_FPU也要選擇關閉。根據實際需求在Xenomai的Interface子系統中選擇合適的接口,并將其編譯到內核模塊之中。完成配置后,在終端中執行“make zImage”命令就可以得到基于Xenomai的實時Linux系統內核。
為了得到Xenomai提供的API的運行,需要將Xenomai源碼編譯以得到需要的庫文件。在中斷中執行以下命令:
#$Xenomai_tree/configure--build=i686-pc-linux-gnu--host=arm-linux
--able-arm-mach=s3c2440--enable-arm-tsc
#make
其中:--build指定宿主機的開發環境;--host用來指定交叉編譯環境;--enable-arm-mach用來指定目標平臺(s3c2440處理器);--enable-arm-tsc用來開啟tsc。將編譯得到的Xenomai動態鏈接庫文件拷貝到根系統的lib文件夾下,以備Xenomai程序運行時調用。
以上對Linux+Xenomai的系統做了詳細的分析,并且在s3c2440處理器上完成了基于Xenomai的Linux系統的移植,為具有強實時性的數控系統提供了軟件平臺。接下來對此軟硬件系統進行整體測試,用來驗證此系統能夠滿足數控系統的要求。
一個隨機的控制任務發出請求到該任務被實際執行之間的時間間隔被稱作任務調度延遲,任務調度延遲的長短是影響系統實時性的一個重要指標[8-9]。系統處理任務的時間和任務調度延遲的時間合在一起組成固定的時鐘粒度,由此可以看出,任務調度延遲所用的時間越長留給系統處理任務的時間越短。Xenomai對于任務調度延遲提供了可以直接使用的代碼。Xenomai中的可執行文件latency可以被用來測試用戶模式下任務調度延遲、內核模式下任務調度延遲和定時器中斷延遲。為體現模擬的真實性,首先執行“dd if=/dev/zero of=/dev/null&”語句模擬CPU的重載情況,然后再進行相關測試。
執行“./latency-t0-T20-p500-h-s”,對用戶模式下的任務的調度延遲進行測試;執行“./latency-t1-T20-p500-h-s”,對內核模式下的調度延遲進行測試。-t為設定測試的類型:0表示對用戶模式下的任務的調度延遲進行測試,1表示對內核模式下的調度延遲進行測試,2表示定時器的中斷延遲測試;-p用來表示設定任務周期,單位為微秒,此處設計為500 μs;-T表示設定持續時間,單位為秒,此處設置為20 s;-h表示打印測試記錄中的最小、平均、最大延遲時間;-s表示打印統計測試過程中的最小、平均、最大延遲時間。用戶態下測試結果和內核態下測試結果如圖4和圖5所示。從測試結果可以看出:在系統負載比較高的情況下,任務調度延遲在用戶空間和內核空間內分別為5 μs~6 μs和1 μs~2 μs,由此可以看出此系統在實時性方面有很高的優勢。

圖4 用戶態下測試結果
在數控系統中存在許多隨機事件,這些事件都會轉換成任務驅動中斷,如果系統無法對這些中斷進行快速的響應,將會給系統帶來無法預測的后果,因此對于定時器中斷的測試是十分必要的。同樣執行語句“./latency-t2-T30-p500”對系統進行測試,定時器中斷測試結果如圖6所示。從圖6的測試結果可以看出:在系統負載比較高的情況下,定時器中斷延遲測試的結果為5 μs~6 μs,由此可以看出此實時系統在定時器中斷響應方面具有很大的優勢。

圖5 內核態下測試結果

圖6 定時器中斷測試結果
本文結合數控系統的實時性要求和對于標準Linux實時性不足的分析,提出了基于Xenomai的Linux系統實時性改造方案,完成基于Xenomai的Linux實時化內核的移植,并在s3c2440芯片上實現此實時系統,最后通過3個實時性能指標的測試,驗證了基于Xenomai的Linux實時性改造方案在數控系統中的可行性。