Hi all,
I'm new to this list. I'm the maintainer of AVRDUDE, a software that
can program AVR microcontrollers through certain ways, including
directly bit-banging the ISP interface.
Jason Hecker recently submitted a patch to allow for using an FT232H
device, based on the 0.19+ additions of libftdi, and I tried getting
that to work on my FreeBSD machine.
I'll summarize some minor FreeBSD issues when compiling the git
version of libftdi separately, this article is about strange
observations with the FT232H device.
The good news first: yes, it works.
However, it experienced funny performance effects. Attaching the
UM232H module to a fullspeed (only) hub results in a huge performance
degradation. Reading a 128 KiB controller takes about 50 s, while an
FT2232D-based board on the same hub, same libftdi, same libusb takes
between 10 and 12 s (depending on the bitbang clock speed).
Plugging that UM232H into a highspeed hub gets it to fancy 5 s.
So I played around a little more. Attached a printer cable to my
server, so I could output debugging state data to the logic analyzer
from within AVRDUDE and libftdi. ;-) Good ol' simple parallel ports
certainly have some merit.
It's puzzling. First, libftdi uses the old libusb-0.1 interface (I
thought they were up to the 1.0 API now), and FreeBSD's
usb_bulk_read() behaves differently from other OSes here: when trying
to read more than one packet's worth of data (which is physically
impossible on the USB), it subsequently waits until the timeout is
expired. This can be seen on screenshot
http://uriah.heep.sax.de/outgoing/ft232h-fs-unpatched.png : the 'b'
trace data indicate the time spent in usb_bulk_read(), while the 'B'
data indicate usb_bulk_write(). (I added more trace data, but that's
not visible in that screenshot's timing resolution.)
When I apply the following patch (*) to libftdi:
--- libftdi-e5fe881.orig/src/ftdi.c 2011-07-08 13:45:56.000000000 +0200
+++ libftdi-e5fe881/src/ftdi.c 2011-09-06 21:32:14.000000000 +0200
@@ -1575,7 +1578,7 @@
ftdi->readbuffer_remaining = 0;
ftdi->readbuffer_offset = 0;
/* returns how much received */
- ret = usb_bulk_read (ftdi->usb_dev, ftdi->out_ep, ftdi->readbuffer,
ftdi->readbuffer_chunksize, ftdi->usb_read_timeout);
+ ret = usb_bulk_read (ftdi->usb_dev, ftdi->out_ep, ftdi->readbuffer,
packet_size, ftdi->usb_read_timeout);
if (ret < 0)
ftdi_error_return(ret, "usb bulk read failed");
I get what is shown in screenshot
http://uriah.heep.sax.de/outgoing/ft232h-fs-patched.png (mind the
narrowed timing resolution; markers G1 and G2 are still indicating the
same 2 ms time spacing). It's getting much faster then, albeit it's
strange it is sitting for three times in usb_bulk_read() before
proceeding with another usb_bulk_write().
http://uriah.heep.sax.de/outgoing/ft232h-fs-patched.png
((*) Basically, what the patch does is to reduce the request size for
each usb_bulk_read() to the maximal possible packet size, which is 64
for fullspeed USB, and 256 for highspeed USB. Without the patch, the
read operation attempts to get 4096 bytes at once.)
In contrast, when attaching it to a highspeed hub, reads and writes
really go back and forth, see
http://uriah.heep.sax.de/outgoing/ft232h-hs-patched.png . Basically,
one read or write operation commences at each USB frame (1 ms). (As
the packet size is now also increased from 64 to 256 bytes, this
causes an additional performance boost.)
Strange enough, when I use my FT2232D device instead, the effect of
the patch is just the opposite: without the patch
(http://uriah.heep.sax.de/outgoing/ft2232-unpatched.png) read and
write operations happen about each 2 ms, but with the patch
(http://uriah.heep.sax.de/outgoing/ft2232-patched.png), there are
three or four read operations for each write operation.
(For the FT2232D, I didn't connect the data pins to the analyzer, just
the debugging data on the PPI row only.)
I'm confused.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
