0 引言

    目前，射頻識別技術（RFID）已在多個領域中被廣泛使用，但RFID應用系統是典型的硬件平臺相關性系統，通常具有難以維護、更新、移植等特點^[1]，其中存在大量重復工作。軟件構件技術是指通過組裝一系列可復用的軟件構件形成軟件系統的軟件技術，以軟件構件為基礎，設計一個合理的構件化工程框架是降低工程開發的難度，提升軟件的可重用性、可移植性和可維護性的有效途徑^[2]。本文針對RFID應用系統的特點，通過對RFID一般應用模型的分析，封裝了構件相關函數，并給出了結構清晰合理的RFID構件化工程框架，有效提高了RFID應用系統的開發效率。同時以思卡爾KL25 MCU和射頻芯片RC531構成的實驗裝置為基礎，在Kinetis Design Studio集成開發環境中對該構件框架的使用進行了具體測試，并分析了該構件框架在其他嵌入式系統上的移植應用，對提高系統開發的規范性和可移植性具有重要參考意義。

1 RFID驅動構件的設計及解析

    構件設計的目標是可重用，達到此目標的關鍵是構件提供了契約式的接口，它的輸入接口代表了環境為它提供的服務，輸出接口代表了它為環境提供的服務。一個接口提供一種服務，完成某種邏輯行為[3]。構件接口由兩部分組成：一是署名部分，即構件本身提供服務的描述，由構件頭文件（.h）實現；二是行為部分，即構件行為的描述，由源文件(.c)實現。因此，為提高構件可重用性，在設計軟件構件時，必須對構件的共性和個性進行分析，抽取出構件的屬性和對外接口函數。盡量做到：當一個構件應用到不同系統中時，僅需修改構件的頭文件，對于構件的源程序文件則不必修改或改動很小。

1.1 RFID應用系統的一般模型

    通過分析RFID應用系統的共性，可以建立一個由3部分組成的一般系統模型^[4]，如圖1所示。控制MCU主要提供對射頻讀寫芯片的控制操作；射頻讀寫芯片及輔助電路用于實現與控制MCU的數據通信并控制與標簽的通信操作；天線部分則實現電磁波的收發。

    以蘇州大學飛思卡爾嵌入式中心開發的 RFID實驗裝置為例，KL25作為控制MCU，是整個硬件系統的核心；射頻讀寫芯片RC531與KL25通信實現各種功能。RC531支持并行接口或SPI接口兩種方式實現與控制MCU的通信。任意一款MCU只需按表1所示提供對應的GPIO引腳即可以模擬SPI的方式控制RC531芯片。

1.2 構件函數封裝

    在RFID系統中，射頻讀寫芯片RC531作為KL25的外設^[5-6]，是驅動構件的對象。

    RC531對A類卡的通信處理流程如圖2所示。首先，發送Request詢卡命令給天線工作范圍內的所有卡片，卡片在上電復位后響應該命令；隨后通過防沖突循環，根據卡的序列號選中一張卡；接著對準備訪問的卡片的存儲區的密碼進行鑒別；在通過了密碼驗證后，讀寫模塊可以對該存儲區的數據進行讀、寫、增值、減值以及掛起等操作^[7]。

    根據該處理流程，從上層應用的角度出發，可不必關注防沖突、密碼驗證等過程，只需要關注對存儲區的具體應用。因此RC531構件只需要對A類卡提供初始化、讀寫數據等功能函數，而防沖突等操作可作為內部函數處理。同理根據B類卡的處理流程，構件需要提供初始化、讀取卡號等函數。

    綜合以上分析，在RC531構件頭文件中的內容應主要包含外設模塊寄存器相關信息的定義和函數原型的聲明。前者指明了本“元構件”與具體硬件相關的信息，而后者則給出了本驅動構件對上層構件或應用程序所提供的接口函數。另外從硬件的角度看，控制射頻模塊只需要確定MCU與RC531的接口一個要素即可，但由于KL25的每個引腳都需要確定端口號與引腳號兩個部分，所以在應用中將這兩個部分組合為一個值，方便理解與調用。通過這種設定，上層構件在使用它時，將具有極大的靈活性。構件源程序文件實現對外接口函數功能，構件內部使用的函數也在構件源程序文件中定義。最終在頭文件中應給出MF_Init(初始化)、MF_ReadCardA(讀A卡)、MF_WriteCardA(寫A卡)、MF_Deduct(電子錢包充值)、MF_Recharge(電子錢包扣款)、MF_Halt(掛起)、MF_ ReadCardB(讀B卡)等功能函數。以初始化函數為例，其需要完成的功能為：將KL25的GPIO接口初始化為SPI形式，將RC531復位并將天線接口初始化為A類或B類通信狀態。因此初始化函數的封裝需要提供一個通信協議類型的參數，并需要返回一個狀態值反映初始化是否成功。

