[avrdude-dev] [PATCH] Experimental implementation of FTDI Bit Bang interface

[Johnathan Corgan]

Below is the URL for a patch providing an *experimental* implementation 
of FTDI USB<-->Serial Bit Bang Mode programing:

http://www.aeinet.com/avrdude/PATCH-avrdude-ftbb-050818.diff

Comments, bug reports, etc., are very welcome.

A few notes about this experimental implementation:

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.

Again, comments welcome!

-Johnathan