nfcpy

nfcpy:stable/0.10

  1. Git
  2. lp:nfcpy
  3. stable/0.10
Last commit made on 2015-10-02
Get this branch:
git clone -b stable/0.10 https://git.launchpad.net/nfcpy

Branch merges

Branch information

Name:
stable/0.10
Repository:
lp:nfcpy

Recent commits

685654b... by "<email address hidden>" <>

Fixes an initialization issue when PN532 is connected to serial port on Raspberry Pi

0c00de8... by "<email address hidden>" <>

also raise ENODEV when PN532 initialized for native USB transport

d57430d... by "<email address hidden>" <>

fix issue with pn532 initialization on Raspberry Pi serial port

29f4fce... by "<email address hidden>" <>

delete continue statement that was commented out

d3bda9b... by "<email address hidden>" <>

pn532 sam configuration for normal mode must be done earlier and with long preamble

6edc8f9... by "<email address hidden>" <>

update with latest trunk revision

860ecb4... by "<email address hidden>" <>

Bugfix release 0.10.1

* Issue warning when nfc/clf/pn53x.py is atttempted to be used as a
  driver (since version 0.10 pn53x contains only an abstract base
  class, drivers are in pn531.py/pn532.py/pn533.py).

* Fixed an issue with PN532 deactivation - the chip needs additional
  time after change of serial baudrate before the next command may be
  send.

* Polling libusb if requested timeout is None (forever) may cause
  a missed a response packet if response arrives between two calls
  to bulk read. This would require use of the asynchronous API that
  PyUSB unfortunately does not support. The temporary fix is to use
  some pretty odd value that is less likely to be the same as a chip
  timeout.

fc74b64... by "<email address hidden>" <>

document history for version 0.10.1

5350998... by "<email address hidden>" <>

The PN532 needs a little time after change of serial baudrate before next command can be send.

5378f15... by "<email address hidden>" <>

Temporary fix for usb polling - it can happen that a usb response is missed when not in bulk read. The only good solution may be to implement asynchronous access to libusb, which PyUSB unfortunately does not.