//將KL25部分GPIO口定義為模擬SPI功能

//MFRC531的MOSI引腳

#define MF_MOSI_PIN

        (GPIO_PORT_D << 8) | 3

//MFRC531的MISO引腳

#define MF_MISO_PIN

        (GPIO_PORT_D << 8) | 5 

…

/函數名稱：MF_Init

//功能概要：復位芯片并根據標簽類型初始化

//參數說明：ProMode： A類協議 Pro_A

//                    B類協議 Pro_B

//函數返回：錯誤碼 MI_OK：初始化成功

//                 MI_NOTAGERR：失敗

uint_8 MF_Init(uint_8 ProMode)；

…

2 工程框架設計

2.1 工程框架的組織原則

    按照軟件工程的思想，框架是一個能夠被開發人員實例化的系統構架，規定了應用軟件的體系結構，定義了模塊和對象的分割，確定了各部分的主要職責、協作關系及控制流程^[8]。工程框架的設計和組織必須是可復用、可移植和可理解的，以利于提高嵌入式軟件的開發效率。因此，本文在設計中遵循以下的原則^[9-10]：

    (1)系統結構分層，軟件與硬件分離。

    首先，應用系統按照用戶、業務邏輯、驅動進行分層，將不同層次的構件文件組織在不同文件夾下，使框架可即插即用替換構件；其次，從不同的層次中分別提煉出高層構件和底層構件，高層構件與硬件無關，而底層構件與硬件密不可分，是硬件驅動程序的封裝。高層構件實現一個具體應用，而底層構件是對硬件驅動程序的封裝；同時在硬件構件層中，相對于核心構件最小系統而言，中間構件和終端構件都是核心構件的“外設”，將這些“外設”的驅動程序封裝而成的軟件構件作為底層外設構件。底層外設構件可以調用底層內部構件，而高層構件可以調用底層外設構件和底層內部構件中的功能構件。

    （2）將芯片特性分離

    每款芯片都擁有自己的內核及芯片初始化文件，這些文件由芯片設計人員提供，具有特定的內容。將這類文件組織在一起，這樣針對某一款芯片進行開發時，應用開發者不必修改該目錄。

2.2 工程框架的組織形式

    通過RFID應用系統模型，可將射頻讀寫芯片作為外設構件處理。基于框架的組織原則，通過對工程框架的目錄名和共性的文件歸納分類組織，得到符合要求的構件化工程框架。以基于KL25的RFID工程為例，其在KDS1.1.1開發環境下的目錄結構組織如圖3所示。

    整個框架中的目錄按照開發系統所應用到的文件順序排列，各目錄中存放文件的原則如下：

    Includes目錄存放開發環境相關的文件，由工程自動生成。

    01_DOC中存放工程說明文檔，工程有變化時，即時更新。

    02_CPU、03_MCU目錄分別存放與內核及芯片相關的公共文件，其中包含了幾乎所有底層構件都涉及的MCU寄存器的宏定義、啟動代碼等文件。

    04_Linker_File中存放鏈接腳本文件，描述程序文件在芯片存儲區中的存放順序，該文件與編譯器相關。

    05_Driver、06_App_componet目錄分別存放底層硬件的驅動構件及高層構件文件，底層構件是硬件系統各功能模塊的驅動封裝，如讀寫芯片RC531的構件文件等；高層構件用于實現具體的應用功能。

    07_Soft_component目錄存放穩定、移植性良好、與硬件無關的抽象構件文件，如數值類型轉換算法等，如此則實現了業務、邏輯、數據的完全分離。

    08_Sources目錄包括總頭文件includes.h、主函數文件main.c以及中斷函數文件isr.h、isr.c。main.c文件是工程任務的核心文件，用戶的應用都添加在該文件中。總頭文件中包含主程序文件中需要的驅動構件頭文件、變量聲明等；isr.c中包含了中斷函數的實現代碼，isr.h是isr.c文件的頭文件，存放中斷函數聲明，因為中斷向量表文件是工程框架的重要內容之一，因此，在工程框架中，用戶應避免直接對中斷向量表文件進行修改，而采用“注冊”的方式為用戶提供編程接口，既方便用戶使用，同時也提高了系統編程的安全性。

3 工程在框架下的移植分析

    在實際應用中，工程的移植有多種情況。以KL25下的RFID應用工程為例，當需要在相同的硬件環境下設計不同的工程時，只需以該工程為模板，在05_Driver目錄下添加需要的底層構件，并在08_Sources目錄下修改主函數中的任務，即可在其余文件保持不變的情況下，快速開發出新的應用工程。這種情況下應用工程之間的可移植性最大。

    當將工程移植到相同或相兼容內核的芯片時，僅需修改03_MCU目錄下的芯片文件，以及根據硬件連接方式在05_Driver目錄下修改RC531構件頭文件中的引腳定義，已有的工程即可在新的目標芯片下運行。如將KL25上的工程移植到Cortex-M4內核的K60芯片時，只需將頭文件中的引腳定義修改即可。

