FTDI are a company known for producing chips for USB applications. Most of us have a few USB-to serial adapters kicking about, and the vast majority of them run on FTDI hardware (or, if we’re honest, counterfeit copies). However, FTDI’s hardware has a whole lot more to offer, and [jayben] is here to show us all how to take advantage of it using Python.
FTDI’s chips have varying capabilities, but most can do more than just acting as a USB-connected COM port. It’s possible to use the chips for SPI, I2C, or even bitbanging operation. [jayben] has done the hard work of identifying the best drivers to use depending on your operating system, and then gone a step further to demonstrate example code for sending data over these various interfaces. The article not only covers code, but also shows oscilloscope traces of output, giving readers a strong understanding of what should be happening if everything’s operating as it should. The series rounds out with a primer on how to use FTDI hardware to speak the SWD protocol to ARM devices for advanced debugging use.
It’s a great primer on how to work effectively with these useful chips, and we imagine there will be plenty of hackers out there that will find great use to this information. Of course, it’s important to always be careful when sourcing your hardware as FTDI drivers don’t take kindly to fake chips.
Well it is a start.Now I have two boards to buzz Adafruit about. One shown there and one other.
ftdi does not exist, as far as I’m concerned. they’re dead, to me.
yes, they were good chips, but we all know how shitty that company is. untrustable. full stop. I see no need to engage people _more_ with their chips.
There are cheaper alternatives anyway now. No one ever need design in an ftdi serial chip again.
Alternatives? Please tell me more
After their their willingness to fuck people over with their drivers has been shown, I will never, ever use or source FTDI of any kind ever again.
“Driver controversy
On 29 September 2014, FTDI released an updated version of their USB-to-Serial driver for Windows on their website. Users who manually downloaded the new drivers reported problems. After Windows drivers became available on 14 October (Patch Tuesday) via Windows Update, it was reported by users of hardware enthusiast forums and websites that the drivers could soft brick counterfeit and software-compatible clones of the chips by changing their USB “Product ID” to “0000”. The change prevents the chip from being recognized by drivers of any OS, effectively making them inoperable unless the product ID is changed back. The behaviour was supported by a notice in the drivers’ end user license agreement, which warned that use of the drivers with non-genuine FTDI products would “irretrievably damage” them. Critics felt that FTDI’s actions were unethical, considering that users may be unaware that their chips were counterfeit, or that Windows had automatically installed a driver meant to disable them. On 22 October 2014, an emergency patch was made to the FTDI drivers in the Linux kernel to recognize devices with the “0000” ID.
On 24 October 2014, in response to the criticism, FTDI withdrew the driver and admitted that the measure was intended to protect its intellectual property and encourage users to purchase genuine FTDI products. The company also stated that it was working to create an updated driver which would notify users of non-genuine FTDI products in a “non-invasive” manner.
In February 2016, it was reported that FTDI had published another driver on Windows Update with DRM components intended to block non-genuine products. This time, the driver will communicate with affected devices, but all transmitted and received data is replaced with the arbitrary, looped ASCII string “NON GENUINE DEVICE FOUND!”, which could cause irregular interactions with devices. ”
Ironic moniker since in a way since “untrustworthy” hardware is how this mess arose. If there’s any kind of lesson it’s don’t go into manufacturing. If the counterfeits and fakes don’t get you. The “customers” most certainly will.
Even the US military isn’t free from counterfeits sneaking into their supply line.
So no surprise people are enacting a scorched earth policy regarding FTDI when FTDI does a knee-jerk reaction to a problem that puts customers at a even greater disadvantage with existing products in use.
Some sectors of the military are, indeed, finding counterfeits parts and materials in their supply chains. Flight hardware, or anything that touches flight hardware, must be procured from the OEM/OCM or dealers directly franchised by the OEM/OCM, at least where I work. It is a constant battle and as programs and customers try to drive down cost and move to COTS parts; the risk of finding counterfeits increases exponentially in the COTS market.
What no one here or in the referenced column from 2016 apparently sees is that counterfeit FTDI chips are no different than a $20 Rolex someone bought from an unscrupulous street vendor in NYC. THEY ARE ILLEGAL COPIES, and the maker community is fueling the fire when they look for cheap alternatives to more costly parts to feed their demands for technology.
If a fake FTDI chip is used in hardware where the emission of magic blue smoke causes harm to a person or property, FTDI can be held financially liable if the fault is traced to their part. In the military sector, any company knowingly using a counterfeit part in hardware is potentially liable for the full cost of any failure. Many years ago I mentored a small company on procurement of high-reliability parts. I showed them that the failure of a counterfeit $36 transistor they could but did not detect could easily cost them more than their gross income for a year (well over $10 million dollars). This is due to contractual flow downs by the US Government via the DFARS 252.246 (look it up) regarding counterfeit parts.
What FTDI did was brilliant – unfortunately, the ignorant purchasers of counterfeit hardware are not willing to admit they were fooled or made a mistake. Instead of going after the real crooks, they’re going after the legitimate manufacturer instead.
I get it, not all makers have deep pockets and tinkering in technology is expensive, I used to pull project parts from old scraped computer boards and I recently completed a personal project using wire I pulled from a wire harness from a broken circa 1985 VHS tape player. But the maker community needs to understand that it is contributing to the problem by buying exceptionally cheap (and possibly counterfeited) parts and products. Ganging up on “Evil Corp” for protecting their intellectual property is wrong. Ignorantly buying counterfeit parts is one thing, but I have seen before where a maker claims to have gotten multiple, likely counterfeit, items off of EBAY or ALI Express for less than the cost of a single known manufacturer’s part, and is willing to throw one or two away “because it is still a better deal”. This is morally, if not legally wrong! Complain all you want – but shut up when you find out counterfeit parts in your hardware has been sending your own personal information to hackers in another country and it’s used to steal from YOU.
Clearly some makers would rather feed the fakers than feed the creators of the technology they enjoy when price is concerned. That’s their choice (legal or otherwise). And quite honestly, it’s not all that bad. All that failed counterfeit hardware left on the curb is an awesome resource for penny pinched makers. Of course it’s illegal to curb your hardware in many cities and a lot of that recycled hardware goes to China and a host of other countries where those same parts we want are pulled from the hardware, “cleaned up” and sold back to us as new. Just remember price is not the same as cost and the community is going to get hit with the real cost one day!
+100
You should learn what your talking about before you talk through your butt. The reason why they did that was because so many companies were cloning their IP. So if you chose to buy a product from a cheap source and got one of these cloned chips and the new driver killed it then you deserve it. I agree with them and what they did
Excuse me? That’s over and done with and so last decade. As it happens I’m afraid you both are part of the minority. Me unless hardware was designed around something else, that’s what I will consistently use.
It most definitely is not “over”, not so long as engineers like myself work for companies that actually take our recommendations seriously and switch to alternate hardware as and when we suggest. For me personally it isn’t about revenge or even how shitty and unethical they are (a fact that’s already been well-established), it’s about the practical realities of global supply chains, the fact that it’s impossible to guarantee that every unit you buy is exactly the product that you think it is, and the readiness of that particular company to screw over our customers (and therefore us) despite our taking every reasonable precaution.
If you got hit by the FTDI driver, you were not their customer since the driver never caused problems with the original chips.
And if you cannot guarantee that you are getting quality parts I hope your company doesn’t make anything where people can get killed if fake parts get into the supply chain and cause failures.
I for myself would prefer to find out during tests before shipping that I got bad parts than having them fail in the field later. So you should welcome their driver since it gives you a tool to find out before shipping devices with fake parts.
How does that argument apply to the all the devices that were already out in the field when they released that driver? Or current clones that we think are ok because they’ve figured out how to circumvent that issue, only to be hit the next time FTDI do something like that?
With all due respect, this isn’t 1977, and your comment doesn’t accurately reflect how much of the world’s manufacturing is done these days. Case in point: my job involves developing check-in systems for a number of major international airlines (check-in kiosks, gates, biometrics etc, that kinda stuff). The airlines don’t develop these themselves of course, they contract certain international airports to do it for them. The airports have business arrangements with intermediate companies that specialize in delivering these kinds of systems, but even they don’t know the first thing about hardware so they sub-contract it out to companies like us. This is where the fun starts, because requirements are constantly changing. So we don’t just offer a system with one set of hardware, we offer a range for clients to choose from. Some of it is more functional, some of it is more secure, some is cheaper, some is more readily available…the permutations are endless. We couldn’t possibly hope to manufacture these devices ourselves so we buy them from vendors all over the world. Each of those vendors, in turn, likely subcontract out to other companies for design, manufacturing…even software. At some point somewhere along this chain someone eventually sources and purchases FTDI chips and then arranges for them to be sent to manufacturing for actual assembly, hoping all along that out of the many people involved in this process all across the world (including the PCB fab houses themselves) nobody surreptitiously substitutes them for fakes and sells them on for a profit. So when FTDI pull a stunt like the one they did, who do you think pays the real price for it? Answer: the passengers who are flying with the airlines I mentioned in step 1, when all of a sudden a bunch of airport scanners stop working and they miss a connecting flight because everyone has to be checked-in manually for a few days. Every single company down the chain then cops one in the backside as a result of something they had nothing to do with.
That’s an example for a single FTDI chip. Now multiply that out by the hundreds of chips that are installed inside hundreds, if not thousands of units we have in production….any one of which could be a fake that slipped into the supply chain. Do you seriously think a small company like us can track all that and still stay competitive?
This isn’t about the scourge of piracy, which is a very real problem that needs addressing, if for no other reason than QA. No, this is about the disgracefully unethical (and possibly illegal) actions of a company that should have at least said “Our drivers are going to disable counterfeit chips on this particular day, here are a couple of utilities you can run to confirm that yours are genuine. Do what you must, you have been warned.”
I agree that would have been nice. Their second driver did that, it put a message into the system log and send out a message on the serial side that told you that the chip is fake. They should have done that from the start, would have caused much less of an uproar
There is still the problem that you could also get hit with a fake part that seems to work OK and then fails a few months later or under certain environmental conditions. So the main issue is still to work on getting real parts and go after people who sell fake parts.
Sending garbage data down the line has the same effect: there’s not necessarily any human eyes to see it, and the system simply fails inexplicably. One way or another, you’re bricking the device intentionally.
It’s possible even a genuine FTDI chip is identified as fake due to a manufacturing error or corrupt flash etc. which doesn’t hurt the actual operation as long as nobody checks that particular bit. So what they really have done is plant a bunch of random mines in paying customers’ products. You should never ever do that.
@MarkF Very good points. I actually had issues with some FTDI chips due to the drivers issue and ended up contacting FTDI in the USA directly. After a few emails and two phone calls with their engineers, I ended up with the following realization: even they cannot tell apart the clones from the real ones when the clones are done well enough without actually opening the package! If that alone is not an issue enough to be distrustful, I don’t know what is.
Also, at many points in time less caring vendors do poison known reliable/authorized supply chains for “easy profit” and therefore there’s not much you can do in advance until you realize you ended up with some counterfeit parts and sometimes only after multiple driver updates from FTDI to “help you” realize it… :|
@RBSCHARETTE: Exactly. It is surprising, how little control you have about the sourcing of your parts. It is a horror that only people who handle multi level BOMs on a daily basis might fully comprehend.
+1 to Gerrit.
People knew, or chose to ignore, their chips where fake. Then later seek to find excuses to complain about the manufacturer.
It is like buying a cell phone from a shady guy in a back alley, then complaining about the manufacturer when said phone is remotely disabled and stops working.
But as always, there are people that find fdti is right, and those that find they are wrong. Just move on, keep hacking and find other chips that work correctly and suits your applications.
Counterfeiting and fakes will be taken seriously when people start dying, in large quantities. Apparently the regular “fakes are bad, m’kay” isn’t working.
Actually, no. It’s like getting a Christmas present, which unbeknownst to you is counterfeit. You then returned said gift at the supposedly salesperson, only to be later on charged with fraud.
I am in a similar position like MarkF and to make an already long story short: There are countless steps in a product’s life which are out of your control.
Everything I or my company designs is only uses original manufacturer order codes of course. But we manufacture ourselves. If the company that we subcontract for fab work decides to cut corners, we are boned. Of course legally speaking we are in the clear, but our OEM customers wont be happy.
Most of the time you will never see that “shady guy” yourself.
You and Gerrit have clearly never worked in any engineering or manufacturing capacity if you view the situation like that…
@bigbob,
We probably have.
And the point is not if it is inevitable or not for supply lines to be compromised.
People know that what they buy from China & friends has a very high chance of being counterfeit or at least sub-quality parts.
The recurrent point everytime that this “blame ftdi” things appear in the click-baits is that people try to shift the blame for their bad purchases to ftdi, and not recognize that the thing valued at $10 that they bought for $1 was counterfeit and that they shouldn´t have bought it.
In a real production line / product ? Probably curse a little, then try to find ways to mitigate the possible problems, while we try to search why the fakes got into the product. It it was chips we bought ourselves, then why aren´t they original. If it was in an assembly by a subcontractor, then this subcontractor will need to answer some questions also. But the blame is not in ftdi. They didn´t sell us the parts.
It’s not OK for retreating armies to poison wells. It may be war, but there are basic standards, and minimising innocent casualties is one of them.
PyFTDI is way nicer than any of the MPSSE-based libs IMO. It’s pure Python (doesn’t use libftdi) and tends to be way easier to use.
Is it as fast? The MPSSE stuff can be really speedy.
It’s pretty fast in my experience. It’s still driving the MPSSE core in the hardware, so all of the real time sensitive stuff happens on the chip. PyFTDI is more of an interface for setting up MPSSE and controlling it. Other nice thing is that it implements some easy to use protocols on top- it has easy to use interfaces for i2c and SPI. I can get better data rates for SPI in PyFTDI than I can with my old Bus Pirate, so it’s at least doing a reasonable job, though I haven’t compared it to using e.g. libftdi in C.
I use the *232H chips a lot, as both a better-in-many-ways Bus Pirate and also recently as a protocol bridge in a more involved embedded project. I played with some of the other Python libraries for them that were wrappers for C libraries and they weren’t very reliable, lots of crashes and hangs, as well as conflicts with the Linux kernel module. PyFTDI is nice and stable, plus being pure Python and in userspace means no kernel module juggling. It’s also easier to extend, which I ended up having to do to support some non-standard behavior in a sensor I was using.
PS: PyFTDI talks directly to the device through libusb, so it’s also a lot less opaque.
Fuck FTDI. They can all climb a volcano and jump straight in. Either way, I won’t give them a single penny.
There is no reason to give any positive publicity fot ftdi. For hackers and hardware developers best thumb of rule is that do not never ever use FTDI chips in your designs. Reason for that is simple. User (or even you) cannot verify that is that chip genuine. And FTDI has prooven that they are willing to go war with counterfits even customers are middle of crossfire. So each FTDI based design is lottery ticket and risk for customer. Just do not use FTDI and wold is better place.
There is no reason to tell others what to do!
Just list the facts and let everyone decide on his own.
Yes, you can check, their latest driver will put a message into the system log if it finds a fake chip and also sends out a message stating that on the serial side.
Sending garbage data into the users’ system has the same effect of tying together the shoelaces of people who have purchased “Adibas” shoes by accident. You’re not justified to break noses to protect your brand.
By your metric, FTDI shouldn’t do anything and just try to use the fak chip as best as possible so you are not inconvenienced in any way. I, on the other side, would rather know that I have a fake chip on the board. If it puts an entry into the syslog and sends garbage or nothing at all, I will find out when testing the assembled product. If it only puts an entry in syslog, but works otherwise, people will ignore that entry, after all it works.
You need to realize, you bought a FAKE chip, you have no idea how well it works and if, if it will still do that in a month or under other environmental conditions. The maker had no incentive to produce a quality product. You need to find out as quickly as possible that you have a problem with your supply chain.
I had the worst time getting the Adafruit FT232H to work. Mainly because I insisted on using Python 3 and Windows. But I did it: https://docs.google.com/document/d/1AtMxzLVzCJ6gkE9xBPYgOlKElqU9c49QfcXxScbAgb8/edit
There is open source debug tool jtag-lock-pick based on ft2232 and some buffers where you can have JTAG, SWD, UART and real RS232 on single usb device. FT2232 has a nice feature of using 2 serial ports with different configuration simultaenously
I use an FT2232 breakout board (with onboard config EEPROM — important) as a do-everything interface too. SWD and UART make it an all-purpose ARM debugger, and it works with OpenOCD when you need to JTAG.
It supposedly speaks full-speed SPI and I2C too, but I’ve never had to use those. I always just hoke something up ad-hoc with a microcontroller.
Just curious, how this ( and solutions using libftdi ) work with applications that expect a somewhat constant clock ?The dll overheads and calling functions should affect clock stability, shouldn´t they ?