fix mem leaks in examples ftdi_deinit -> ftdi_free

Update README.mingw to reflect current Windows libusb situation

Mark release candidate status

Quick start guide how to build libftdi

Update ChangeLog

Update AUTHORS

Update README and TODO

Increase copyright year (final release will be in 2013)

Grab changelog from libftdi 0.20

Fix rpm dependency

rpm .spec file: Package the python wrapper

Install ftdi_eeprom

First shot at fixing the .spec file

C++ wrapper: Fix use-after-free issue in List::find_all()

We can no longer call ftdi_deinit() inside find_all().
This will call libusb_exit() which invalidates all further
operations on device lists / usb devices pointers.

Instead we pass in the Ftdi::Context from the calling side.

Tweak doxy2swig.py output to include Returns header

Underlines are proportional to the title now also.

Extract doxygen from ftdi.c to python docstrings

Uses the doxy2swig.py script to process the doxygen-generated
doc/xml/ftdi_8c.xml file into a SWIG file ftdi1_doc.i.

This allows the documentation to show in a python docstring viewer from
something like ipython.

Enable separate doxygen XML output

The xml is to be post-processed for other purposes, e.g. generating python
docstrings via a script.

Fix build on FreeBSD (cmake file typo)

Updated python wrapper: Fixes for python3 + documentation

xantares 09 wrote:
- Fixed examples with python3
- Added docstring documentation

Note: the read_chipid function fails from python3.

Fix python lib linking on MacOS X

Improve cpack packaging

- Filter out "build" directory
- source package name is arch-dependent

Fix doxygen doc generation if C++ wrapper is not built

python bindings: python3 support

Whitespace fixes by Thomas Jarosch (detected by pylint and git)

Remove ftdi_async_complete() left over from libftdi 0.x

Avoid to link python libs on debian

Fix wrong array access in set_ft232h_cbus()

Changed code by Martin Devera <martin.devera@wifcom.cz>,
patch and commit log by Thomas Jarosch.

Merge branch 'renames-for-release'

Python stuff is solved now

fixed NULL-pointer dereference in the ftdi_error_return(code, str) macro that occures when it is called because of a ftdi == NULL check

Hi,

as we just performed a Cppcheck run upon our project including the libftdi sources it found a possible null-pointer dereference when calling the ftdi_error_return(code, str) macro after the ftdi==NULL check.

Fix for this bug:

fixed NULL-pointer dereference in the ftdi_error_return(code, str) macro that occures when it is called because of a ftdi == NULL check

Hi,

as we just performed a Cppcheck run upon our project including the libftdi sources it found a possible null-pointer dereference when calling the ftdi_error_return(code, str) macro after the ftdi==NULL check.

Fix for this bug:

Remove old async mode ignore lines

Reported by Michel Zou

Rename python wrapper to ftdi1. Adapt examples with minimal code changes

ftdi_eeprom: reset the device after flashing the eeprom

If we change e.g. the product-id the change will take effect immediately
without having to unplug/replug the device.

Signed-off-by: Anders Larsen <al@alarsen.net>

Document the FT245R EEPROM weirdness

The FT232R and the FT245R share the same USB id (0x0403, 0x6001) and are
only distinguished by bit 00.0 in the (internal) EEPROM.

ftdi_eeprom currently can't handle this and will turn an FT245R chip
into an FT232R; document the fact.

Signed-off-by: Anders Larsen <al@alarsen.net>

ftdi_eeprom: Added config value "eeprom_type"

The default eeprom size is 128 bytes - if we have a larger one, we need
a way to specify the fact.
Using ftdi_read_eeprom() / ftdi_eeprom_decode() to get the actual eeprom type
is not an option as ftdi_eeprom_decode() would overwrite the values set
by ftdi_eeprom_initdefaults()

Signed-off-by: Anders Larsen <al@alarsen.net>

ftdi_eeprom: reset the device after flashing the eeprom

If we change e.g. the product-id the change will take effect immediately
without having to unplug/replug the device.

Signed-off-by: Anders Larsen <al@alarsen.net>

