摘  要: 討論了基于Linux平臺的A/D采集卡的工作過程及在工業控制中采用Linux操作系統進行應用開發的方式,特別對利用Linux可加載核心模塊(LKM)開發A/D采集卡驅動的相關核心機制及調用作了詳細討論。

　　關鍵詞: LKM  核心驅動  溫度采集卡  工業控制  ISA

 

　　Linux操作系統經過十多年的發展,以其運行穩定可靠、占用資源少、長期運行仍能保證效率的特性,獲得了眾多的企業和政府部門的認可。近幾年,在工業控制中Linux也有非常好的表現,控制領域中RTLinux應用研究正在進行。筆者開發了Linux供熱控制平臺。在此Linux控制系統應用研究中著重研究了核心可加載驅動模塊機制。本文將詳細討論采集卡的核心驅動模塊。

1 硬件介紹

　　P51系列A/D采集卡是一個8通道ISA總線的溫度采集卡。它將溫度傳感器(熱電偶、熱電阻等)的輸出信號或電流、電壓通過A/D轉換器轉換成數字量。其主要特點:精度高、抗干擾能力強、可靠性高。

1.1 P51采集卡的工作過程

　　圖1說明了接口板采集數據的整個過程。

 

 

　　每個通道數據以16位二進制原碼形式輸出,低字節在前。8個通道16字節數據按順序輸出。

1.2 I/O端口

　　主機與接口板的接口使用2個輸入端口,由于A0未參加譯碼,實際上占用了4個端口地址。接口板的地址可由板上的跳線開關設定。地址默認設置為164H及166H，如表1所示。

 

 

　　該硬件只用到了2個I/O端口:狀態口和數據口,字長都是8位。其中,狀態口只用D0位作為檢驗數據是否已經準備好的標志,其它位沒有定義。

2 軟件部分

　　軟件部分由應用程序和設備驅動程序兩部分構成,本文主要討論設備驅動程序部分。在Linux平臺上實現對硬件的驅動支持可以有兩種方式:一種直接在用戶空間實現;另一種使用Linux內核中提供的機制來實現�？紤]到用戶空間驅動程序的局限性,在開發中采用了第二種方式。

2.1 LKM機制簡介

　　Linux內核提供了兩種機制來開發設備驅動程序:一種直接把驅動程序聯編到內核中;另一種則是通過稱為Linux可加載模塊(LKM)機制來開發可動態加載和卸載的驅動模塊。基于各方面的考慮本文采用后者。

　　Linux作為單核結構效率比較高,但是系統靈活性不足。為了平衡這兩者的關系,提供了LKM 機制。利用這種機制可以開發Linux內核模塊,并且可以動態地對它加載和卸載。Linux下的設備驅動程序一般都支持這種方式,且模塊被加載到內核后,它就可以任意利用內核提供的各種資源和服務了。Linux內核維護了一張所有內核資源的符號表(稱為內核資源符號表),用于在模塊載入時解決相應資源的引用問題。并且,Linux允許模塊的堆棧操作,一個模塊可以使用其他模塊提供的資源。也就是說:一個模塊對另一個模塊資源的使用與其對內核資源的使用非常相似,不同的只是這些服務的資源從屬于另一個模塊而已。每當一個模塊被加載,Linux就會修改內核資源符號表,將該模塊所提供的服務和資源加入進去。這樣另一個模塊載入時,如果需要就可以引用這個模塊的資源了。

　　卸載一個模塊時,需要知道當前模塊是否正在被使用。如果沒有被使用,在卸載時要能夠通知該模塊它將被卸載,以便由它自己釋放已被它占用的系統資源。同時Linux還要從內核資源符號表中刪除該模塊提供的所有資源和服務。

　　從上面的原理分析可知,內核模塊編寫時,有兩個主要的接口函數:init_module()用于在模塊加載時注冊服務和申請資源;cleanup_module()用于在模塊卸載時清除掉由init_module()所做的工作,從而使內核模塊可以安全地卸載。其中對init_module()的調用是在根用戶執行insmod命令加載模塊時。而對cleanup_module()的調用是在根用戶執行rmmod命令卸載模塊時。

2.2 Linux下設備驅動程序

　　系統調用是操作系統內核和應用程序之間的接口，設備驅動程序是操作系統內核和機器硬件之間的接口。設備驅動程序為應用程序屏蔽了硬件細節。在應用程序看來，硬件設備只是一個設備文件， 可以通過相應的系統調用象操作普通文件一樣對硬件設備進行操作。

2.2.1 Linux設備分類

　　Linux支持兩種標準硬件設備:塊設備和字符設備。塊設備接口僅支持面向塊的I/O操作,所有I/O操作都通過在內核地址空間中的I/O緩沖區進行,它可以支持幾乎任意長度和任意位置上的I/O請求,即提供隨機存取的功能。字符設備接口支持面向字符的I/O操作,只支持順序存取的功能,一般不能進行任意長度的I/O請求。I/O請求的長度必須是設備要求的基本塊長的倍數。

2.2.2 設備標識方式

　　Linux設備由一個主設備號和一個次設備號標識。主設備號唯一標識了設備類型,即設備驅動程序類型,它是塊設備表或字符設備表中相應表項的索引。次設備號僅由設備驅動程序解釋,一般用于識別在若干可能的硬件設備中,I/O請求所涉及到的那個設備。值得一提的是次設備號還可以被分成幾個部分,用來區分子設備驅動程序和具體的設備。

2.2.3 Linux設備驅動程序組成部分

　　Linux設備驅動程序可以分為三個主要組成部分:

