基于Linux操作系統的射頻識別安檢設計方案
參數1是調用打開(kāi)數據庫函數sqlite3_open()打開(kāi)的數據庫對象。
參數2 是一條待執行的SQL語(yǔ)句,其語(yǔ)法格式同標準SQL語(yǔ)言規范一樣,如創(chuàng )建 table時(shí)插入的記錄如下:
create table student(id varchar(10) primary key, age smallint);
此語(yǔ)句創(chuàng )建了名為student的表,表中定義了id(學(xué)號)和年紀兩個(gè)變量,其中id是主鍵。
Insert into student values(12345678,21);
此語(yǔ)句向student表中插入一組數據(12345678,21),其中學(xué)號為12345678,學(xué)生年齡為21。
對于數據庫的其他操作,如數據庫更新、修改、查找等用法同上。
參數3 sqlite3_callback是自定義的回調函數,對執行結果的每一行都執行一次這個(gè)函數。
參數4 void *是調用者所提供的指針,你可以傳遞任何一個(gè)指針參數到這里,這個(gè)參數最終會(huì )傳到回調函數里,如果不需要傳遞指針給回調函數,可以填NULL。
參數5 char ** errmsg是錯誤信息。sqlite3里面有很多固定的錯誤信息。執行sqlite3_exec之后,如果執行失敗則可以查閱這個(gè)指針,即可知道執行過(guò)程中錯誤發(fā)生的位置。
3.3 串口同sqlite3通信測試與分析
為了驗證sqlite3數據庫在嵌入式Linux[3-4]終端下的執行效率和穩定性,為此做了一個(gè)簡(jiǎn)單的測試實(shí)驗:通過(guò)上位機程序向嵌入式Linux終端的串口定時(shí)發(fā)送字符串;嵌入式Linux終端接收到字符串便立即寫(xiě)入到下位機的數據庫中。自后查看數據中的數據,看看有沒(méi)有遺漏和誤碼。上位機的程序使用VC6.0開(kāi)發(fā),整個(gè)程序界面只設了一個(gè)按鍵,按下按鍵,上位機就向嵌入式Linux終端不停地發(fā)送字符串數據,按鍵響應程序設計如下:
可見(jiàn)程序是個(gè)定時(shí)100 ms便發(fā)送一條字符串的循環(huán),而且發(fā)送的每一條字符串事先通過(guò)str.Format格式化為固定長(cháng)度,本例中是11 B。按下按鍵后發(fā)送的第一條字符串為:“第1條記錄”,每發(fā)送一條字符串里面的數字加“1”,這樣寫(xiě)到數據庫中就可以很清楚地查看有沒(méi)有遺漏和誤碼,而且可以通過(guò)修改Sleep函數的延時(shí)參數檢測出嵌入式Linux終端下sqlite3數據庫操作的速度。
下位機嵌入式Linux終端的程序設計為:先創(chuàng )建一個(gè)數據庫文件test.db,接著(zhù)就是一個(gè)死循環(huán),串口不停地查找有沒(méi)有數據寫(xiě)入,當檢測到數據時(shí),便寫(xiě)入到test.db中,若寫(xiě)入有誤,則立即跳出循環(huán),終止程序。
4 結語(yǔ)
整個(gè)測試根據上位機串口發(fā)送的頻率不同做了多組實(shí)驗,每組實(shí)驗寫(xiě)入1 000個(gè)數據,最終結果分析如下:上位機在定時(shí)80 ms左右或大于80 ms的情況下發(fā)送數據時(shí),數據庫寫(xiě)入的誤碼率為零;當定時(shí)時(shí)間小于80 ms時(shí),隨著(zhù)定時(shí)時(shí)間變小誤碼率會(huì )越來(lái)越高。通過(guò)數據分析可知原因有以下幾點(diǎn):一是數據庫本身寫(xiě)入需用時(shí)幾十毫秒,二是SD卡并非高速讀寫(xiě)設備,當數據還未完全寫(xiě)入數據庫時(shí)若有新數據發(fā)過(guò)來(lái),則下次讀寫(xiě)將會(huì )發(fā)生難以估計的錯誤。實(shí)驗還得出了當把數據庫文件寫(xiě)入到系統Flash上的總耗時(shí)約為50 ms,比寫(xiě)入SD卡中約少30 ms。不過(guò)就80 ms左右的一次讀寫(xiě)速度而言,嵌入式數據庫sqlite3執行效率和穩定性非??捎^(guān),現在一般的RFID讀寫(xiě)器通過(guò)串口執行一條指令的時(shí)間也需幾十毫秒的時(shí)間,因而使用sqlite3數據庫在執行速率和穩定性上對于安檢系統中RFID讀寫(xiě)數據的處理可以很好地達到要求,而且sqlite3還支持數據加密,安全性同樣非常出色。
評論