Thông tin cơ bản về RFID RC522 và PN532: 10 bước

2024 Tác giả: John Day | [email protected]. Sửa đổi lần cuối: 2024-01-30 13:33

LƯU Ý: Bây giờ tôi có các Tài liệu hướng dẫn cung cấp mã Arduino cho RC522 và PN532.

Cách đây một thời gian, tôi đã mua ba mô-đun RFID khác nhau để thử nghiệm. Trong một dự án trước, tôi đã trình bày chi tiết cách sử dụng mô-đun 125 kHz đơn giản để thực hiện một chức năng bảo mật cơ bản. Các mô-đun như vậy sử dụng thẻ chỉ đọc để quy trình quét ID, lưu trữ nếu muốn và so sánh với ID được lưu trữ. Các mô-đun khác mà tôi đã mua hoạt động ở 13,56 MHz và sử dụng các thẻ có thể đọc và ghi, vì vậy thật lãng phí nếu chỉ sử dụng chúng cho mục đích bảo mật cơ bản. Hai mô-đun chung sử dụng chip RC522 hoặc chip PN532 - cả hai đều do NXP sản xuất.

Nếu bạn đã đọc bất kỳ dự án nào khác của tôi, bạn sẽ biết rằng tôi thích sử dụng bộ vi điều khiển PIC giá rẻ và lập trình bằng hợp ngữ. Vì vậy, những gì tôi đang tìm kiếm là một chuỗi các bước cần thiết để nói chuyện với các mô-đun và với các thẻ RFID. Trong khi có rất nhiều chương trình ví dụ trực tuyến cho các mô-đun, hầu hết chúng được viết bằng phần mềm ‘C’ cho Arduino và sử dụng giao diện SPI. Ngoài ra, hướng dẫn sử dụng cho chip và thẻ Mifare cũng cần một chút giải mã. Bài đăng này chủ yếu nói về thông tin tôi ước tôi có khi bắt đầu dự án. Tôi cũng bao gồm các chương trình phần mềm lắp ráp PIC để thực hiện các lệnh cơ bản theo yêu cầu của mỗi mô-đun. Ngay cả khi bạn không sử dụng PIC và / hoặc hợp ngữ, mã nguồn ít nhất phải cung cấp cho bạn ý tưởng tốt về các lệnh cụ thể cần thiết để thực hiện từng bước.

Bước 1: Giao diện nối tiếp

Cả hai chip được sử dụng trên các mô-đun này đều có khả năng giao tiếp thông qua SPI, I2C hoặc UART (HSSP). Mô-đun PN532 có một công tắc DIP được sử dụng để chọn giao diện mong muốn nhưng mô-đun MFRC522 được kết nối với giao diện SPI. Tôi thích sử dụng UART tích hợp sẵn của PIC, vì vậy tôi đã tìm kiếm trên mạng để xem có cách nào để đưa mô-đun MFRC522 vào chế độ UART không. Những gì tôi tìm thấy là cắt một dấu vết trên bảng sẽ thành công. Việc cắt có hiệu quả loại bỏ 3,3 volt khỏi chân EA của chip. Về mặt kỹ thuật, chân EA sau đó sẽ được kết nối với đất nhưng không nhiều người có thể thực hiện công việc hàn đó do mật độ chân chip. Tuy nhiên, đừng lo lắng, vì chân EA không có thanh kéo bên trong và không "nổi" như các đầu vào logic TTL cũ. Tham khảo sơ đồ chip và hình ảnh phần bo mạch để biết vị trí cần cắt. Đảm bảo rằng bạn chỉ cắt đoạn ngắn đi trực tiếp đến chân EA.

Bước 2: Phần cứng

Các kết nối phần cứng cho giao tiếp UART được hiển thị trong sơ đồ trên. Các kết nối UART cho MFRC522 không được đánh dấu trên bảng nhưng, như được hiển thị trong sơ đồ, chân SDA nhận dữ liệu UART và chân MISO truyền dữ liệu UART. Mô-đun PN532 có các ký hiệu UART ở phía dưới cùng của bảng.

