iAbortFd file descriptor array have been removed from nfc_device_t;
nfc_abort_command() can now failed (return false);
nfc_abort_command() now call abort_command pointer from drivers;
pn532_uart and arygon drivers use a pipe-based mecanism (similar from previous one);
pn53x_usb driver use a boolean flag-based mecanism (the previous one does not work as expected);
pn53x_usb now print smarter messages on error at usb connection;
pn53x_usb now handle a strange case: sometimes, the first sent command is not ACKed by PN53x USB device, a dummy command is now sent.
- Move CMake modules from cmake_modules/ to cmake/modules/
- CMake now use cmake/config_windows.h.cmake to create config.h on Windows platform
- contrib/windows.h header is automagically included by config.h
- Put missing NFC_EXPORT macro on front of emulation API
- nfc-mfclassic and nfc-mfcultralight examples are now compiled under Windows
Many thanks to Glenn Ergeerts which provide the initial patch.
- New functions nfc_device_new(), nfc_device_free();
- Add experimental abort mechanism for the PN53x USB driver;
- Move chip-specific variables from nfc_device_t to pn53x_data (Fixes Issue 124).
Suppress any PN53x references in nfc.c
Improve nfc_driver_t struct to embedded HAL API
Merge macros from nfc-messages.h into nfc-internal.h
Remove useless files: nfc-messages.h, buses.h and chips.h
Implement HAL for ARYGON driver
Move send/receive callbacks from nfc_driver_t to internal chip io callbacks (since there are dedicated to pn53x framing)
use a new way to handle drivers
use absolute include path instead of relative ones
move some nfc_device_t members in a better place
nfc_device_t now embeddeds driver data and chip data pointers (useful to be more generic)
use more readable variables instead of strange coding convention
move PRINT_HEX macro into nfc-internal.h
silent warnings with more strict CFLAGS
chips/pn53x: use the powerful C99 writing to construct PN53x commands
chips/pn53x: remove almost all memcpy()
chips/pn53x: WriteRegister, ReadRegister and SetParameters command wrappers are correctly named
chips/pn53x: introduce chip state (SLEEP, NORMAL or EXECUTE)
chips/pn53x: add SAMConfiguration command wrapper (need to be improved)
chips/pn53x: remove almost all const arrays
chips/pn53x: use human readable defines for commands instead of hex values
chips/pn53x: in debug mode, the PN53x command is shown in human-readable string, awesome isn't it? ;-)
drivers: split transceive() into send() and receive() to be able to handle more cases (differed replies, abort commands, etc) later
drivers: use a const structure of functions instead of -dirty- callbacks array
drivers/pn532_uart: major improvement of UART handling
drivers/pn532_uart: check PN53x frames when received
buses/uart: receive() is now based on expected bytes instead of calculated timeouts..
buses/uart: use a smart way to determine available ports on POSIX systems (tested on Linux and FreeBSD)
New Issue
Summary: Remove nfc-message.h file from installed ones
nfc-message.h provide some usefull debugging macros but I am not sure that these macros have to be installed with other files.
New issue
Summary: Improve ISO 14443-B data (ATTRIB_RES) decoding
Before this revision, pn53x_decode_target_data() wrongly decode ISO14443-B. Currently, whole ATTRIB_RES field is stored in nfc_target_info_t struct.
I do not find the correct documentation to fix it better than this, but at least it now retrieves a correct value.
Always use nfc_initiator_transceive_bytes(). If you where using advanced
features and already relying on nfc_initiator_transceive_bytes(), then your
code has to be updated to unset the NDO_EASY_FRAMING option. See an example of
such a change in the libfreefare's repository:
http://code.google.com/p/nfc-tools/source/detail?r=566
Updates issue 106
Status: Feedback
Romuald: I am not sure about the option enum values. I took 0x02 thinking it
would not hurt but am not really sure about that because I can see many 'holes'
in the sequence.
- Define two sets of DE<FOOBAR> macros: the first one for 'generic' errors
which could be encountered regardless of the NFC device the library is acting
with (0xX000), and ont set for device-dependant errors (0x0X00).
- Make some more functions accept a nfc_device_t* as first argument to have
access to the iLastError;
- Reset errors when entering public API functions;
- Save errors when applicable;
- Distinguish system-level errors (e.g. I/O error) and operational errors (the
PCD returns an unexpected value);
- Minor tweaks.
Update issue 65
Status: Feedback
New review:
Owner: rconty@il4p.fr
Cc: rtartiere@il4p.fr
Summary: Review the error-handling code.
Branch: /branches/libnfc-error-handling
For this development, a strong emphasis has been set on making changes that
will not go through our way on the way to libnfc-1.6+. For this reason, some
constructs are not natural (e.g. error codes defined in two different places),
please keep this in mind when reviewing.
It was obviously an April joke: iErrorCode which was renamed iPICCError is
indeed a PCD Error, so I renamed it to iLastError since communications errors are
also to handle at the device driver level (read chip level), although I guess
that some errors would be common to distinct devices.
PICC error are irrelevant because they can either be transmission error
detection (in which case the libnfc should retry the transmission) or
application-level errors the libnfc cannot be aware of.
- Rename the nfc_device_t's struct iErrorCode member to iPICCError (We are
likely to have both PICC and PCD errors fields to avoid unneeded complexity
at some point);
- Make the PN53x error descriptions static;
- Enhance some comments here and there.
Avoid redundant code in PN53x usb and uart drivers. Since it makes sense to
report errors at the nfc_device_t level, pass it directly to
pn53x_transceive().
Programs using the libnfc MAY use pn53x_transceive() to communicate with a NFC
device, and SHALL not use anymore pnd->pdc->transceive(). Code in the library
itself SHOULD avoid calling pnd->pdc->transceive(), so such construct have been
updated accordingly.
Within the ongoing effort to improve the NFC devices abstraction, and now that
pn53x_transceive() does not fail when it reads a response that has no
status-code, do not call directly pnd->pdc->transceive() from nfc.c. In a
mid-term future this will be changed again, and calling pn53x_transceive() from
nfc.c will be forbiden, in favor of colling some pnd->transceive() function,
but that's another part of the story.
Of course, it changes the API one more and it's not going to be the last time
in this branch.
New issue
Summary: Provide a target listing function
Labels: Milestone-1.4.x
Libnfc lacks of target listing function. Actually, applications or libraries based on libnfc have to wrote their own listing function which can provide side effect if two or more of theses libraries are used together in the same application. Plus, some kind of problem could appears during listing multiples targets (i.e. collisions) and this problem should be solved in libnfc (i.e. using NFC chip capabilities), not in applications based on libnfc.
- New API functions: nfc_strerror(), nfc_strerror_r() and nfc_perror();
- Drivers now have a reference to chips callback methods;
- Rename -pn53x_err2string to pn53x_strerror and add it to pn53x_callbacks_list.
- New API function append_iso14443a_crc();
- Add a PRINT_HEX macro for driver debugging (replaces print_hex function from bitutils.c);
- Move bit-mirroring related functions to libnfc/mirror-subr.[hc];
- Move iso14443 related functions to libnfc/iso14443-subr.c;
- Move libnfc/bitutils.c hex-dumping code to examples/nfc-utils.c;
- Replace calls to swap_endian32() and swap_endian64() functions with calls to bswap32() and bswap64 provided by endian.h.
And while I am here:
- Fix the DBG macro so that it does not throw warning at compile time.
This is not a 'complete' fix since the DBG macro is still using it; but more globally, this file should not be part of the libnfc installed files. We should rely on error codes and maybe some logging mechanism (e.g. syslog() on POSIX compliant systems and RegisterEventSource() / ReportEvent() on Windows).