//將K60部分GPIO口定義為模擬SPI功能

//MFRC531的MOSI引腳

#define MF_MOSI_PIN

        (GPIO_PORT_E << 8) | 19

//MFRC531的MISO引腳

#define MF_MISO_PIN

        (GPIO_PORT_E << 8) | 1

…

    當工程移植到不同內核的芯片時，由于硬件結構一般變化較大，通常需要修改02_CPU、03_MCU、08_Sources目錄下的中斷注冊文件等與芯片直接相關的系統文件，同時還須修改GPIO的驅動，但設備構件文件的結構及工程框架依然可以保持不變。可見在該框架下，工程組織非常清晰，移植也很方便。

4 工程框架應用與測試

    測試工程在KDS1.1.1開發環境和SD-FSL-KL25-EVB開發板上進行，測試工程實現的功能為：KL25的串口1與PC通信，接收讀取M1卡中數據塊5中數據的控制命令，實現框架的中斷服務功能；查找并讀取標簽中的數據，通過串口1將數據顯示在PC上。要實現以上功能，需在框架isr.c文件中添加串口1的中斷服務例程，并在isr.h文件中實現中斷注冊，然后在主函數文件中分別調用RFID初始化、讀數據構件與串口發送數據構件即可。主函數部分代碼如下：

    MF_Init(Pro_A)；

    for(；；)

    {

     If(1==read_flag)

     {

    if(MI_OK == MF_ReadCardA

    (ReadDataBuff, Key,BlockNo))

    {

      uart_send_string(UART_1, "Read Success!\r\n"); 

    //將讀取的數據轉換為16進制字符形式

       …

    //將數據輸出

       uart_sendN(UART_1,16,DataBuff)；

    }

    else

　　　　{

           uart_send_string(UART_1, "Read failed!\r\n")；

        }

    }

    …

    將測試工程編譯后下載到目標板，將開發板上的串口1與PC連接運行，從串口測試工具中發送控制命令“R11”，可以觀察到接收窗口中穩定地回送數據，如圖4所示。測試結果表明在該工程框架下，工程任務建立簡便，運行穩定，控制邏輯清晰可靠，能夠滿足工程運行的需求。

5 結論

    RFID應用系統在市場中被廣泛使用，但RFID開發原理較為復雜，同時在開發中存在大量重復工作。設計一個合理的開發框架有助于封裝底層構件，幫助開發者高效地開發出穩定的嵌入式RFID產品。本文根據軟件工程思想，對RFID構件分析并封裝了MF_Init、MF_ReadCardA、MF_WriteCardA、MF_Deduct、MF_Recharge、MF_Halt、MF_ ReadCardB等功能函數，并給出了結構清晰合理的構件化工程框架，對提高RFID應用系統開發的規范性和可移植性具有重要參考意義。同時以飛思卡爾KL25 MCU和射頻芯片RC531構成的實驗裝置為基礎，給出了測試工程的創建及測試過程，為RFID應用系統開發提供了一個結構清晰、層次分明、可移植性強的開發模板。

參考文獻

[1] 譚民，劉禹，曾雋芳.RFID技術系統工程及應用指南[M].北京：機械工業出版社，2007.

[2] 楊芙清，梅宏，黃罡.構件化軟件設計與實現[M].北京：清華大學出版社，2008.

[3] MOREIRA F A，SOLIVEIRA M F.A model-driven engineering framework for embedded systems design[J].Innovations in Systems and Software Engineering，2012，8(1)：19-23.

[4] 王慧明.RFID開發平臺的設計及其應用[D].蘇州：蘇州大學，2009.

[5] ARM.Cortex-M0+ technical reference manual[EB/OL].(2012-03-01)[2015-04-20].http：//www.Freescale.com.cn.

[6] 王宜懷，朱仕浪，郭蕓.嵌入式技術基礎與實踐-ARM Cortex-M0+ Kinetis L系列微控制器[M].北京：清華大學出版社，2013.

[7] Philips Semiconductors.Mifare MF RC531 ISO 14443 readerIC data sheet[EB/OL].(2005-12-01)[2015-04-20].http：//www.nxp.com.

[8] 凌藝春，黃飛.匯編程序移植性的研究與實踐[J].制造業自動化，2011，33(3)：174-175.

[9] SZYPERSKI C，GRUNTZ D，MURER S.Component software：beyond object-oriented programming[M].Addison-Wesley，2002.

[10] 張倩，楊玉宇.《系統與軟件可移植性》標準中可移植性定義的研究[J].信息技術與標準化，2009，35(10)：51-54.