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 [email protected]
