I'm pleased to announce the release candidate of libftdi 1.3.
* Added ftdi_usb_get_strings2() to prevent automatic device close (Fahrzin Hemmati)
* Added ftdi_transfer_data_cancel() for cancellation of a submitted transfer,
avoided resubmittion of a canceled transfer in the callbacks,
replaced calls to libusb_handle_events with
libusb_handle_events_timeout_completed (Eugene Hutorny)
* ftdi_eeprom / eeprom handling:
* Add support for arbitrary user data (Salvador Eduardo Tropea)
* Add --build-eeprom support (Salvador Eduardo Tropea)
* Fix use_usb_version config file option (Thilo Schulz)
* Ability to include other config files in EEPROM config file (Thilo Schulz)
* Add external oscillator enable bit (Raphael Assenat)
* Support channel configuration (Stephan Linz)
* Added --device option to ftdi_eeprom to specify FTDI device (Robin Haberkorn)
* Fixed EEPROM user-area space checks for FT232R and FT245R chips (Robin Haberkorn)
* Various improvements to CBUS handling, including the EEPROM (Robin Haberkorn)
* swig wrapper: Fix handling of binary strings in ftdi_write_data()
for python 3 (xantares09)
* cbus python example code (Rodney Sinclair)
* ftdi_stream: fix timeout setting (Ларионов Даниил)
* Fixed typo in CBUS defines: CBUSG_DRIVE1 -> CBUSH_DRIVE1
Please give it some good testing. Final release is planned in mid-May.
Hi, Need to copy eeprom dump from one ft232r and writing it into another ft232r Have read it can be done in Linux but I have no experience in it . Will this make the two ft232r identical in terms of data. Output configuration and serial number If you can send me step by step how it can be done . Thanks Ravjeet
On Tue, May 17, 2016 at 2:29 AM, Thomas Jarosch <[hidden email]> wrote:
Am 25.04.2016 um 19:28 schrieb Thomas Jarosch:
> I'm pleased to announce the release candidate of libftdi 1.3.
> Main highlights
If I run the 'simple.c' example against libftdi 1.2 it works fine as
long as 'nothing goes wrong'.
But if I put a 'sleep(5)' command just before the "if ((ret =
ftdi_usb_close(ftdi)) < 0)" and I pull the USB plug while sleeping
valgrind tells me that not all memory is freed so the
ftdi_usb_close(ftdi) seems to leak in that specific case.
How come? Is the 'simple' example just oversimplified (although a lot of
ftdi_frees are in place)?
FYI I am using libusb from Ubuntu 14.04 LTS itself:
userspace USB programming library development files
--- Valgrind trace ---
==19593== Memcheck, a memory error detector
==19593== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==19593== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==19593== Command: ./simple
Initialized libftdi 1.2 (major: 1, minor: 2, micro: 0, snapshot ver:
FTDI chipid: 3B359ACD
unable to close ftdi device: -1 (all fine)
==19593== HEAP SUMMARY:
==19593== in use at exit: 3,543 bytes in 9 blocks
==19593== total heap usage: 1,198 allocs, 1,189 frees, 271,883 bytes
==19593== LEAK SUMMARY:
==19593== definitely lost: 152 bytes in 1 blocks
==19593== indirectly lost: 3,391 bytes in 8 blocks
==19593== possibly lost: 0 bytes in 0 blocks
==19593== still reachable: 0 bytes in 0 blocks
==19593== suppressed: 0 bytes in 0 blocks
==19593== Rerun with --leak-check=full to see details of leaked memory
==19593== For counts of detected and suppressed errors, rerun with: -v
==19593== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)