Re: [avrdude-dev] Serial programming AVR with FTDI FT232BM Bit Bang Mode

[Johnathan Corgan]

Joerg Wunsch wrote:

> Curious, I'd assume bit-banging across USB to be really slow.  It's
> already really slow on a standard serial port, but for USB, each bit
> change will require a USB packet of its own.  

That's not how the FT232BM bit bang mode works.

Basically, it turns the eight RS232 signals into a parallel port, but 
retains the concept of "baud rate."  If you write a buffer of data out 
to the device in this mode, the chip will clock out the bytes over this 
parallel bus at a definable baud rate.  So the trick is to wire one of 
these pins to SCLK, then toggle the value of that bit in successive 
bytes in the buffer.  Some other pin gets mapped to MOSI, and you set 
the corresponding pin to the bit value to send in two successive bytes.

The effect of this is that when the FT232BM clocks these successive 
bytes over the (bit bang) bus, the SCLK bit is toggling and the MOSI bit 
has the serial data.

So one byte of data to send to SPI becomes sixteen bytes to send over 
USB (two per bit, one with SCLK low and one with SCLK high).  FTDI 
supports 4096 byte USB packets, so you can send 256 bytes of real data 
through the SPI per USB packet.

From a throughput perspective, the FT232BM supports baud rates up to 1 
Mbit/sec, and since it takes two bauds per SPI bit, the maximum SPI 
clock rate is about 512Kpbs.  It takes 32 bits or 64 bauds to send a 
command, so one can send a maximum of 16K commands per second, assuming 
there is no requirement to pause between commands.

This also assumes one is doing "blind writing", with no intervening 
reads.  Unfortunately, to read the pin status (in bit bang mode, each 
pin is set to either an input or output), one has to do a read command 
after *every byte* sent.  This does reduce throughput drastically, as it 
turns into a single USB packet per byte in each direction.  Continuous 
throughput in this mode is about 256 bytes per second, or about 64 
commands per second.  This would be the case whenever you need to read 
the response from the AVR to whatever command was sent.  (I think this 
can be improved by fiddling with the USB timers but I haven't played 
with it yet.)

Anyway, I've used this part and this technique before to program Xilinx 
FPGAs upon start up over USB, eliminating the need for a configuration 
PROM.  It does go pretty fast.  On my project it's already there to 
provide a USB serial interface to the AVR, so it seems useful to take 
advantage of its bit bang capabilities to program the part as well.

Here is a link to FTDI's application note:

http://www.ftdichip.com/Documents/AppNotes/AN232B-01_BitBang.pdf

> Why not simply use a bootloader?

I need to be able to fiddle with fuse bits and chip erase.  Can an AVR 
boot loader do this?

> My only concern for AVRDUDE would be that there's currently no
> infrastructure to maintain separate device drivers as part of the
> project.  (There's giveio.sys for the Win32 parallel-port bit-banging,
> but that's quite different.)

Well, I assume there is some sort of abstraction in the software 
architecture that becomes device independent at a point in the stack. 
I'd have no problem GPLing some code that would export an interface at 
this level and let it be statically linked into the code.  (If that is 
what you meant.)

Right now the code I've written so far assumes my exact board 
configuration and doesn't have any facility to dynamically set which 
RS2323 pins are wired to the SPI pins.  It's missing a bunch of sanity 
and error condition checks, and in general is just something I hacked 
together to be able to help debug the hardware board. But it's working 
so far :-)

-Johnathan