　　(1)自動配置和初始化子程序。負責檢測所要驅動的硬件設備是否存在并能否正常工作。如果該設備正常,則對這個設備及其相關的設備驅動程序需要的軟件狀態進行初始化。

　　(2)服務于I/O請求的子程序。主要是file_operations結構的各個入口點的實現。這部分的實現支持文件系統調用(如open、close、read等)。

　　(3)中斷服務子程序。在Linux系統中,并不是直接從中斷向量表中調用設備驅動程序的中斷服務子程序,而是由Linux系統接收硬件中斷,再由系統調用中斷服務子程序。

2.3 溫度采集卡驅動程序內核模塊

2.3.1 file_operations結構的初始化

　　file_operations結構是Linux操作系統中用于實現驅動程序的最重要的數據結構,它為Linux提供的服務于I/O請求的子程序的代碼實現提供了一系列入口點。該結構貫穿在整個驅動程序中,筆者在文件作用域內進行了定義,并對本程序中用到的入口點做了初始化，其偽代碼如下:

　　struct file_operations p51_fops=}

       open ： p51_open；  　　　　　//把實現的p51_open函數指針賦給open入口點。

       release ： p51_release； 　　 //把實現的p51_release函數指針賦給release入口點。

       read ： p51_read；            //把實現的p51_read函數指針賦給read入口點。

　　{

2.3.2 模塊初始化與模塊卸載

　　溫度采集卡模塊初始化通過對init_module()的實現來完成以下幾個任務:

　　(1)以字符設備類型向系統注冊溫度采集卡設備,同時動態獲得主設備號。通過調用下面這個函數來實現:

int register_chrdev(unsigned int major， const char * name， struct file_operations *fops);

    這里使major參數為0,這樣系統就會動態地分配并返回主設備號。name參數是用于標識設備的字符串。file_operatons傳入的是如前所述的p51_fops。

　　(2)向系統申請溫度采集卡的I/O端口地址。根據前面提到的跳線方法得到I/O地址,調用系統提供的宏:

　　check_region(start，n)    　　　 //檢查端口地址范圍start～start+n-1是否可用,是則返回0,否則返回1。

　　request_region(start，n，name)   //用于申請通過上述函數檢查的地址范圍。

　　(3)做一些必要的系統日志,根據各種條件用printk向系統日志緩沖區寫入不同級別的信息。

　　(4)控制內核資源提供的符號表輸出的符號信息(即在LKM簡介部分提到的模塊要注冊的服務)。這里使用EXPORT_NO_SYMBOLS使得該模塊不輸出任何符號信息。

　　溫度采集卡模塊卸載需要完成以下幾個任務:

　　(1)調用release_region(start，n)宏，釋放模塊初始化時申請的I/O端口資源。

　　(2)調用int unregister_chrdev(unsigned int major， const char * name)向系統注銷該字符設備。本程序中major參數是前面注冊時動態獲得的主設備號,name與注冊時提供的name字符串相同。

　　(3)調用printk函數,做一些必要的系統日志。

2.3.3 file_operations結構中入口點的實現

　　(1)open和release入口點

　　這兩個入口點在本模塊中被賦予的是file_operations結構的p51_open和p51_close函數指針。它們主要通過調用MOD_INC_USE_COUNT及MOD_DEC_USE_COUNT來進行模塊計數。用計數來控制溫度卡驅動模塊是否正在被使用,防止模塊使用中被意外卸載,導致核心對設備操作出現異常。

　　(2)read入口點的實現

　　這個入口點在本模塊中被賦予的是file_operations結構的p51_read函數指針,它是設備操作的核心部分,實現了如下幾個功能:

　　·用inb_p宏訪問硬件的狀態和數據端口,以讀取相應的狀態和數據信息。

　　·調用long sleep_on_timeout(wait_queue_head_t *q， long timeout)把當前進程加入時鐘等待隊列q中,等待timeout時間。從采集卡的工作方式來看,這樣做可以減少輪詢時間,大大提高了效率。

　　·如前所述,程序從溫度卡讀取的是數據的原碼形式,須實現原碼與補碼之間的轉換。

　　·Linux分為核心空間和用戶空間。用戶空間的代碼不能直接訪問核心空間,故需調用Linux核心提供的copy_to_user(to，from，n)宏,把數據從內核空間地址from拷貝到用戶空間地址to中。這樣,系統調用返回后,用戶空間的代碼就可以通過to指針來訪問相應的數據并進行處理了。

　　數據采集核心部分如圖2所示。

 

 

2.3.4 溫度卡故障的處理

　　故障處理在工業控制中非常重要。由于本采集卡在硬件一級對故障預報和發現提供的支持比較少,故在軟件層次上,在滿足需求的情況下通過對狀態口依照前面所提供的方法查詢三次失敗后,將重新對設備進行初始化和設置,再作以上嘗試。如果還是失敗將由用戶進程進行處理。

2.4 應用程序開發

　　對上述模塊編譯并加載后,Linux根用戶可用mknod命令,利用動態分配的主設備號(該設備號在用戶空間,可以從/proc/devices文件中獲得)建立相應的設備文件,并對它設置恰當讀寫權限。就可以在應用程序中,使用Linux的文件系統調用這個設備文件來操作溫度采集卡。這樣做使應用程序編程風格更加統一,代碼更具魯棒性,應用系統更加安全,更易于維護。而且可在核心級保證關鍵部分的實時響應,從而降低了用戶程序開發的難度。

　　對于Linux下的工業控制軟件開發,還有很長的路要走。而其中非常重要的基礎性工作就是對各種工控設備提供穩定可靠的核心驅動模塊的支持。本文所作的工作對此進行了一次很好的嘗試。