Dear Maintainer,

I recently upgraded avrdude from debian version 6.3-5.  After upgrading I was
unable to use my default programmer, arduino-ft232r without setting a -P port
parameter on the command line.  Upstream patch 8580 modified ft245r.c to allow
selection of a particular ftdi device based on the serial number of the device.
Unfortunately this patch has broken the ability for avrdude to automatically
select the first ftdi port for ft245r devices, which include arduino-ft232r.

Furthermore, there is no way to specify the serial number in the .avrduderc
file which has effect with these ft245r devices.  All attempts to set
"default_serial" or "default_parallel" with the correct "usb:SERIAL_NUM" which
work with the -P parameter failed to get past the conditional at line 554 of
ft245r.c.  Attempts to create a custom programmer with a parent of
arduino-ft232r or ft245r which attempted different combinations of setting
"usbdev" and "usbsn" to the appropriate serial number failed to satisfy the
aforementioned conditional.

I consider the upstream patch 8580 as ill formed in that it breaks existing
configurations without providing a way to specify a device serial number in
.avrduderc via either the default_serial or through a custom programmer with
usbdev or usbsn specified.  I am not sure how to incorporate the previous
behavior which selected the first ftdi device and "just worked" in version
6.3-5 with the added functionality for allowing users with multiple ftdi
devices to select a particular one via serial number.

The upstream patch 8580 is also logically incorrect in that the "else if"
conditional on line 573 is unreachable.  Any port which does not satisfy the
sscanf conditional at line 554 will immediately shortcut to the error return at
line 558.  A correct patch must strncmp "port" with DEFAULT_USB for
strlen(DEFAULT_USB) and then check if "port" is longer than strlen(DEFAULT_USB)  and then it can perform the sscanf conditional at line 554.

The upstream patch is also broken for the parsing of ftX style ports in the
conditional at 573.  Comparing "device" with "ft" is not correct.  The correct
comparison is between "port" and "ft".

The patch provided in the previous message makes some changes to how ft245r
devices parse the port command line parameter.

1) for a default port (no -P provided) or "-P usb" it will select the first
   ftdi devnum (0).  This reverts to the operation prior to upstream patch
   8580.

2) for a -P usb:XXXXXXXX it will check if a valid serial number is provided and
   select the correct ftdi devnum.  In this regard it is identical to the
   functionality of upstream patch 8580.

3) for a -P usb:ftX it will fail.  In this regard it is a reversion of the
   functionality of upstream patch 8580.  I think the logic could be altered to
   allow this type of port selection. I would not be averse to this change and
   it would accommodate users who have changed to post 8580 port selection
   semantics.  I believe that the helpful message at line 590 of 7e245a25
   should be more clear about how to pass "-P usb:ftX" if this variant is kept.

4) for a -P ftX it will select the ftdi devnum provided by X. In this regard it
   is a reversion to the previous operation prior to upstream patch 8580.

I don't know if upstream want to allow the "-P ftX" anymore, or if they want to
transition to the "-P usb:ftX" manner of port selection for usb attached
devices.

The patch does not address the possibility of parsing the usbsn or usbdev
parameters from .avrdudrc file.  These parameters are available in the pgm
structure, but I think an even better way to avoid having to create a custom
programmer type would be to parse the default_serial or default_parallel
parameters from .avrduderc.  I am not familiar enough with avrdude to provide a
patch which would look at these parameters and try to use them in the "port"
parameter of the ft245r_open function.

This feature was introduced with upstream[0] svn commit 1415. Please
engage the upstream development project and explain the problem and
possible solutions. In the meantime I'm setting severity of this bug
report to wishlist and tagging it as an upstream issue.


Milan


[0] http://svn.savannah.gnu.org/viewvc/avrdude?view=revision&revision=1415