Cả hai mô-đun đều chạy trên 3,3 volt và mức logic 5 volt từ chân PIC TX cũng cần được giới hạn. Kết nối LCD là thiết lập 4-bit tiêu chuẩn đã được sử dụng trong một số dự án trước đây của tôi. Định dạng mặc định cho tất cả các tin nhắn được đặt cho màn hình LCD 1602 tiêu chuẩn (16 ký tự x 2 dòng). Tôi cũng có một màn hình LCD 40 ký tự x 2 dòng mà tôi sử dụng để kết xuất dữ liệu thô trong quá trình gỡ lỗi, vì vậy tôi đã bao gồm một định nghĩa trong phần mềm cho phép tôi tận dụng không gian hiển thị bổ sung.

Bước 3: Khối dữ liệu

Các thẻ Mifare Classic 1k được sử dụng cho dự án này được định cấu hình là 16 cung, bốn khối dữ liệu cho mỗi khu vực, 16 byte cho mỗi khối dữ liệu. Trong số 64 khối dữ liệu, chỉ có 47 khối thực sự có thể sử dụng được. Khối dữ liệu 0 chứa dữ liệu nhà sản xuất và các khối 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 và 63 được gọi là khối Trailer. Các khối Trailer là khối cuối cùng trong mỗi sector và chúng chứa hai khóa và các bit truy cập khối. Các khóa và bit truy cập khối chỉ áp dụng cho các khối dữ liệu trong khu vực đó, do đó bạn có thể có các khóa và quy tắc truy cập khác nhau cho mỗi khu vực. Các khóa mặc định được đặt thành “FF FF FF FF FFh”. Đối với dự án cơ bản này, tôi chỉ sử dụng một khối dữ liệu và giữ các khóa và bit truy cập mặc định. Có rất nhiều tài liệu liên quan đến các thẻ này vì vậy chỉ cần thực hiện tìm kiếm trực tuyến cho “Mifare” hoặc truy cập trang web NXP nếu bạn muốn khám phá chúng chuyên sâu hơn.

Bước 4: Hoạt động chung

Mặc dù cả hai mô-đun là duy nhất về cách chúng được truy cập và cách chúng truy cập vào các thẻ, nhưng có một quy trình chung được yêu cầu để hoàn thành công việc. Đối với dự án này, chúng tôi giả định rằng các thẻ là loại Mifare Classic 1k và chúng tôi chỉ cho phép một thẻ tại một thời điểm trong trường ăng-ten. Các bước cơ bản được xác định dưới đây.

· Khởi tạo mô-đun: Nói chung, điều này đòi hỏi những thứ như ghi giá trị vào các thanh ghi trong chip, gửi lệnh “đánh thức” và bật nguồn cho ăng-ten. Trong một ứng dụng hoạt động bằng pin, bạn sẽ muốn có thể bật và tắt nguồn ăng-ten để tiết kiệm pin nhưng đối với ứng dụng đơn giản này, chúng tôi bật nó một lần rồi để nguyên.

· Xóa cờ tiền điện tử (chỉ 522): Khi một thẻ được xác thực, một cờ sẽ được thiết lập để cho người dùng biết rằng các giao tiếp với thẻ sẽ được mã hóa. Người dùng cần xóa cờ này trước khi quét tiếp theo, ngay cả khi thẻ đang được quét là cùng một thẻ.

· Quét thẻ: Về cơ bản, mô-đun hỏi "Có ai ở ngoài đó không?" và thẻ phản hồi "Tôi ở đây". Nếu mô-đun không nhận được phản hồi nhanh, nó sẽ ngừng lắng nghe. Điều đó có nghĩa là chúng ta cần liên tục gửi các lệnh quét tới mô-đun cho đến khi nó tìm thấy thẻ.

· Lấy thẻ Số nhận dạng người dùng (UID): Thẻ sẽ phản hồi yêu cầu quét với một số thông tin hạn chế như loại thẻ. Điều đó có nghĩa là chúng ta có thể cần gửi một lệnh khác để lấy UID của nó. UID là bốn byte cho các thẻ Mifare Classic 1k. Nếu có thể lâu hơn cho các thẻ khác nhưng dự án này không giải quyết chúng.

