射頻識別（RFID）是一種非接觸式的自動識別技術，它通過射頻信號自動識別目標對象并獲取相關數據，識別過程無需人工干預，可工作于各種惡劣環境。RFID技術在許多領域得到應用，如停車場管理、集裝箱運輸管理系統等。在大多數應用中，只要求有固定的閱讀器，但在某些特殊系統中(如集裝箱運輸管理系統)，不僅要求有固定的閱讀器，而且還要求有手持式讀卡器。
　　TagMaster AB公司是世界知名的RFID讀卡器制造商。它提供性能優良的固定式閱讀器，也提供一種手持式閱讀器。手持式讀卡器由Caiso公司的工業級PDA（Personal Digital Assistants）和TagMaster AB公司的S1510組成。PDA雖然功能強大，但有如下缺點：(1)提供的觸摸屏輸入方式過于精細，不適合工作人員現場操作；(2)TFT液晶顯示屏在強光下顯示效果差，耗電量大，并且在低溫下（0℃以下）無法工作，因此不適合室外工作；(3)采用Microsoft公司的商用系統WinCE，成本高。
　　本文介紹一種基于嵌入式Linux的便攜式RFID信息采集與處理系統。它采用高性能的32位ARM920T系列微處理器、8鍵的鍵盤及OLED顯示屏，結合S1510實現了對電子標簽卡信息的采集、處理及實時顯示，很好地解決了上述問題。
1 系統組成
　　系統采用Atmel公司的AT91RM9200 32位高性能處理器、TagMaster公司的S1510及OLED顯示模塊" title="顯示模塊">顯示模塊等實現電子標簽卡信息的采集、處理、實時顯示及與上位機" title="上位機">上位機通信等功能。系統組成如圖1。

1.1 微處理器
　　系統采用Atmel公司以ARM920T為核心的AT91系列微處理器AT91RM9200。它最高主頻可達180MHz，具有先進的節電技術，集成了SDRAM、Flash、紅外、USB等接口。系統采用USB（Universal Serial Bus）及紅外方式與上位機通信。紅外方式采用Agilent公司的HSDL-3602紅外收發器實現。
1.2 射頻識別模塊
　　射頻識別模塊采用瑞典TagMaster AB公司的2.4GHz產品S1510。該模塊體積小，專為手持設備設計，可以采集1米內各種電子標簽上的數據。它通過USART串口與處理器通信，接口簡單，易于硬件實現。為了保證數據的可靠傳輸，模塊與微處理器通信采用TagMaster AB公司開發的應答式串口通信協議ConfiTalk。
ConfiTalk協議是一種面向字符的應答式串行通信協議。它每次傳輸一定長度的數據塊（幀），每個幀包含幀頭(STX)和幀尾(ETX)。為了提高數據傳輸的可靠性，每幀又加入了8位的校驗位(CS)及地址位(ADR)。幀的結構如圖2。

　　MESSAGE代表任意長度的信息。協議規定微處理器發送給S1510的幀為命令幀，返回的幀為應答幀。本系統使用的S1510是TagMaster AB公司的最新產品，它支持基于ConfiTalk協議的MAIL命令方式的數據傳輸。MAIL命令方式通信也就是把幀中的MESSAGE域統一成四種格式，其中命令幀有MAIL_SEND和MAIL_RECEIVE兩種，分別表示S1510接收用戶信息和返回卡信息(包括卡號、卡狀態和卡存儲的數據)，如圖3。
　　應答幀有兩種：MAIL_SEND的應答幀和MAIL_RECEIVE的應答幀，如圖4。

?

　　圖4中，36表示S1510使用MAIL方式處理命令幀和應答幀，而4、5表示S1510命令幀的類型(MAIL_SEND或MAIL_RECEIVE)；Status表示該命令的執行狀態（成功或失?。?；MAIL_SEND命令幀中的Data域表示用戶要進行的操作及參數，如使Data=WRITE：參數：數據，即表示用戶要將數據寫入電子標簽卡；MAIL_RECEIVE的應答幀中的Data域為用戶所要求得到的數據。
　　當使用MAIL命令方式讀寫標簽卡時，用戶只需要按幀的格式填充各域，然后利用ConfiTalk協議提供的API函數發送到S1510即可。命令清晰明了，大大方便了用戶的開發。
1.3 OLED顯示模塊
　　系統采用萊寶科技有限公司的OLED顯示模塊RGS24128064YW001。有機發光顯示器OLED（Organic Light Emitting Display）被譽為“夢幻顯示器”。與液晶屏相比，OLED顯示屏更輕更薄、可視角度更大，能夠顯著節省電能，并且在-40℃的低溫下仍可以正常工作。RGS24128064YW001具有串行和8位并行數據接口。系統采用8位并行接口與微處理器通信。
1.4 SDRAM和Flash及自定義鍵盤
　　系統采用32位的同步動態隨機存儲器(SDRAM)作為系統內存，16位的Flash作為不可丟失數據存儲器。用戶可以通過8鍵的鍵盤進行各種操作，如讀卡、寫卡等。
2 系統軟件設計
　　系統軟件是整個系統的靈魂，其設計的好壞直接影響系統的穩定性和可擴展性等性能。系統設計將軟件分為兩層結構，如圖5所示。最下面一層為操作系統層，主要實現對Linux操作系統的移植和各種設備驅動程序" title="設備驅動程序">設備驅動程序的編寫，包括OLED模塊、USB Device、紅外、鍵盤等設備驅動程序。上一層為應用程序" title="應用程序">應用程序層，主要實現卡信息顯示、鍵盤掃描、電子標簽卡讀寫、文件傳輸、時鐘以及電池電量檢測等功能。