Document the FT245R EEPROM weirdness

The FT232R and the FT245R share the same USB id (0x0403, 0x6001) and are
only distinguished by bit 00.0 in the (internal) EEPROM.

ftdi_eeprom currently can't handle this and will turn an FT245R chip
into an FT232R; document the fact.

Signed-off-by: Anders Larsen <al@alarsen.net>

ftdi_eeprom: Added config value "eeprom_type"

The default eeprom size is 128 bytes - if we have a larger one, we need
a way to specify the fact.
Using ftdi_read_eeprom() / ftdi_eeprom_decode() to get the actual eeprom type
is not an option as ftdi_eeprom_decode() would overwrite the values set
by ftdi_eeprom_initdefaults()

Signed-off-by: Anders Larsen <al@alarsen.net>

Another TODO entry gone

cmake already places the header in /usr/include/libftdi1/ftdi.h, just needed to adapt the .spec file

Don't rename python wrapper for now

Otherwise all python code would have
to adapt from "ftdi.xxx()" to "ftdi1.xxx()".

Try to adapt debian build rules

Rename library from libftdi to libftdi1

Rename and adapt pkgconfig files for libftdi1

We decided to skip this API change for now

Actually configure libftdi1.spec

Rename libftdi.spec.in to libftdi1.spec.in. Adapt package requirements to libusb1

Rename libftdi-config to libftdi1-config

pkgconfig file: Depend on libusb-1.0

Fix libftdi.pc file generation when building with -DDOCUMENTATION=OFF

Add Xiaofan Chen to AUTHORS. This was long overdue

Add Jared Boone to AUTHORS

Patch for building examples on MacOS X Lion

I had trouble with CMake picking up my /opt/local/include directory before my libftdi/src directory. I was getting the MacPorts-installed libftdi-0.20 headers, not the headers from the build tree. This was only happening during building of examples/. This patch addressed my problem.

- Jared

EEPROM max_power build/decode inconsistency

Hello all,

As promised, below is a patchset to make eeprom->max_power consistently express power (current) requirements in milliamperes.

I've also updated my AUTHOR address.

Regards,

Daniel
--

From 9e854c8111dba11ea71166e22ca464b474156150 Mon Sep 17 00:00:00 2001
From: Daniel Kirkham <dk2@kirkham.id.au>
Date: Sat, 12 May 2012 19:23:57 +1000
Subject: [PATCH] Fix to make eeprom->max_power consistently express power (current) requirements in milliamperes.

Updated AUTHOR address

Add 'Anders Larsen' to AUTHORS

Bump the library version number to 2.0.0

Allow libftdi-1.0 to co-exist with libftdi-0.x to ease migration.

Signed-off-by: Anders Larsen <al@alarsen.net>

Completed the support for the FT4232H chip

Added missing fields to the ftdi_eeprom structure and the encoding and
decoding functions.

The ftdi_eeprom utility forces DRIVER_VCP on and RS485 off for all channels,
but this could easily be made configurable, should the need arise.

Signed-off-by: Anders Larsen <al@alarsen.net>

ftdi_eeprom: Fix segmentation fault after --flash_eeprom

Allocate a buffer if it's not already available (hint: it was only allocated
by --read-eeprom)

Signed-off-by: Anders Larsen <al@alarsen.net>

ftdi_eeprom: remove redundant debug output

The (commented-out) debug output after ftdi_eeprom_decode() can be removed
as that function can generate it itself (and it contained obsolete fields
anyway).
Remove the unused config option "chip_type" in the process.

Signed-off-by: Anders Larsen <al@alarsen.net>

Fix _sleep warning on MinGW

Fix header, API change ftdi_write_data_async has been replaced by ftdi_write_data_submit

Python wrapper update

- Properly wrap ftdi_read_pins / ftdi_read_data
- Add example invocation of the read function to complete.py

C++ wrapper: Reset internal USB device pointer on Context::close()

Example code: Fix compile warnings about unused variables

