Lattice - FTDI chips for Breakout boards etc, can those be tweaked ?

[Brane212]

After repairing one of my Breakout boards, I couldn't help noticing, that:

That FTDI thing has 2 channels and each channel has several modes.
One channel is presently unused, but it has beeen configured as UART and there are 0-ohm place holders to connect those lines to FPGA.

As far as I can see, linux immediately sees both UARTs.

This thing could be usefull for debugging, but it is PITA to instantiate whole UART just for debug and/or data acquisition.

BUt FTDI offers parallel modes that are far faster and demand less internal logic in FPGA.

Questions:

1. Is there some good reason against implementing DIY lattice programmer with this thing ? Schematics is simple, chip is not that expensive ($6) and as far as I can tell, Diamond does check ID of the connected FPGA before programing, so this could probrably work with any FPGA. DIamond ISP tool is expensive and it doesn't offer that extra channel. Plus, if I manage to burn it I can only use it as an anal probe afterwards, while this FTDI thing looks very serviceable.

2. Is there someone with enough experience to explain whole thing and untangle the web of needed options, drivers and modules and to explain what do do with it and how ?

[Kilrah]

What model is "that FTDI thing"? Did you look at the datasheert and/or looked at it in FT-Prog to see if it does have modes that make it easier for you?

[Brane212]

FT2232H.

I've checked datasheet,yes. That's why I have asked, after seeing what the chip is capable of.

[Brane212]

I guess what I need to know is how would I see those ports on Linux, what kind of drivers I need to setup ( whether in-kernel ones or something spcial from FTDI etc).

[Kilrah]

Probably need to use their D2XX drivers and API.
http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf

[andersm]

Under Linux you'd preferrably use libFTDI.

[Brane212]

Thanks, but that seems like too much of a haslle for FTDI.

I liked it at first, because with ftdi_sio driver you'd get two /dev/ttyUSBx ports just by plugging the damn thing into USB.  Sending the data to such port and syphoning it out of "terminal" seemed like a trivial shell hack.

I hoped that FTDI made such kernel module for other modes, so one could just plop the thing in and automagically get a device.

If I have to f**k around with libFTDI etc, then I'm better off using libusb and USB microcontroller.

[Kilrah]

The UART mode is easy because it's been a standard for years, that... emulates a standard that's been there for decades.

All the other modes are generic, i.e. they're a way to transfer data from A to B but there's no standard way or protocol to use with them, so no standard way to expose them either. You can do what you want with it, but that means you must define and implement the whole chain to your spec.

An UART in the FPGA to work with the standard serial port is a tiny piece of cake, anything you would want to do on the PC will be a lot more complicated.

[Brane212]

Why ? Suppose you do FIFO--thing.

All FPGA has to do is to generate strobes or CLK and those 8 bits of data per transfer one way or another.

With simple kerne driver,say (ftdi_fifo), I could get device /dev/ftdi_fifo. Reading from device would generate read cycles, writing into it would generate write cycles.

Voila.

All that is needed on FPGA side could be as simple as a few registers and selection logic, all that is needed on PC side, can be a simple few lines of bash.

[ale500]

The uart mode is not that bad. You can use 500 kbps or 1 Mbps or 2 Mbps, you don't need 115200 or some other funky baud rate, a very simple shift-register UART fits in like 17 Slices, only the transmitter . If you find how to use the FIFO mode... that would be awesome !

[Brane212]

The uart mode is not that bad. You can use 500 kbps or 1 Mbps or 2 Mbps, you don't need 115200 or some other funky baud rate, a very simple shift-register UART fits in like 17 Slices, only the transmitter . If you find how to use the FIFO mode... that would be awesome !

That would be semi-acceptable, if one would not be required to remove ftdi kernel module for programming to work.

So I am supposed to rename modulee ( so that kernel does not find it at device plugin), do my programming, then unplug the device, rename module back again, do depmod -a and plug the board back in. This would drive me insane...

[Kilrah]

Why? Someone actually posted as simple udev rule I think yesterday to automatically disconnect the device so that it's free for you to use, while the 2nd channel is happily bound to the ftdi kernel module to provide UART comms.

[mikeselectricstuff]

The uart mode is not that bad. You can use 500 kbps or 1 Mbps or 2 Mbps, you don't need 115200 or some other funky baud rate, a very simple shift-register UART fits in like 17 Slices, only the transmitter . If you find how to use the FIFO mode... that would be awesome !

From memory I think the FT2232H goes to 12Mbaud, certainly does 6M

[janoc]

The uart mode is not that bad. You can use 500 kbps or 1 Mbps or 2 Mbps, you don't need 115200 or some other funky baud rate, a very simple shift-register UART fits in like 17 Slices, only the transmitter . If you find how to use the FIFO mode... that would be awesome !

That would be semi-acceptable, if one would not be required to remove ftdi kernel module for programming to work.

So I am supposed to rename modulee ( so that kernel does not find it at device plugin), do my programming, then unplug the device, rename module back again, do depmod -a and plug the board back in. This would drive me insane...

You don't need to do anything like that. You can tell Linux to temporarily disconnect a driver from the device - e.g. see here: https://lwn.net/Articles/143397/ Then when you are done, just replug the board or powercycle it - the driver will load back again.

However, to program the FTDI bridges you do not need to disable the UART driver. Just use the libftdi or the official FTDI's library to program the mode you want - the library will handle all the driver issues for you. Correction - what happens is that if you reprogram the FTDI to not act as an UART but e.g. I2C, SPI or JTAG bridge, the driver will detach automatically because the device reports a different descriptor now.

You may have to do it manually if you want to bitbang some pins - either do it as described in the article above, or using libusb and the libusb_detach_kernel_driver() function. However, even then most likely nothing bad will happen unless you try to bitbang the pins used by the UART functionality. You will get at best a warning from the system about not claiming the interface correctly.

There is even a pre-made tool for it:
https://github.com/Lefinnois/USBdetach

I have used exactly the same FT2232H as an USB to I2C bridge recently through these libraries. No problem whatsoever. Also OpenOCD uses these extra modes to drive the various FTDI based JTAG dongles.