If you are using an FT232 for USB-to-serial in your project, watch out. If you have a fake chip it could be irreversibly damaged by the latest official FTDI driver. Although someone in the linked thread claims that it is fixable.
If you are looking for an alternative chip, there is the Prolific PL2303, the Silicon Labs CP21xx series, the Texas Instruments TUSB3410, and the Microchip MCP2200. You can also use a microcontroller with built-in USB support, such as the Atmel AVR AT90USB162, or the ATmega8u2.
I recommend using a chip (or using a microcontroller USB stack) that supports the USB CDC class, because the CDC class does not require special drivers to get serial working on most operating systems.
This is appalling behaviour on FTDI’s part - I consider it vigilante justice. Consumers are the ones who will be bitten, and are too far from the source of the problem and in many cases have no way of knowing if some particular product they have even contains a FTDI part let alone if it’s genuine or not. They’re clones; even visually inspecting the devices won’t let on if they’re genuine or not. It’s almost impossible for small-time manufacturers to guarantee that the parts they’re putting in their devices really are genuine at times (hell, if even the US air force can’t for Air Force One, how can we?).
Summary of the issue for everyone
If you have Windows set to automatically install updates (the default), Windows Update will silently install the FTIDI driver version 2.12.00, which will semi-permanently destroy any device using a clone chip that is plugged into your computer (at which point the device will be unusable even on other computers or older drivers - so it’s too late). Windows will also search Windows Update for a new driver if you plug a FTDI device into a different USB port to what it was plugged into previously.
You will likely be affected by this if you have bought Arduinos (especially off-brand, but sometimes those are resold as ‘official’) or similar from eBay, AliExpress, or many smaller retailers - online or physical. Who knows what consumer goods you own that could also be affected.
Of course you also still need to make sure the malwareified drivers aren’t loaded again next time, or on any computer you ever plug the dongle into, lest you end up in this situation again.
Not many consumers could diagnose the issue, let alone follow the instructions to unbrick under Windows or Linux (if they even had a Linux install to use).
The one saving grace of all this is that due to FTDI’s high price-point, relatively few mass-production/consumer devices actually use their chips - so it’ll mainly impact the hobbyist community (us, boo). It’s unfortunate as companies like Arduino have put so much effort into making the process of starting with embedded development painless for beginners, and those are the people that FTDI will be hurting the most with this.
Personally, this is just driving home that it’s a good choice to go with a real USB implementation rather than a USB-to-serial bridge. Looking around, there’s actually been big improvements on Windows in the last couple of years to make the installation of non-HID/mass-storage USB devices invisible and true plug-n-play. Yay!
I’m probably missing something here because I’ve never designed a board with USB on it, but perhaps the root cause of the problem is not FTDI or the counterfeiters, but rather the USB-IF?
Richard is right that this chip is popular with hobbyists and makers, but I’m guessing that a large part of that is because FTDI is one of a handful of companies that will let you use their USB vendor ID for small production runs. To get your own costs a minimum of US$5000, which makes it tricky to get into the USB peripheral business.
If USB had a standardized driver spec that covered the functionality in the FTDI driver and common operating systems came with that spec implemented generically, anyone could build USB compatible peripherals. As it is, you have to choose between stepping on someone else’s IP or spending a bunch of money licensing a two-byte number (woohoo, 6001!) and writing yet another driver that does the same thing as everyone else’s.
What I mean is a standardized spec that includes generic VID/PID values. There’s no reason the designers of the USB spec couldn’t have worked around that requirement; you don’t need $5000 numbers for serial port or ethernet devices.
We use FTDI in one product, glad we designed our own now rather than buying the cheap ebay ones and sticking our own cable on it, I told the boss it would work out better for - looks like it did. Everything is ARM for us now though, so we only need that for the legacy product then no more uarts
I wont be using FTDI any more, the boss wanted FTDI because of it’s reputation, i wanted microchip or siliconix because of price… guess his argument has gone.
In the past I avoided FTDI in my designs, but often bought devices with FTDI chips in them.
I doubt I will be buying devices with FTDI chips in the future. First because it takes effort on my part to verify that the chips are not going to be effected by malicious firmware updates. Second I don’t trust a company that creates a firmware update that maliciously attacks others chips.
@bruce: A number of vendors will allocate you a PID from their VID if you’re using their IC’s (Atmel and Microchip do from memory, but I seem to remember something about ST not being so generous unfortunately) - it’s the only sub-allocation allowed by the USB-IF.