· Chọn thẻ (chỉ 522): UID được sử dụng để chọn thẻ mà người dùng muốn xác thực để đọc và ghi. Điều này dựa trên khả năng có thể có nhiều hơn một thẻ trong trường ăng-ten. Đó không phải là trường hợp của ứng dụng đơn giản của chúng tôi nhưng dù sao chúng tôi cũng cần chọn thẻ.

· Xác thực thẻ: Bước này là bắt buộc nếu chúng ta muốn đọc hoặc ghi thẻ. Nếu tất cả những gì chúng ta muốn làm là phân biệt giữa các thẻ cho một ứng dụng bảo mật đơn giản thì UID là đủ. Việc xác thực yêu cầu chúng tôi biết UID và chúng tôi biết khóa mật mã cho lĩnh vực dữ liệu của thẻ mà chúng tôi muốn truy cập. Đối với dự án này, chúng tôi gắn bó với các khóa mặc định nhưng dự án tiếp theo của tôi thay đổi các khóa để thẻ có thể được sử dụng như một ví điện tử.

· Đọc hoặc ghi thẻ: Đọc luôn trả về tất cả 16 byte của Khối dữ liệu được yêu cầu. Việc ghi yêu cầu rằng tất cả 16 byte được viết cùng một lúc. Nếu bạn muốn đọc hoặc ghi một khối khác trong cùng khu vực dữ liệu, thẻ không cần phải xác thực lại. Nếu bạn muốn đọc hoặc ghi một khối trong một lĩnh vực dữ liệu khác thì thẻ cần được xác thực lại bằng cách sử dụng khóa cho lĩnh vực đó.

Bước 5: Trình tự truy cập mô-đun MFRC522

Quy trình khởi động bao gồm các bước cơ bản được tìm thấy trong hầu hết các ứng dụng mà tôi đã xem xét:

· Gửi byte dữ liệu giả (xem đoạn tiếp theo)

· Đặt lại mềm

· Đặt độ lợi của máy thu RF (nếu mong muốn thứ gì đó khác với mặc định)

· Đặt tỷ lệ phần trăm điều chế ASK thành 100%

· Đặt giá trị gốc cho các tính toán CRC

· Bật ăng-ten

· Nhận phiên bản phần sụn (không bắt buộc)

Vì một số lý do không giải thích được, mô-đun của tôi bật nguồn và nghĩ rằng nó đã nhận được lệnh ghi mà không có byte dữ liệu. Tôi không biết đây có phải chỉ là sự cố với mô-đun của mình hay không nhưng tôi chưa thấy bất kỳ tham chiếu nào đến nó ở nơi khác. Tôi đã thử nghiệm đặt lại cả phần cứng và phần mềm và không khắc phục được sự cố. Giải pháp của tôi là thêm một lệnh gọi đọc giả để đăng ký “0” (không xác định) khi bắt đầu quy trình khởi tạo mô-đun. Nếu mô-đun coi đây là dữ liệu cho lệnh ghi không xác định thì có vẻ như không có bất kỳ tác động xấu nào. Nếu nó coi nó như một lệnh đọc, thì không có gì hữu ích xảy ra. Tôi thấy phiền rằng tôi không thể xác định đầy đủ vấn đề, đặc biệt là khi chỉ thiết lập lại phần cứng của mô-đun không khắc phục được sự cố.

Chip RC522 bao gồm một số thanh ghi, hầu hết trong số đó là cả hai chức năng đọc và ghi. Để thực hiện ghi, số thanh ghi được gửi đến mô-đun theo sau là giá trị để ghi. Để thực hiện đọc, số đăng ký có 0x80 được thêm vào và được gửi đến mô-đun. Phản hồi cho một lệnh ghi là một tiếng vọng lại của thanh ghi được truy cập. Phản hồi cho một lệnh đọc là nội dung của thanh ghi. Phần mềm tận dụng kiến thức đó để xác minh rằng lệnh đã được thực thi đúng.

Bước 6: Trình tự truy cập mô-đun PN532

Quy trình khởi động bao gồm các bước bắt buộc sau:

