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.
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
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.
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.
Romuald Conty