BBB - USB I/O with FTDI FT2232H

RE: BBB - USB I/O with FTDI FT2232H

ravi_butani — Wed, 24 Oct 2018 17:23:52 GMT

Hii [mention:b0bc65b9ecdc4307bd967592f00e340a:e9ed411860ed4f2ba0265705b8793d05]..

Excellent tutorial... Just worked like a charm for synchronous FIFO implementation on FT232H by changing PID...

I am designing IRNSS GNSS Receiver and want to record IQ data from my DIY RF Frontend for post processing at 6MBPS rate... Seriously you saved me [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-2ebbaa5d-3a7e-4744-baa1-d950963a3a80/contentimage_5F00_3.png:16:16] its one of the critical task for my ongoing PhD...

Thanks,

Ravi

RE: BBB - USB I/O with FTDI FT2232H

Former Member — Mon, 15 Jul 2013 20:56:48 GMT

It appears that bytes are guaranteed to skip, and I'm guessing this is because there is a delay writing to the filesystem. With a very short *WR pulse (of the order of tens on nsec) the number of bytes written to file appear to be close to the expected value (assuming that the FT2232H is trying to capture at 60MHz). At any longer pulse, bytes are skipped. For further investigation!

That's likely to be a USB limitation, remember USB 2.0 is 480Mbit/s so at it's theoretical maximum, divide by 8 and you get 60MB/s. Effective throughput is much less due to protocol overheads and any other devices on the bus. Think about a keyboard that's operating at 1.5Mbit/s on the same bus, how much of your theoretical 60MB/s gets lost when a single bit takes 320 times as long to send ?

Also, when you're doing this on a BBB think in terms of the overall system, can you write to the eMMC or SD card at 60MB/s, or even 30MB/s, probably not. If you're using a USB hard drive then you fall foul of only having a single USB port and having to share the bandwidth. Network perhaps ? No as it's only a 100Mbit/s network port. So you're left with writing to buffer cache which will get flushed to storage later, but if we assume 60MB/s and only 512MB RAM at least some of which is already in use you won't get long before you've exhausted that resource as well.

So the 60MHz advertised rate only works so long as you can empty, or fill the usb buffers in the 2232 fast enough, after that you either have to pause to catch up or start dropping captured samples on the floor.

For me this detracts quite a lot from using USB connected stuff for anything serious as you basically need to put a microcontroller, fpga or similar onto the other end of the usb cable to do the interesting stuff for you. It needs enough local memory to meet whatever the requirement is since it can't guarantee it can pass it back over usb quickly enough.

There's things like the Open Bench Logic Sniffer that do exactly this, and scaled up a bit you could look at the BBB connected to your bigger PC over usb in much the same way [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-2ebbaa5d-3a7e-4744-baa1-d950963a3a80/contentimage_5F00_1.png:16:16]

RE: BBB - USB I/O with FTDI FT2232H

Former Member — Mon, 15 Jul 2013 12:06:07 GMT

I forgot to say, your diagram shows libftdi & libusbx sitting on top of a driver. That's slightly misleading. While there will be a driver of some sort for the USB host port that will be there regardless if you want to be able to talk to the usb bus.

The diagram could give the impression that you need the ftdi_sio driver installed and libusbx then talks to that, but a big part of the point of libusbx is that you can talk to the device without requiring a driver at all and can therefore write your driver as a userspace application.

RE: BBB - USB I/O with FTDI FT2232H

Former Member — Mon, 15 Jul 2013 10:33:21 GMT

A couple of observations as I'm just delving into libftdi for a second time... Lots of the libftdi code has hard coded device id's that dont cover all of the available ftdi devices. For example the ftdi_usb_find_all api function defaults to a limited subset which doesn't include the device I'm currently using.

This makes it rather more interesting when none of the examples work and you don't (initially) know if it's the board you've just built, their code, your code or whatever.

libconfuse isn't needed for libftdi itself, only for ftdi_eeprom

libusbx is a fork of libusb. Whatever you think of forks, or the reasons behind this one, it's worth mentioning a couple of specific things in this case. Currently libusb and libusbx are more or less compatible from a features and api perspective, however the libusbx folks deliberately decided to make libusbx a straight drop-in replacement using the same soname and version. This has the side effect that you can't install both, you have to pick a side. That leads you to the problem of which one your distro picked and has hard-coded into various package dependencies.

Currently the only apparent difference for libusbx is the addition of a 'version' call in the API, but as the two APIs inevitably diverge then either the drop-in replacement strategy will have to change, or you will get issues.

The bitbang modes (with the possible exception of mpsse mode which I haven't tried) are only suitable for very simple gpio usage. Previous experience shows that your 20000 writes per second won't produce a square wave and the variations won't be consistent from one cycle to the next.

Rather than using ftdi_read_pins and such like, it's possible to set the baud rate and then use ftdi_read_data to read data that's supposedly clocked in at the baud rate you've set, or to use ftdi_write_data to clock out a buffer full of data.

Again though, it appears there's variable latency somewhere and what you get on a scope isn't what you expect.

So for simple on/off requirements it's fine, or for something where you use one of your bitbang pins as a clock that the other end can sync with everything is fine. Timing sensitive stuff, not so much.

None of this was helped by the internal ftdi_convert_baudrate in the previous versions of libftdi I was using producing invalid divisors. I've not checked the current release, but some of my previous code has a complete re-implementation of this function as well as a way to send the divisor direct to the chip using libusb to allow me to circumvent libftdi in this area.

When debugging anything with these, if you have a couple of spare pins available it's worth configuring them as BitBang_RD# and BitBang_WR# as those give you a good reference point for the scope and show something of what the chip is doing internally.

There's now an FT232H available that's basically a single channel version of the FT2232H. I'd always thought the 2232's and 4232's were overpriced and you rarely need the multiple channels. The 232H has the interesting features like the MPSSE that weren't previously available on the likes of the FT232RL while managing to be cheaper than both.

My current project using an FT230X as a USB/GPIO expander:

[View:/resized-image/__size/589x428/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-2ebbaa5d-3a7e-4744-baa1-d950963a3a80/contentimage_5F00_175687.jpg:589:428]