· Gửi một chuỗi khởi tạo: Điều này dành riêng cho giao diện UART. Hướng dẫn sử dụng nói rằng giao diện UART sẽ đánh thức trên cạnh lên thứ năm được phát hiện trên giao diện. Nó khuyến nghị gửi 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. Đối với hầu hết các phần, chỉ cần có đủ số lượng ký tự có các cạnh tăng lên và chúng không được giống như một phần mở đầu lệnh (00 00 FF).

· Đánh thức mô-đun: Được ghi trong sách hướng dẫn sử dụng, nó cho thấy rằng mô-đun khởi tạo vào một loại trạng thái ngủ được gọi là “LowVbat”. Để thoát khỏi trạng thái này, chúng ta cần gửi lệnh “SAMConfiguration”.

PN532 mong đợi các lệnh được gửi ở định dạng tin nhắn xác định bao gồm lời mở đầu, tin nhắn và hậu đề. Các tin nhắn phản hồi theo cùng một định dạng. Cả hai thông báo lệnh và phản hồi đều bao gồm TFI (Định danh khung) và một phiên bản lệnh. Lệnh sử dụng TFI là 0xD4 và phản hồi sử dụng 0xD5. Các phiên bản lệnh khác nhau nhưng phản hồi sẽ luôn tăng phiên bản lệnh và trả lại nó trong byte theo sau TFI. Tính nhất quán đó cho phép dễ dàng quét các thông báo phản hồi để tìm thông tin liên quan.

Mỗi thông điệp lệnh (theo sau phần mở đầu) bao gồm độ dài thông báo, phần bù của 2 độ dài thông báo, TFI, lệnh, dữ liệu, tổng kiểm tra và dấu nối sau. Phần mềm xây dựng các lệnh riêng lẻ và sau đó gọi một quy trình tính toán tổng kiểm tra và thêm dấu vết vào.

Định dạng thông báo cho phản hồi tương tự như định dạng của lệnh. Một phản hồi điển hình sẽ bao gồm một ACK (00 00 FF 00 FF 00) theo sau là phản hồi cụ thể cho lệnh. Mỗi phản hồi lệnh bắt đầu bằng phần mở đầu là 00 00 FF. Phản hồi cũng phải có một byte TFI là D5 theo sau là số lệnh tăng lên 1. Đối với lệnh “SAMConfiguration” (14) của chúng tôi sẽ là 15. Lệnh “SAMConfiguration” nhận được phản hồi này: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Có thể gửi các lệnh dành riêng cho mô-đun khác nhưng chúng không cần thiết cho ứng dụng này. Tuy nhiên, tôi đã bao gồm một quy trình có thể được gọi để lấy số phiên bản phần sụn. Một phản hồi điển hình (sau ACK và phần mở đầu) sẽ là: 06 FA D5 03 32 01 06 07 E8 00. “01 06 07” cho biết số phiên bản phần sụn 1.6.7.

Bước 7: Trình tự truy cập thẻ

Sau khi mô-đun đã sẵn sàng, chúng tôi có thể gửi các lệnh cụ thể cho các thẻ. Để đọc hoặc ghi dữ liệu thẻ, chúng ta cần có số nhận dạng (UID) của nó. Sau đó, UID và khóa sẽ được sử dụng để cấp phép cho một khu vực dữ liệu thẻ cụ thể để đọc / ghi. Việc đọc / ghi dữ liệu thẻ luôn được thực hiện trên tất cả 16 byte trong một khối dữ liệu được chỉ định. Điều đó có nghĩa là ứng dụng điển hình sẽ đọc khối dữ liệu, sửa đổi dữ liệu như mong muốn và sau đó ghi dữ liệu mới trở lại thẻ.

Bước 8: Phần mềm

Phần mềm xử lý ngắt được gọi bất cứ khi nào PIC UART nhận được một byte dữ liệu. Trong một số dự án UART trước đây của tôi, tôi có thể chỉ thăm dò cờ ngắt RX thay vì phải sử dụng trình xử lý ngắt. Đó không phải là trường hợp của phần mềm này, đặc biệt là đối với PN532 giao tiếp ở tốc độ truyền cao hơn nhiều so với RC522. Giao diện UART của RC522 được giới hạn ở 9600 baud trong khi mặc định cho PN532 là 115k và có thể được đặt cao tới 1,288M baud. Các byte nhận được được lưu trữ trong một vùng đệm và phần chính của phần mềm sẽ truy xuất chúng khi cần thiết.

