While here, rename the pn53x_transceive_callback() function to
pn53x_transceive_check_ack_frame_callback() to make it more obvious what it is
supposed to do.
- 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.
In r509, a direct call to pn53x_transceive() was changed into a call to nfc_initiator_transceive_dep_bytes() which is part of the public API. The command to send was updated accordingly, but the code that extracts the response have not.
Update issue 98
This should fix the problem: because the response was not the expected length, the actual card data was not copied to the buffer, so it was always the same 16 uninitialized bytes that where returned for any block.
PR: Issue 98
Submitted by: zamby.ing
Pointy hat to: me
Or maybe I would rather have removed the const and called strdup(3)?
New issue
Summary: Sync code and comments
Owner: rconty@il4p.fr
Status: New
Romuald, can you please review this changeset and fix the code if I corrected
the wrong way (i.e. the comment was Okay and the code bogus while I fixed the
comment thinking the cod was right).
Thanks!
New issue
Summary: Make sending ACK on message transmission skipable.
Owner: rtartiere@il4p.fr
Cc: rtartiere@il4p.fr
Status: New
I guess that for performance reasons, some advance users would prefer to skip
sending the non-mandatory ACK on data transmission. They may also perform a
quicker check of the ACK returned by the chip after sending the command and
before receiving the response (not sure about this one).
It will probably be a ./configure option disabled by default that allows some "shortcuts" to perform NFC hacking.
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.
New issue
Summary: pn53x_transceive() workaround reverences in examples/nfc-poll.c comments
Status: New
Owner: rconty@il4p.fr
Cc: rtartiere@il4p.fr
The source code of nfc-poll has references to no using pn53x_transceive() for
the status-byte workaround reason in a comment. However this function is not
called in the code. While I guess that's some comment that should have been
removed and have never reached the svn repo, I prefer to be sure that it can be
removed. The comments where introduced at the same time of the file, at r353.
ISO C forbids empty source files. Instead of compiling possibly empty source
files depending on the compiler parameters, only compile required files to
build the library as requested at the ./configure stage.
Windows users (and more precisely non-autotools users), you may have to update
whatever you use to build the libnfc to fit your needs. The Makefile shipped
in the windows directory compiles all drivers as it is written so you should
not notice any difference, but if you don't use _that_ makefile, then you will
have to do some adjustment.
For now, keep the defines in CFLAGS just in case. Planned for removal in circa
one week.
While here, pet `./configure` output (--help format and summary).
I am sure we don't have /dev/ttyUSB*, and since I use /dev/cuau0 with a
cross-over cable to connect 2 machines and have a serial console, I guess
"/dev/cuau" is the SERIAL_STRING that's expected to work for me. A quick test
would be cool however, but I don't own a serial NFC device.
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 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.
As the documentation states, and as reported in isssue 81 (fixed in r421),
usb_reset()'s argument is invalid after the call and so usb_close(3) must be
called before usb_reset(3).
The doc says LCS (aka abtTx[4]) must be set so that the lower byte of LCS+LEN
(aka abtTx[3]) is 0x00. This has not to be related to the USB buffer size, so
that we can adjust it without breaking down the libnfc.
- Complete indent(1)'s arguments list;
- Ensure files to be indented have no local edit;
- Hide indent command-line details. Since everything is static, no need for V=1 support.
- 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).
- format '%ld' expects type 'long int', but argument 2 has type 'unsigned int';
- format '%ld' expects type 'long int', but argument 2 has type 'size_t'.
Tested on FreeBSD arm.
- format '%d' expects type 'int', but argument 2 has type 'long unsigned int';
- format '%d' expects type 'int', but argument 2 has type 'size_t';
- unused variable 'nti';
- unused parameter 'argc'.
Romain Tartiere