>>>>> "Joerg" == Joerg Wunsch <libftdi@xxxxxxxxxxxxxxxxx> writes:
Joerg> Hi all, I'm new to this list. I'm the maintainer of AVRDUDE, a
Joerg> software that can program AVR microcontrollers through certain
Joerg> ways, including directly bit-banging the ISP interface.
Welcome!
Joerg> Jason Hecker recently submitted a patch to allow for using an
Joerg> FT232H device, based on the 0.19+ additions of libftdi, and I
Joerg> tried getting that to work on my FreeBSD machine.
Joerg> I'll summarize some minor FreeBSD issues when compiling the git
Joerg> version of libftdi separately, this article is about strange
Joerg> observations with the FT232H device.
Joerg> The good news first: yes, it works.
Joerg> However, it experienced funny performance effects. Attaching the
Joerg> UM232H module to a fullspeed (only) hub results in a huge
Joerg> performance degradation. Reading a 128 KiB controller takes
Joerg> about 50 s, while an FT2232D-based board on the same hub, same
Joerg> libftdi, same libusb takes between 10 and 12 s (depending on the
Joerg> bitbang clock speed).
In a fullspeed hub, for the Hish Speed H devices, the usb packet size gets
reduced
from 512 to 64 bytes. Maybe that needs to be considered. And at least on
linux, transaction only can take place in a 1 ms frame. With a high speed
hub, transaction even with a full speed device (on linux) are in 125 us
frame, so the speedup for the FT2232C is well knows. See some conversation
that I had with kernel USB developpers ages ago.
Also the device timeout of the FTDI chips must be considered. the timeout
applies, when more date is requested in an usb request than the buffer can
deliver.
Joerg> Plugging that UM232H into a highspeed hub gets it to fancy 5 s.
See above
Joerg> So I played around a little more. Attached a printer cable to my
Joerg> server, so I could output debugging state data to the logic
Joerg> analyzer from within AVRDUDE and libftdi. ;-) Good ol' simple
Joerg> parallel ports certainly have some merit.
But Intel in it's absolute wisdome made that port legacy...
Joerg> It's puzzling. First, libftdi uses the old libusb-0.1 interface
The new libusb-1 interface has it's drawbacks on windows. The relative easy
(argh) instructions how to set up libusb-0.1 on windows explode for using
libusb-1 , also Xiaofan did much work and has gave many hints.
I also stay with libftdi-0 for my xc3sprog project for that reason.
However most patches are for libftdi-1. bad situation.
Joerg> (I thought they were up to the 1.0 API now), and FreeBSD's
Joerg> usb_bulk_read() behaves differently from other OSes here: when
Joerg> trying to read more than one packet's worth of data (which is
Joerg> physically impossible on the USB), it subsequently waits until
Joerg> the timeout is expired. This can be seen on screenshot
Joerg> http://uriah.heep.sax.de/outgoing/ft232h-fs-unpatched.png : the
Joerg> 'b' trace data indicate the time spent in usb_bulk_read(), while
Joerg> the 'B' data indicate usb_bulk_write(). (I added more trace
Joerg> data, but that's not visible in that screenshot's timing
Joerg> resolution.)
Joerg> When I apply the following patch (*) to libftdi:
Joerg> --- libftdi-e5fe881.orig/src/ftdi.c 2011-07-08 13:45:56.000000000
Joerg> +0200 +++ libftdi-e5fe881/src/ftdi.c 2011-09-06
Joerg> 21:32:14.000000000 +0200 @@ -1575,7 +1578,7 @@
ftdi-> readbuffer_remaining = 0; readbuffer_offset = 0;
Joerg> /* returns how much received */ - ret = usb_bulk_read
Joerg> (ftdi->usb_dev, ftdi->out_ep, ftdi->readbuffer,
Joerg> ftdi->readbuffer_chunksize, ftdi->usb_read_timeout); + ret =
Joerg> usb_bulk_read (ftdi->usb_dev, ftdi->out_ep, ftdi->readbuffer,
Joerg> packet_size, ftdi->usb_read_timeout); if (ret < 0)
Joerg> ftdi_error_return(ret, "usb bulk read failed");
Joerg> I get what is shown in screenshot
Joerg> http://uriah.heep.sax.de/outgoing/ft232h-fs-patched.png (mind the
Joerg> narrowed timing resolution; markers G1 and G2 are still
Joerg> indicating the same 2 ms time spacing). It's getting much faster
Joerg> then, albeit it's strange it is sitting for three times in
Joerg> usb_bulk_read() before proceeding with another usb_bulk_write().
A Suse zypper update installed non-fitting X libraries/server on my system
at home, so no chance to look at the traces.
Joerg> http://uriah.heep.sax.de/outgoing/ft232h-fs-patched.png
Joerg> ((*) Basically, what the patch does is to reduce the request size
Joerg> for each usb_bulk_read() to the maximal possible packet size,
Joerg> which is 64 for fullspeed USB, and 256 for highspeed USB.
Joerg> Without the patch, the read operation attempts to get 4096 bytes
Joerg> at once.)
Joerg> In contrast, when attaching it to a highspeed hub, reads and
Joerg> writes really go back and forth, see
Joerg> http://uriah.heep.sax.de/outgoing/ft232h-hs-patched.png .
Joerg> Basically, one read or write operation commences at each USB
Joerg> frame (1 ms). (As the packet size is now also increased from 64
Joerg> to 256 bytes, this causes an additional performance boost.)
Joerg> Strange enough, when I use my FT2232D device instead, the effect
Joerg> of the patch is just the opposite: without the patch
Joerg> (http://uriah.heep.sax.de/outgoing/ft2232-unpatched.png) read and
Joerg> write operations happen about each 2 ms, but with the patch
Joerg> (http://uriah.heep.sax.de/outgoing/ft2232-patched.png), there are
Joerg> three or four read operations for each write operation.
Causing unneeded USB transactions is always a bad thing!
Joerg> (For the FT2232D, I didn't connect the data pins to the analyzer,
Joerg> just the debugging data on the PPI row only.)
Joerg> I'm confused.
Will look at the patches as soon as X is back on my system. But probably
also to get confused.
B.t.w.: How common are Full-Speed hubs. Is debugging worth the effort?
And do you really bitbang? Why not MPSSE?
Bye
--
Uwe Bonnes bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
