With the latest speedup, ft245r works pretty well and fast.

So I think this one can be closed finally.

I'm testing this patch with avrdude 5.10.

I have something wrong, and ig goes into an infinite loop:

CMD: AC530000  RES: FFFFFFFF
ftbb: ATMEGA168 program enable received bad echo: expected 53 but was ff
CMD: AC530000  RES: FFFFFFFF
ftbb: ATMEGA168 program enable received bad echo: expected 53 but was ff
...

(It seems that avrdude is not asserting "reset": my leds keep flashing...... )

"Markers" ... just a name for a generic mechanism.  We can ensure that some pattern is found in the input data; so we do so, and use that to flag the data we might not otherwise be able to find.

Why libusb calls?  Because libftbb wasn't sufficient, and since anyway it relies on libusb to exist.  In ftdi_usb_open() the use is just to find the specified device.  In fastcmd() the comment explains the issue:  libftbb does buffer flushes in a bad order, and the direct call is used to minimize the amount of garbage sitting in the buffer (and maximize the amount of real data).

See also the patch I posted to the mailing list:

http://lists.gnu.org/archive/html/avrdude-dev/2006-10/msg00011.html

This uses libftdi on Linux, and looks forward to using the smarter capabilities on the c-rev ft232 chips ... it doesn't
bang individual bits, but bangs them in bulk, so that the
overall speed is a lot better.

Note that even at this much-improved speed, I needed to
also hack avrdude to avoid superfluous I/O.  Such as
writing every block, after they'd all been erased, and
a few other cases; ideally avrdude would grow a mode
whereby it only flashes bytes stored in the hexfile.

A new programmer type, 'ftbb', has been created.  Within avrdude.conf, you can now create a new programmer definition with type 'ftbb':

programmer
  id       = "ezdop";
  desc     = "AE6HO EZ-Doppler";
  type     = ftbb;
  baudrate = 230400;
  reset    = 5;
  sck      = 3;
  mosi     = 2;
  miso     = 1;
;

The baudrate parameter maps to the bit bang interface baudrate.  The above definition has been added to avrdude.conf.in, copy and edit as needed.

Due to the check for a valid pin number between 1 and 17, the pin definitions correspond to the FTDI data bus pin + 1.  For example, with an FT232BM, 'reset = 5' means you are telling avrdude that RESET has been wired to the bit bang bus D4.  Thus valid values are 1 - 8 to correspond to bit bang bus D0-D7.

No support exists yet for specifying the port via -P.  The bit bang code is hardwired to use FTDI device number zero.  You will still have to invoke the command line parameter '-P ft0', and if this is missing or set to something besides 'ft0', the program will error out.

I've tested all the basic operations from the command line and from the terminal mode, with success, using an ATMega8 and an FT232BM.  I have no experience yet with the FT2232 part so I don't know if it would be supported at all.  FT245BM should work with no differences.

As has been mentioned previously, this implementation is very slow. Transmitting a byte to lower SCK, reading a byte to get MISO status, transmitting another byte to raise SCK to clock in, MOSI, etc., results in a ping-pong effect on the USB bus.  But this is required to return the data the AVR is clocking out the MISO line to the calling routine.  The FTDI USB latency timer does not seem to function in bit bang mode, so experimenting with this value hasn't made any difference.

I'll be working on an update to this implementation to clock out an entire command in a single USB packet for commands that don't need a response; this will at least improve things like writes.

Finally, the support exists for Cygwin only, and dynamically links to the FTDI FTD2XX DLL.  The Makefile.am changes have the location of the FTD2XX.h and FTD2XX.lib files (supplied by FTDI) hard coded; you'll need to fix these up to correspond to the location in your build environment.