• rconty
  • Administrator
  • Offline
  • Registered: 2009-04-22
  • Posts: 673

Topic: Request for upcomming libnfc (1.3.0) code review

Hello,
As you may know, we are working on a new release version which massively change libnfc's API.

We have now reach a step where we can use it instead the previous version.
There are a lot of changes where main are: (see SVN log to have a full change log)

Fixes:
- build: Add workarounds for libusb in c99;
- build: Attempt to fix rpath issue on linux platform (it is already deprecated in main distributions. i.e. http://wiki.debian.org/RpathIssue)
- build: wrong paths in pkg-config file.
- libnfc: Remove warnings when compiling;
- libnfc: Various code fixes and cleanup;
- bus uart: Added support for recv/send of larger data chunks (>default_os_buffer);
- bus uart: Fix some some buffer synchronization problems under POSIX system;
- bus uart: Add configure option: --disable-serial-autoprobe to disable autoprobing.
- libnfc: Fix nfc_target_init doesn't correctly reset the parity during initalization;
- libnfc: added support for WUPA and 7,10 byte UID in nfc_initiator_select_tag();
- libnfc: Fix tag re-selection with UID lenght > 4 bytes (like DESFire or Ultralight);
- nfc-mfclassic: Fix authenticated only with KEYA;

Improvments:
- build: Build on recent FreeBSD (ie. upcoming FreeBSD 8.0; FreeBSD CURRENT);
- build: Add alternative build system (CMake).
- build: Add new files usefull for desktop GNU/Linux users: some rules for udev to allow non-root access to PN53x USB devices;
- build: Update msinttypes up to revision 26. (used when compiling under Windows);
- build: Add "make html" directive: it will build API documentation using Doxygen. (--enable-doc flag is required at configure time);
- libnfc: Add C++ compatibility;
- libnfc: Add driver agnostic nfc_pick_device(), nfc_list_devices();
- libnfc: It is now possible to specify a wanted device using new struct "nfc_device_desc_t".
- libnfc: Add device name to device descriptions (nfc_device_desc_t) to select a given PCSC device;
- libnfc: Finally removed all dirty globals, it 'should' be thread-safe now
- libnfc: Less confusing message for bitstreams display;
- libnfc: chips level introduction with pn53x.h/c;
- drivers: Add PN532 UART driver;
- driver acr122: add acr122_pick_device(), acr122_list_devices();
- drivers pn533_usb and pn531_usb: Lets search continuing to find other USB readers if any in PN531 and PN533 USB drivers;
- drivers pn533_usb and pn531_usb: Support for the generic vendorid/productid of the NXP chip;
- examples: Add MIFARE Ultratag tool. (Many thanks to xxv)
- examples: Add man page for nfc-mfultool;
- examples: MIFARE examples (mftool and mfultool) have now a better help message;
- examples: Add NFCIP (NDEP) as experimental feature (Thanks to Fkooman).
- examples: add quiet mode to improve timing of emulate, relay and anticol commands
- nfc-list: List all devices in nfc-list(1);
- nfc-list: Simply turns off the RF field upon exit;
- nfc-emulate: allow UID to be specified
- nfc-relay: Initialize initiator device explicitly;
- nfc-relay: Capture ctrl-c for quitting cleanly the relay attack application;
- nfc-relay: exit properly if emulator initialization failed;
- nfc-mfclassic: Add default keys tries;

Changes:
- API: Rename tag_info to nfc_target_info_t;
- API: Rename init_modulation to nfc_modulation_t;
- API: Rename dev_config_option to nfc_device_option_t;
- API: Use NULL instead of INVALID_DEVICE_INFO to know if device is valid;
- API: Rename chip_type to nfc_chip_t;
- API: Rename dev_spec to nfc_device_spec_t;
- API: Rename dev_info struct to nfc_device_t;
- Files: Remove defines.h public header;
- Files: Prefix messages.h and types.h headers by "nfc-";
- Files: Rename pn531.h/c to pn531_usb.h/c;
- Files: Rename pn533.h/c to pn533_usb.h/c;
- Files: Move examples into src/examples subdirectory;
- Examples: Rename nfc-mftool to nfc-mfclassic;
- Examples: Rename nfc-mfultool to nfc-mfultralight;
- API: Many variables name have been changed to match with coding convention;
- API: Changed length parmeters from uint32_t to size_t;

Before releasing, we need some developers to test it and find the news bugs we introduce.

Feel free to report issues, bugs or advices at our development site: http://code.google.com/p/libnfc/issues/list

Romuald Conty
  • zuck
  • Member
  • Offline
  • Registered: 2009-08-14
  • Posts: 47

Re: Request for upcomming libnfc (1.3.0) code review

In my opinion, as I've already said in the issue discussion, "nfc_device_xxx" is ambiguos.

A better solution could be "nfc_adaptor_xxx".

  • rconty
  • Administrator
  • Offline
  • Registered: 2009-04-22
  • Posts: 673

Re: Request for upcomming libnfc (1.3.0) code review

Hi Zuck,

zuck wrote:

In my opinion, as I've already said in the issue discussion, "nfc_device_xxx" is ambiguos.

You're totally right "device" is a generic term and can be ambiguous but "NFC device" is the generally adopted expression : from manufacturers to wikipedia, NFC device always point to the reader/active target/initiator.

zuck wrote:

A better solution could be "nfc_adaptor_xxx".

From wikipedia: adaptor "is a device whose purpose is to convert attributes of one device or system to those of an otherwise incompatible device or system."
That seems to not fit to our needs.

BTW, thanks for contribution.

Romuald Conty
  • zuck
  • Member
  • Offline
  • Registered: 2009-08-14
  • Posts: 47

Re: Request for upcomming libnfc (1.3.0) code review

Mmm...

IMHO a NFC device (or NFC-compatible device) is an electronic device which can communicate with other NFC-compatible devices, like next-gen mobile phones, etc. so it's not only the NFC reader/writer, but the complete system composed by the reader and the host PC.

An adaptor (in the sense of "interface") is a device which converts data from a format to another one and viceversa. This is what a NFC reader/writer (or a specific PN53x demo-board) do with libnfc.

In my company, we are developing an electronic device whit NFC capabilities based on a PN532 chip. The NXP chip is the NFC interface/adaptor, the entire system (with CPU, screen, etc.) is the NFC device, isn't it?

Last edited by zuck (2009-11-27 17:19:07)

  • Registered: 2009-06-22
  • Posts: 60

Re: Request for upcomming libnfc (1.3.0) code review

I'm very happy with the term "device". If you look at operating system architectures you have programs and libraries using device drivers to talk to devices. That is what we have here.

I have my code that uses libnfc map to the error codes ERROR_BAD_DEVICE, ERROR_NOT_READY, ERROR_IO_DEVICE etc and the messages bubble up through the win32 error system as "device not ready" etc. Maps very nicely to user expectations, eg the same thing they would get if they had not put a CDROM or floppy in a drive.