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.
