Some more random ramblings from me. What’s been going on? I’ve been working on this job for a customer involving a ST7735 based TFT display. As for controlling this display, I went with ucglib, as it seemed suitable. It supports many types of displays, and it’s under a BSD license, so the license doesn’t pose any barriers for commercial use. Nevertheless… using the ucglib library, it turned out to be rather slow. I have solved this issue by creating a framebuffer, rendering the data in RAM, and sending it to the display. That’s blazing fast, oh my dear! However, it requires quite some RAM, which is scarce on a microcontroller.

Nevertheless… I’ve been taking this idea out of that project, and did some testing on my own to see what I can achieve using a framebuffer. And then I can be fast, and in that case, the compiler optimisation is very noticeable. It could double the frame rate. I’d say, this can turn into a whole new project. But I guess I’ll clean up the test code and publish some examples soon-ish. (Probably next month, during the Christmas vacation)

Some other toys, that have been catching dust for years. I’ve some RC522 and PN532 card readers laying around. Those are the two popular models being sold at eBay and AliExpress. Both are chips made by NXP. I’ll have to dig some deeper to see what the differences between those are. For one thing, they speak different protocols. I see two families around then. The RC522, which is actually called MFRC522, has two more variants, MFRC523. Looking at AN1445, the MFRC522 only supports ISO/IEC14443A, and the MFRC523 also supports ISO/IEC14443B, and the PN512, which adds FeliCa to the supported card types. FeliCa cards are ISO/IEC 18092. So I wonder if any generic ISO/IEC 18092 card would work.

Then we arrive at the PN532 card reader. This chip implements a different protocol, and has a PN512-legacy mode. Thus, this suggests this is a newer protocol to replace the older one. In addition to reading all the card types mentioned before, this chip also offers emulation of those cards, and NFCIP-1, which I believe is reader-to-reader communication. I’ll have to investigate further, but I’ll begin at reading cards.

Most drivers out there in the hobby scene only support the RC522 and the PN532, as those are the chips used on the chips sold by Chinese on eBay and AliExpress. It is the hardware available, and the only hardware I’ve laying around. I might dig through the datasheets and write some driver that supports them all, but that will be untested code. If I want one of the other chips, I’ll have to solder it to a board myself. Nobody is selling any of the other variants, and chips by other manufacturers are rare. I know ST makes RFID chips as well, but finding them on a board?

So… we have two protocols now, and I was thinking about creating two drivers, with some unified API, say, a Hardware Abstraction Layer.

Having said all of that, looking at NXP’s website, it seems both chips are “Not Recommended for new design”, and for the MFRC52x they recommend the CLRC663. For the PN532
they recommend PN7120 or PN7150. For the PN533 (with USB) they recommend PN7462. Curiously, for the PN512, I see no such message.

On first glance, the CLRC633 has yet another protocol, but all commands and registers are documented. For the PN71xx series… it’s a different story. Those implement a standard protocol, NCI, defined by the NFC Forum. ST also implements this protocol in some of its chips. Thus, at first glance, it looks like, one protocol to rule them all. Makes future development easier, one would say. But in order to implement a protocol, one needs specifications. Heading over to the NFC forum, it costs a whopping $ 600, I kid you not. If one has to pay $ 600 to be allowed to read the specification. Of course, the specifications are floating around somewhere on the interwebs, and the first paragraph says, if you don’t have a license, you are allowed to read, but not to implement. So… great, who is interested in a universal protocol if one has to pay big read the specs. Do you want your standard to be adopted or not? I’ll stick to a chip that documents its commands and registers in freely available datasheets and user manuals, thank you.