keever50 opened a new issue, #16036: URL: https://github.com/apache/nuttx/issues/16036
### Is your feature request related to a problem? Please describe. Currently NuttX has no common API for NFC/RFID cards and contactless readers _(from now on referred as contactless)._ As result contactless drivers are not portable and hard to maintain and understand. Also the absence of documentation further complicates development. Additionally, the PN532 driver is undocumented and in a broken state. Attempts to repair and extend its functionality have been challenging due to its current condition. ### Describe the solution you'd like To address these issues, I have been developing a common API for contactless devices, along with a new PN532 driver that adheres to this API. The API definition can be found here: [NuttX Contactless IOCTL API](https://github.com/keever50/nuttx/blob/pn532_fixup/include/nuttx/contactless/ioctl.h) A flow diagram illustrating the design is shown below:  (Type A and Type B refers to two examples of card standards. Mifare type A and Mifare type B) ** --- Future --- ** This API does not contain all features for contactless. Currently it only supports passive reading of UIDs, which is the bare minimum nearly all card readers support. In the future features can be added to add a standard write() and read() implementation, for example to read and write card contents. Also commands can be added to allow different scan modes, such as communication between NFC scanners and card emulation. ** --- Usage example --- ** This is a test application using the API features that follows the flow diagram above. https://pastebin.com/sXzwUALk ** --- PN532 --- ** The PN532 driver has been completely rewritten (with future expansion in mind), as discussed in [Issue #15942](https://github.com/apache/nuttx/issues/15942). However, this driver will be submitted in a separate PR after the new API is merged. As part of this transition, all legacy PN532 IOCTL commands will be removed. Maintaining backward compatibility would require significant effort, and given the state of the old driver, it is unlikely to have many active users. Feedback and suggestions are highly welcome. ### Describe alternatives you've considered The alternative is to not create a common API and have individual drivers that are not portable. But regarding the way this common API is written is hopefully discussed in this issue. ### Verification - [x] I have verified before submitting the report. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
