[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] Serial programming AVR with FTDI FT232BM Bit Bang Mode
From: |
Johnathan Corgan |
Subject: |
Re: [avrdude-dev] Serial programming AVR with FTDI FT232BM Bit Bang Mode |
Date: |
Sat, 13 Aug 2005 16:29:26 -0700 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
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