Pylibftdi

Latest version: v0.22.0

Safety actively analyzes 638720 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 3 of 6

0.14.2

~~~~~~
* new - optional device_index parameter to `Device()` constructor, select
devices by index rather than (just) serial number / description as per
device_id

0.14.1

~~~~~~
* install - only install the ftdi_osx_driver_* scripts if we're installing
to an OS X machine

0.14

~~~~

* refactor - split the `Device` class from the driver.py module into its
own 'device.py' module
* refactor - fix tests so they work both standalone and when run via e.g.
python -m unittest discover
* change - now resets the flow control and baudrate during device
initialisation
* new - SerialDevice class - supports properties for various serial lines
(CTS, DTS, RI as inputs; DTR, DSR as outputs)
* new - ftdi_osx_driver_{re,un}load scripts to disable / re-enable the
built-in drivers supplied on Mac OS X
* new - midi_output example - using pylibftdi to output MIDI data

0.13

~~~~

* When finding and opening a device, don't just present the last error (which
may well be a 'device not found (-3)' error, but more specific ones. Avoids
issues where errors opening a device were being masked as pylibftdi would
continue looking for other devices to open, and report on failure to find
any of them.
* Don't error out on failure during string retrieval part of device
enumeration (list_devices) on failure to read product manufacturer,
description or serial number (bitbucket issue 10)
* Fix Driver.libftdi_version() for older library versions (which don't report
version information...)
* USB_PID_LIST now defaults to 0x6001, 0x6010, 0x6011, 0x6014. The new
entries are 0x6010 and 0x6011. Note that USB_PID has been removed, and
USB_VID has been replaced with FTDI_VENDOR_ID
* Updated documentation, specifically regarding use on OS X Mavericks
* Added serial_loopback example test, for investigating ongoing issues with
UB232H module serial loopback losses...

0.12

~~~~
* Optimisation on accessing port property when direction is set to ALL_OUTPUTS
- don't bother reading the pins first. Makes ``port`` identical to ``latch``
in this case.
* Support for libftdi 1.x, used by preference over ftdi 0.x. The specific
driver search can be given as a string (or tuple of strings) to the
``Driver`` constructor, e.g. the default is equivalent to::

>>> d = Driver()
>>> equivalent to...
>>> d = Driver(('ftdi1', 'libftdi1', 'ftdi', 'libftdi'))
>>> and if we wanted to use ftdi 0.x on Linux:
>>> d = Driver('ftdi')

The driver in use can be determined by ``Driver.libftdi_version()`` method::

>>> from pylibftdi import Driver
>>> Driver().libftdi_version()
(1, 0, 0, '1.0', 'v1.0-6-gafb9082')
>>> Driver('ftdi').libftdi_version()
(0, 99, 0, '0.99', 'v0.17-305-g50d77f8')

* Support for MS Windows (which requires the 'lib' prefix on ftdi searching -
previously absent).
* Minor bug fixes

0.11

~~~~

* API changes
* Device() parameter 'interface' has been renamed to 'interface_select',
as it wasn't clear what this meant. Symbolic constants 'INTERFACE_ANY',
'INTERFACE_A'/B/C/D are provided in the pylibftdi package namespace.
* Device() parameter 'buffer_size' has been renamed to 'chunk_size' because
there isn't any buffering going on, so it was potentially misleading.
* new 'latch' property on BitBangDevices reflects current state of output
latch, for better defined behaviour on read-modify-write operations on
mixed-direction ports.
* fixed the bit_server example; run as
python -m pylibftdi.examples.bit_server
* docstring clean-ups
* BitBangDevice now reads device pin state on startup, so read/rmw operations
across process runs now work as expected; for example previously running::

>>> from pylibftdi import BitBangDevice
>>> d = BitBangDevice()
>>> d.port = 1
>>> ^D

restart interpreter

>>> from pylibftdi import BitBangDevice
>>> d = BitBangDevice()
>>> d.port |= 2

would have cleared D0, but now keeps it high (so d.port == 3)
* setup.py will now use setuptools/distribute if installed, allowing the
'develop' target.

Page 3 of 6

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.