2.1 嵌入式Linux
　　Linux是一種公開源碼的多任務操作系統，具有開放度高、安全性好、穩定性強、可移植性好等特點，在嵌入式操作系統中被大量采用。
　　本設計采用的Linux內核是在ARM-Linux的基礎上，編寫了OLED顯示模塊、USB 設備、紅外收發器及鍵盤的設備驅動程序。在Linux系統中，設備驅動程序占有很重要的位置，它提供了在用戶空間操作硬件設備的接口。Linux系統將設備分為字符設備、塊設備及網絡設備三種，并給出針對不同設備的數據結構及注冊函數。當用戶開發設備驅動程序時，只需按硬件操作的方法填充設備數據結構，并將它注冊到內核中即可。
　　為了方便用戶應用程序的編寫，把USB設備實現為CDC（Communication Device Class）類設備，其驅動程序分為兩層，最底層操作AT91RM9200上的USB設備控制器，如處理硬件中斷、讀寫寄存器及操作I/O口來檢測設備的插拔；上層實現了底層與TCP/IP協議層的連接，主要是模擬物理網卡，并注冊到內核。這樣，在應用程序的USB設備就是一個標準的網絡設備，用戶不需要了解驅動程序的接口，而直接使用Linux提供的套接字進行網絡通信程序的開發。當用戶進行二次開發時，可以不加修改地將上位機開發好的網絡通信程序直接移植到本系統中，而且可以通過上位機的Telnet等工具對嵌入式系統進行一定的操作。
　　其他驅動程序(如OLED顯示模塊、鍵盤、紅外收發器)都作為Linux下的標準字符設備編寫，使用register_chrdev( )函數進行注冊，提供了讀、寫和控制操作。在Linux系統中，應用程序對字符設備的操作與文件的操作相同。
　　Linux中設備驅動程序可以通過模塊方式動態地加載和卸載，也可以直接編譯到內核中。前者使用靈活，可以減小內核，但因嵌入式系統要求所有設備在初始化后全部就緒，不能在使用時加載設備的驅動模塊。所以，本系統中所有的設備驅動程序都直接編譯進內核。
　　每個設備驅動程序在用戶空間對應一個設備文件，由文件系統管理。本系統使用ext2作為根文件系統。為了開發和升級方便，首先將根文件系統做成RAMDISK格式，所謂RAMDISK就是系統啟動后將壓縮的文件解壓到內存，形成一個虛擬硬盤；然后，將引導程序、內核映像及根文件系統燒寫到Flash中。
　　系統加電后，引導程序將內核映像從Flash中調入內存，然后從核入口開始執行：首先初始化CPU，然后加載各個設備驅動程序，最后掛載文件系統，執行應用程序。
2.2 應用程序設計
　　Linux是多任務系統，支持多線程及多進程。多線程的優點是線程比進程小，可以使應用更輕便，線程間通信方便；缺點是所有線程使用同一個地址空間，如果一個線程出現問題，整個系統將受影響；而進程各自占有一份內存空間，可以增強系統的穩定性，但是多進程增加了系統開銷，進程間通信復雜。為此，根據實際情況，考慮到系統穩定性，本系統采取兩者相結合的方式分別完成數據采集處理及文件傳輸功能。
2.2.1 數據采集處理
　　數據采集處理是一個進程，它包括主線程和輔線程。主線程完成電子標簽卡信息的讀取、寫入、實時顯示及查詢；輔線程實現一個時鐘以提供用戶當前時間，并定時對電池的電量進行檢測和動態顯示，在電量過低時發出警告。
　　應用程序用MAIL命令方式完成電子標簽卡的讀寫。該進程首先初始化屏幕，然后等待按鍵中斷，當有鍵按下時，根據鍵值執行相應的工作；當指定時間內沒有鍵按下，系統則進入休眠狀態，從而達到省電的目的。程序流程圖如圖6。

　　當成功采集到標簽卡信息后，應用程序將卡信息(包括卡號、卡狀態、用戶數據及當前時間)通過OLED顯示屏提供給用戶，并寫入一個文件進行記錄。由于文件傳輸進程會將該文件傳輸到上位機，所以當讀寫文件時要將文件上鎖。Linux提供了文件鎖以防止不同進程同時訪問同一個文件。本文使用flock（）函數對文件上鎖和解鎖。
　　由于OLED是圖形點陣式顯示屏，而且Flash容量有限，所以不可能直接使用漢字字庫。系統預先提取所有用到的漢字、數字及字母的點陣數據，然后建立自己的字庫文件，從而使應用程序可以對漢字、數字及字母進行顯示。
2.2.2 文件傳輸
　　文件傳輸是一個進程，完成卡信息的上傳" title="上傳">上傳及其他數據的下載。與上位機通信采用Clinet/Server模型。該進程實質上是一個服務器端（本系統）的應用程序，它循環等待客戶端（上位機）的連接請求。當請求到達時，首先判斷請求來自哪個接口(USB或者紅外接口)，然后根據請求的類型執行相應的上傳或下載?？紤]到實際應用中可能會使用多臺手持式閱讀器，為了方便上位機對信息的管理，規定文件名由手持式閱讀器編號和文件上傳序號組成，程序在上傳文件時自動將其編號及上傳序號加入文件名。該進程的流程如圖7。