Ruby Gem : MFRC522

因緣際會下,有人來問我在Raspberry Pi上操作其他硬體的問題,剛好很久沒碰硬體就幫忙寫了lib,並包裝成套件

這個套件是Ruby Gem,名字叫做MFRC522,是設計在Raspberry Pi上面操作MFRC522晶片的lib

程式碼可以在github上找到:https://github.com/atitan/MFRC522_Ruby

專有名詞

在開始介紹細節之前先解釋一些常見的專有名詞

  • PICC(Proximity Integrated Circuit Card):非接觸積體電路卡片,就是RFID卡片
  • PCD(Proximity Coupling Device):非接觸耦合裝置,RFID讀卡機的意思

技術細節

MFRC522使用ISO 14443 type A作為基礎,這個標準分為4個層級的文件,1是硬體規格、2是無線電波能量和傳訊介面、3是初始化與衝突避免、4是傳輸協定

1和2都已經由MFRC522製造商實作完成,只需要處理3和4即可

首先介紹一下架構

MFRC522這個class負責處理與硬體模組之間的溝通,以及卡片標準的第三級(初始化與衝突避免)

再來介紹卡片生命週期的一些細節

卡片在進入感應區後通電,會進行power-on reset,並進入idle state

首先透過REQA或WUPA指令將卡片轉成ready state,這兩個指令的差別在WUPA可以將卡片從halt state喚醒,而REQA不行

在ready state下,進行卡片UID的詢問,卡片收到請求會回傳UID

若這個時候有多張卡片在感應區內,PCD會收到不齊全的UID,這不要緊,繼續將收到一半的UID放進請求裡然後再送一遍

感應區內的卡片都會收到這個請求,而UID開頭與我們送出資料相符的那張卡片會繼續回復剩下的UID,重複這兩個步驟就能得到完整的UID

有了完整的UID後,還要再進行一次請求並附上完整的UID,與UID完全符合的那張卡片會進行確認的回應

此時檢查是否還有下一層UID(有1~3層),若有就要重複上面的步驟去取得剩下的UID

進行初始化與衝突避免之後,卡片會進入active state,此時就可以跟卡片進行通訊

Mifare Classic和Ultralight使用Mifare私有協定進行傳輸,因此只需建構在第三級標準上即可

而Mifare DESFire或Plus SL3在衝突避免後會辨識為ISO標準卡片,必須實作第四級的傳輸協定才能溝通

在OSI模型下,ISO第三級算是硬體層,而第四級是資料鏈結層

Mifare私有協定與ISO傳輸協定最大的差別在錯誤處理,Mifare協定會丟個NAK回來並將卡片重設成idle state。而ISO協定因為僅處理傳輸上的錯誤,因此卡片必須透過資料傳輸在軟體層做錯誤訊息回報

在傳輸逾時的部份,Mifare協定在卡片datasheet中定義各種操作所需的時間長度。ISO協定則是在傳輸前會進行交涉,卡片會表明他預設的時間為多少。要是在某些操作中發生時間不夠用的狀況,卡片可以透過特殊的訊框向PCD請求延長時限

此外,ISO協定還支援資料切割,當傳輸的資料超過任一方的buffer size而無法一次接收時,可以將資料切割後傳輸。若有資料遺失的情形,也可透過NAK的方式要求對方重傳。

在操作結束之後,可利用HLTA指令讓卡片進入halt state,此時卡片只會對WUPA指令有反應,收到後會進入ready state

留言

粗體斜體刪除線連結引用圖片程式碼

注意:您的電子信箱將不會被公開,且網站連結不會被搜尋引擎採計

{124} {123} {122} {121} {120} {119} {118} {117} {116} {115} {114} {113} {112} {111} {100} {025} {024} {023} {022} {021} {020} {019} {018} {017} {016} {015} {014} {013} {012} {011} {010} {009} {008} {007} {006} {005} {004} {003} {002} {001}