cpp-wrapper: when using get-string-and-reopen method without having set up the usb-device the currently opened usb-device is retreived from the usb-device-handle used in the ftdi context. this fixes the open methods of the cpp wrapper that do not get an usb-device by parameter.

Remove duplicated udev rule.

Spotted by Rogier Wolff. Thanks.

Fix build on Mac OS X

Add missing malloc in ftdi_eeprom

Fix boost include directory in unit test

Update udev rule syntax for newer kernels

Credit goes to Lucian Langa <cooly@gnome.eu.org>:

------------------------
SUBSYSTEM=="usb_device" syntax is old usb sysfs (usbfs)
support (kernel <2.6.22)

Correct syntax now should be:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device"
------------------------

One clarification for the previous commit:

Additional udev rules credit goes to
Canyon Bliss <canyon.bliss+redhat@gmail.com>

udev rules: Support all FTDI chip types

Python wrapper update

- wrapped ftdi_get_eeprom_buf
- use of ftdi_usb_find_all is easier
- useless usb_get_strings size args
- fixed possible memory leak from wrapping ftdi_new

Drop 64bit lib suffix on debian systems

Enhance python wrapper

- Updated functions prototypes in regard to the lib
- Made OUTPUT* typemaps active as they were misplaced regarding headers order
- Allowed use of ftdi_usb_get_strings
- Added an advanced example script (examples/python/complete.py)
- Stripped the 'ftdi_' suffix to avoid to write "ftdi.ftdi_usb_open(...)"; it becomes just "ftdi.usb_open(...)"
- Removed useless pointer functions since valid OUTPUT typemaps are there
- Some cleanup

Fix installaton of python wrapper

--------------------------------------------
The python wrapper installation path is not correct:
-- Building python bindings via swig. Will be installed under /usr/site-packages

In fact it doesn't even rely on CMAKE_INSTALL_PREFIX because of this:
GET_FILENAME_COMPONENT(SITEPACKAGE ${PYTHON_LIB_INSTALL}/../site-packages ABSOLUTE)

I think it should more look like this: (here with CMAKE_INSTALL_PREFIX=/home/michel/Download/libftdi-git/build/install)
-- Installing: /home/michel/Download/libftdi-git/build/install/lib64/python2.7/site-packages/_ftdi.so
-- Installing: /home/michel/Download/libftdi-git/build/install/lib64/python2.7/site-packages/ftdi.py
--------------------------------------------

Increase ftdi_eeprom->cbus_function array again

Remove errorneous ; after if

Detected by my upcoming cppcheck check

Interface can not be changed on an already open device

Based upon code from Uwe Bonnes, improved by me.

Use ftdi_new and not ftdi_init in the examples

At least our examples should use the library allocated buffer
and not a user allocated one.

Solved another TODO entry

Add example code demonstrating how to use the python wrapper

Remove old ftdi_enable_bitbang() function. It was marked as deprecated for two years

SWIG wrapper: Mark ftdi_version_info.version_str and .snapshot_str read only

Fixes this warning:
Warning 451: Setting a const char * variable may leak memory.

Use a private header for the private EEPROM structures

I added the ftdi_i.h header to bindings/ftdi.i. Noe the bindings compile
again. Other things are untouched.

Upgrade doxygen file with 'doxygen -u'

Quiet normal doxygen output so we only see the useful messages

Some more steps done towards 1.0

Merge remote-tracking branch 'origin/get-library-version'

Merge branch 'autoconf-removal'

Increase library version to 0.99

Remove unused templates directory

It was autocreated by kdevelop back in the days.

Update release process documentation

Add 'make dist' target

Remove autoconf support. Project switched to cmake

Missing version header template file

Added API to get libftdi library version.

Supports version number as integer, string
and possible git snapshot revision.

Based upon idea by Martin Zenzes.

Silence gcc warnings about possible uninitialized variables

Merge branch 'new-baudrate-code'

Adjust unit test to match baudrate calculation for AM type chips

ftdi_eeprom/main.c: Clean up the FTDI structure on exit

Valgrind still reports an error, but I suspect it is with (my version?)
of confuse.