The Program
I'm making something simple that will check the reader ID, card type and Card ID.
You put a card on the reader. Execute the program, and get info:
I have a set of different card types, from somewhat smart to extremely savvy. The reader will recognise them.
#include <iostream> #include "uFCoder.h" int main() { UFR_STATUS status; uint32_t readerType = 0; uint8_t cardType = 0; uint32_t cardSerial = 0; status = ReaderOpen(); status = GetReaderType(&readerType); status = GetCardId(&cardType, &cardSerial); status = ReaderClose(); std::cout << std::hex << "Reader type: 0x" << readerType << " cardtype: 0x" << (unsigned)cardType << ", serial id: 0x" << cardSerial << std::endl; return 0; }
Simple on purpose. But it shows you can talk to reader and card.
Prerequisites
Library
To talk to the reader, you use the Digital Logic library and API.
The library is proprietary and closed source. There's a pre-built lib or DLL available for the popular architectures and operating systems.
My target platform belongs to the Raspberry Pi family. It's running Debian Stretch.
The most recent D-Logic library that supports Stretch is version 5.0.18. Later versions require a GLIB version that's more recent than the one for Stretch.
Download the library package to your development environment and unzip it.
In the Eclipse IDE, you'll need the header and library. More on that later.
On the target platform, you only need the library.
I used WinSCP to move the library:
I leave it to you where you want to put the library.
On Debian, it should be available in /usr/lib.
I prefer to not put files in that folder manually. I put the library somewhere in my home structure, and create a symbolic link in /usr/lib.
sudo ln -s /home/avnet/ufr/bin/libuFCoder-armhf.so /usr/lib/libuFCoder-armhf.so
I have no strong opinion on this. It's how I prefer to work with development projects where I want to leave the OS as undisturbed as I can.
Digital Logic is working on a driver for the industry standard PcSc protocol. I'm excited about that, because it means you can plug-and-play it into BlockChain clients. A Windows driver is announced a few months ago. The download page is empty at the moment. I contacted D-Logic to ask when it 'll be available. |
Disable FTDI kernel modules
The µFR Nano has an FTDI USB ic. When you plug it in, this automatically loads 2 kernel modules in Linux.
To make the D-Logic lib work, you need to disable them.
Check if you have this situation by executing:
lsmod | grep ftd
If this returns ftdi_sio and usbserial, you need disable them.
There are 2 ways of doing this:
Temporary, for development:
sudo rmmod ftdi_sio usbserial
Permanently, by blacklisting them. D-Logic provides a shel lscript for that:
wget https://www.d-logic.net/code/nfc-rfid-reader-sdk/ufr-linux-usb_permission_script/raw/master/uFCoder1x.sh chmod +x *.sh sudo ./uFCoder1x.sh
Set Up the Eclipse IDE for Cross-platform Development
I've blogged about setting up a Linux-ARM development and debug environment on a Windows machine before.
Ping if you want a pointer to the instructions. In this post, I'm starting from a working cross-development setup.
Dependencies
In Eclipse, you'll need to tell the toolchain where to find the header and the library.
They are both part of the *.zip you downloaded in the previous section.
To make the project work on different computers, I use an environment variable to point to the D-Logic library distribution's root.
on my Windows 10 laptop:
Name D_LOGIC_LIB
Value: D:\users\jancu\Documents\elektronica\d-logic\ufr-lib-5.0.18
The project will need to know where the header file resides:
... and where the pre-compiled library can be found:
"Hey Jan, I don't need no environment variables for that."
True. But I've prepared my project in a way that it's easy to change between library versions, architectures and operating systems.
The target (Raspberry Linux, Siemens IoT2XXXX window, Intel Linux, Windows PC, ...) and development machine are easily switched.
I can share the project to this post (I did), and the only thing you have to do is adapt environment settings based on your disk layout. ...
Debug Configuration
I'm developing on a Windows laptop. Bit compiling for a Raspberry Pi type of device.
The program will be automatically uploaded to the device, and a debug session is started:
Result (code compiled on Windows, Eclipse running on windows, but code executed on the target Linux device:
Real World Test
I have a set of RFID tags and cards.
Here's the result of running each of them with the program, clockwise, starting from The Infineon Security2Go card:
You can also put your smartphone on the reader and do the same exercise. It has an RFID too.
The Eclipse project is attached. You will need to adjust the D_LOGIC_LIB environment variable to match where you stored the library distribution.
There's also the early begin of a C++ wrapper in the Eclipse project. It's not used in the example, but I thought I'd leave this in the archive if you'd be interested.
Also check the toolchain. I'm using the GCC 10 cross-compile chain for ARM-Linux here. But any chain that can compile for your target will be fine.
If you run Eclipse on a Pi or BB, you can just use the native GCC.
If you want to develop a solution that works on Windows and Linux, check Build an application in Eclipse and GCC for Windows and Linux - supports external Libs, DLLs, Debug.
Good luck.
Related Blog |
---|
Blockchain - Talk Directly to the Infineon 2Go Smart Cards API |
NFC Card Reader Protocol of Digital Logic µFR - part 0: intent |
µFR NFC Card Reader - part 1: first C program for Linux (RPi, BB, ...) |
µFR NFC Card Reader - part 2: first C++ program |
µFR NFC Card Reader - part 3: C++ Class to handle ISO14443 / APDU cards |
µFR NFC Card Reader - part 4: first meaningful ISO14443 / APDU conversation |
µFR NFC Card Reader - part 5: refactor, look back at initial design |