Cờ New_Msg chỉ ra rằng các byte đã được nhận và Byte_Count cho biết có bao nhiêu. Tôi đã bao gồm quy trình “Disp_Buff” trong phần mềm có thể được gọi để hiển thị nội dung của bộ đệm nhận trong quá trình gỡ lỗi. Một số thông báo trả về sẽ tràn ra màn hình 1602 điển hình nhưng tôi có một màn hình LCD 40 ký tự x 2 dòng mà tôi tìm thấy tại một trang web điện tử dư thừa trực tuyến. Định nghĩa “Max_Line” có thể được đặt cho kích thước màn hình LCD của bạn. Nếu đạt đến “Max_Line”, quy trình “Disp_Buff” sẽ tiếp tục bằng cách ghi vào dòng thứ hai. Bạn có thể thêm một đoạn mã nhỏ vào quy trình đó để tiếp tục đến dòng ba và dòng bốn nếu bạn có màn hình LCD 4 dòng. Đối với PN532, có một cờ có thể được đặt để quy trình loại bỏ tất cả các byte nhận được hoặc chỉ loại bỏ 16 byte dữ liệu từ một phản hồi đọc.

Không cần xóa bộ đệm nhận hoặc Byte_Count vì xóa cờ New_Msg sẽ khiến trình xử lý ngắt xóa Byte_Count và đó là thứ được sử dụng làm chỉ mục trong bộ đệm. New_Msg thường được xóa trước mỗi bước lệnh để các kết quả cụ thể cho lệnh đó có thể được định vị và xác minh dễ dàng. Trong RC522, điều đó có nghĩa là bộ đệm nhận thường chỉ có 1 đến 4 byte. Trong một số trường hợp, chẳng hạn như đọc khối dữ liệu, lệnh Read_FIFO phải được phát hành nhiều lần để di chuyển các byte từ FIFO vào bộ đệm nhận. Tất cả các kết quả lệnh cho PN532 kết thúc trong bộ đệm nhận, do đó, một quy trình quét được thực hiện để xác định các byte cụ thể cần thiết.

Vòng lặp chính trong phần mềm quét thẻ và sau đó xác thực thẻ để đọc / ghi. Đối với phần mềm kiểm tra được bao gồm ở đây, biến Junk_Num được sửa đổi mỗi lần thông qua vòng lặp chính và được sử dụng trong quá trình ghi vào thẻ. Các giá trị được viết xen kẽ giữa giá trị của Junk_Num và phần bổ sung 1 của Junk_Num. Cuối cùng, 16 giá trị đã viết được đọc và hiển thị. Có thông báo hiển thị cho mỗi bước với các cuộc gọi định kỳ trì hoãn để có thời gian đọc từng tin nhắn. Thông báo lỗi cũng được cung cấp nhưng thông thường chỉ xảy ra nếu thẻ bị xóa trong một hoạt động.

Một phần của quá trình khởi tạo phần mềm là một phần mã chỉ được thực thi khi bật nguồn và bị bỏ qua nếu phát hiện thấy thiết lập lại phần mềm. Thông báo lỗi thường kết thúc bằng cách đặt lại phần mềm như một cách để thoát khỏi vòng lặp chính. Việc đặt lại xảy ra trong quy trình “Tilt” chỉ đơn giản là bật Bộ hẹn giờ cho Cơ quan giám sát và sau đó đi vào một vòng lặp vô hạn chờ hết thời gian.

Bước 9: Phần mềm độc đáo MFRC522

Chip RC522 yêu cầu nhiều lệnh cấp thấp hơn chip PN532 để thực hiện giao tiếp với các thẻ. Nó giống như lập trình bằng hợp ngữ so với lập trình bằng “C”. Một sự khác biệt đáng kể khác là RC522 yêu cầu giao tiếp với thẻ được truyền thông qua bộ đệm FIFO. Các quy trình “Write_FIFO” và “Read_FIFO” xử lý các tác vụ đó. Phần mềm MFRC522 bao gồm một phần cho nhiều lệnh cấp thấp hơn mà từ đó các chức năng chính được xây dựng.

Phép tính tổng kiểm tra lệnh thẻ cho RC522 rất khác so với PN532. Sau khi lệnh thẻ được tích hợp trong FIFO, một lệnh mô-đun sẽ được gửi để tính toán tổng kiểm tra. Kết quả 16 bit không tự động được thêm vào lệnh thẻ nhưng có sẵn để đọc từ hai thanh ghi 8 bit. Phép tính tổng kiểm tra xóa dữ liệu trong FIFO nên trình tự bắt buộc như sau:

· Xây dựng lệnh trong FIFO

· Lệnh tính toán tổng kiểm tra

· Xây dựng lại lệnh trong FIFO

· Đọc các thanh ghi CRC và ghi các byte tổng kiểm tra vào FIFO

· Gửi lệnh Truyền hoặc Xác thực

Lệnh Transceive sẽ truyền bộ đệm FIFO sau đó tự động chuyển sang chế độ nhận để chờ phản hồi từ thẻ. Lệnh Transceive phải được thực hiện theo sau khi cài đặt bit StartSend trong BitFramingRegister để thực sự truyền dữ liệu. Lệnh Authenticate không có yêu cầu đó.

Nói chung, các ứng dụng mã Arduino “C” có sẵn trực tuyến sử dụng thanh ghi cờ ngắt và thanh ghi thời gian chờ để đảm bảo rằng phản hồi chính xác được nhận một cách kịp thời. Theo ý kiến của tôi, điều đó là quá mức cần thiết cho ứng dụng quan trọng không theo thời gian này. Thay vào đó, tôi sử dụng thời gian chờ phần mềm ngắn để chờ phản hồi và sau đó xác minh rằng điều đó là chính xác. Hướng dẫn sử dụng cho các thẻ Mifare nêu chi tiết thời gian cho các giao dịch khác nhau và thời gian cũng được phép nhận được số byte dự kiến. Những độ trễ thời gian này được tích hợp trong hầu hết các chương trình con lệnh cấp thấp.

Bước 10: Phần mềm độc đáo PN532

Sau khi mô-đun được khởi tạo, các bước cần thiết để tìm và xác thực thẻ được thực hiện bằng cách viết lệnh thích hợp theo sau là dữ liệu cần thiết. Lệnh quét trả về UID sau đó được sử dụng để xác thực. Sau đó, đọc và ghi thẻ gửi hoặc trả về 16 byte cho khối dữ liệu được định địa chỉ.

Trình tự khởi tạo đã được trình bày chi tiết trước đó và quy trình phần mềm tương tự cũng gửi lệnh SAMConfiguration để đưa mô-đun thoát khỏi trạng thái “LowVbat”. Phần còn lại của các lệnh cơ bản, chẳng hạn như Quét, Xác thực, Thẻ Đọc / Ghi, chỉ được xây dựng tuần tự trong các quy trình áp dụng. Tổng kiểm tra được tính bằng cách chỉ cộng các byte lệnh, thực hiện phép bổ sung, sau đó thêm 1 để biến nó thành phần bù của 2. Kết quả 8 bit được nối vào chuỗi lệnh ngay trước dấu nối sau.

Không có FIFO như trong RC522 nên các thông báo phản hồi hoàn chỉnh sẽ được tự động nhận. Quy trình “Find_Response” quét bộ đệm dữ liệu nhận cho TFI (0xD5). Quy trình này tận dụng lợi thế của việc biết thông báo mong đợi phải là gì và bỏ qua các phản hồi ACK đơn giản không bao gồm dữ liệu. Sau khi tìm thấy TFI, các phản hồi mong muốn là một điểm bù đã biết từ nó. Các byte lặp lại lệnh và byte trạng thái lệnh được lưu lại bởi quy trình “Read_Buff” để xác minh sau.

Đó là nó cho bài đăng này. Kiểm tra các dự án điện tử khác của tôi tại: www.boomerrules.wordpress.com