FTDIgate 2.0?

[boffin]

Maybe damage control is on the way.  There's an upcoming interview between FTDI and Adafruit
https://blog.adafruit.com/2016/02/04/comingsoon-an-interview-with-fred-dart-ceo-of-ftdi-ftdichip-ftdi/

[c4757p]

Given what I've seen before, I expect they'll use this interview as a chance not for damage control, but to dig their hole even deeper. They seem to have a thing for, ahem, deep holes.

[marcan]

BTW, regarding the quality of their IP: I just tested the SPI mode of the FT2232H with their sample application for the D2XX driver and the SPI_ReadWrite function (with SPI_TRANSFER_OPTIONS_CHIPSELECT_ENABLE and SPI_TRANSFER_OPTIONS_CHIPSELECT_DISABLE, the only modification I made is to transfer 2 bytes). This is how it looks like:

FT232R. That was supposed to be a square wave, in bitbang mode. Turns out their clocking is, well.... yeah.

I wonder if the clone chip supports bitbang mode, and if it does, if it works any better.

[marcan]

Oh, this is pure gold.

FT232R, clone vs. original, outputting a 38kHz square wave in bitbang mode, same exact code driving both.



Original at the top, clone at the bottom.

Turns out the clone chips are actually better at following FTDI's own spec (and actually being useful in bitbang mode) than the original, buggy silicon.

Now where can I get a distributor that guarantees they will supply the superior clone chips? I don't want to give FTDI any money, and these things are actually useful in bitbang mode, unlike FTDI's junk.

[mtdoc]

Oh, this is pure gold.

FT232R, clone vs. original, outputting a 38kHz square wave in bitbang mode, same exact code driving both.



Original at the top, clone at the bottom.

Turns out the clone chips are actually better at following FTDI's own spec (and actually being useful in bitbang mode) than the original, buggy silicon.

Now where can I get a distributor that guarantees they will supply the superior clone chips? I don't want to give FTDI any money, and these things are actually useful in bitbang mode, unlike FTDI's junk.

That's funny.

Now their CEO is devoting time and energy doing interviews? - not a good sign.

I think it's becoming increasingly obvious that FTDI's problem is not cloners, it is FTDI.

Perhaps clone chip makers should just write their own driver and start marketing their chips as a cheaper, better, FTDI pin compatible alternative?  They could  brand them FDTI (at least that would be more honest and not illegal)....

[mikerj]

That's your opinion and the opinion of some others, mostly hobbyists who got burned by buying cheap (Chinese) products.
In a professional environment, this plays no role, apart from the fact that you have to check your sources, but a professional
already did that.

And what about the end user who has no choice in whether a genuine FTDI device was used or not?

Aim your anger to the counterfeiters, not to a a company that tries to protect their investment by not supporting
counterfeit chips with their driver. There's nothing wrong with sending the string "this is not a genuine chip" when counterfeit
is detected.

How can you possibly know that?  Can you personally guarantee that no device using an FTDI chip exists that doesn't do something bad or unexpected when that string is sent to it?  Of course you can't.  Sending that string back to the calling application at the PC end is one thing (though still stupid), but sending it to the embedded device using the FDTI chip shows a monumental level of stupidity.

[f4eru]

In a professional environment, this plays no role, apart from the fact that you have to check your sources, but a professional
already did that.

Wrong. Even professionals who check their sources get bitten. Why ? because often, they put high pressure on prices, so the source, or the source of the source of the source gets it where it's cheap. You get what you pay for, and this is the norm in Asia.

There's nothing wrong with sending the string "this is not a genuine chip" when counterfeit is detected.

Wrong and wrong.
1) They don't detect counterfeits. They detect non FTDI chips. It could be a legitimate compatible chip, a clone, a grey market FTDI silicon, or a counterfeit.
2) There's something wrong with corrupting user data. A driver should NEVER maliciously corrupt user data. If an error pops up, it should use the legitimate error channels instead (closing the port, popping up an error message, etc...).

[Karel]

That's your opinion and the opinion of some others, mostly hobbyists who got burned by buying cheap (Chinese) products.
In a professional environment, this plays no role, apart from the fact that you have to check your sources, but a professional
already did that.

And what about the end user who has no choice in whether a genuine FTDI device was used or not?

The end user puts a claim at the place where he bought it.

Aim your anger to the counterfeiters, not to a a company that tries to protect their investment by not supporting
counterfeit chips with their driver. There's nothing wrong with sending the string "this is not a genuine chip" when counterfeit
is detected.

How can you possibly know that?  Can you personally guarantee that no device using an FTDI chip exists that doesn't do something bad or unexpected when that string is sent to it?  Of course you can't.  Sending that string back to the calling application at the PC end is one thing (though still stupid), but sending it to the embedded device using the FDTI chip shows a monumental level of stupidity.

That's not the responsibility of FTDI. Every engineer that designs a possible dangerous device that uses a serial port without
any data checking protocol, is an idiot.

[Karel]

In a professional environment, this plays no role, apart from the fact that you have to check your sources, but a professional
already did that.

... because often, they put high pressure on prices, so the source, or the source of the source of the source gets it where it's cheap. You get what you pay for, and this is the norm in Asia.

You take the risk to go for cheap. You take the fame when your business goes well. You take the blame when shit happens
because of your choice to go for cheap.

There's nothing wrong with sending the string "this is not a genuine chip" when counterfeit is detected.

Wrong and wrong.
1) They don't detect counterfeits. They detect non FTDI chips. It could be a legitimate compatible chip, a clone, a grey market FTDI silicon, or a counterfeit.
2) There's something wrong with corrupting user data. A driver should NEVER maliciously corrupt user data. If an error pops up, it should use the legitimate error channels instead (closing the port, popping up an error message, etc...).

Wrong and wrong.
They do detect counterfeit chips. Show me a link to a place where I can buy a legitimate, compatible non-FTDI
chip that gets harmed by the actions of FTDI.
There's nothing wrong with sending the string "this is not a genuine chip". Counterfeiters shouldn't use somebodies elses
USB VID in order to illegally use somebodies elses driver which they have no right to.

[Karel]

Perhaps clone chip makers should just write their own driver and start marketing their chips as a cheaper, better, FTDI pin compatible alternative?  They could  brand them FDTI (at least that would be more honest and not illegal)....

They should have done that in the first place.

But probably they are not capable to write a (stable) driver, or writing it costs too much money,
or probably both...

[pickle9000]

Perhaps clone chip makers should just write their own driver and start marketing their chips as a cheaper, better, FTDI pin compatible alternative?  They could  brand them FDTI (at least that would be more honest and not illegal)....

They should have done that in the first place.

But probably they are not capable to write a (stable) driver, or writing it costs too much money,
or probably both...

Less overhead, more profit. If a programming skill was needed it could be purchased. They choose items that are profitable to copy. That means low production cost, high selling cost, and they need to pass tests.

Think about the complexity of the task design and distribution. Just getting the things on the underground market is a massive undertaking. Remember we are talking massive numbers of devices.

[Karel]

Perhaps clone chip makers should just write their own driver and start marketing their chips as a cheaper, better, FTDI pin compatible alternative?  They could  brand them FDTI (at least that would be more honest and not illegal)....

They should have done that in the first place.

But probably they are not capable to write a (stable) driver, or writing it costs too much money,
or probably both...

Less overhead, more profit. If a programming skill was needed it could be purchased. They choose items that are profitable to copy. That means low production cost, high selling cost, and they need to pass tests.

Think about the complexity of the task design and distribution. Just getting the things on the underground market is a massive undertaking. Remember we are talking massive numbers of devices.

Exactly. And FTDI whent through all of this and invested a lot of money in their driver. They have all the right to brick or sabotage counterfeit chips that abuse their driver.

[Boomerang]

The driver cannot look at the marking of the chip. Only small number of specially trained people can look at the chip, make series of tests and say "This is counterfeit for sure."

[amyk]

Oh, this is pure gold.

FT232R, clone vs. original, outputting a 38kHz square wave in bitbang mode, same exact code driving both.



Original at the top, clone at the bottom.

Turns out the clone chips are actually better at following FTDI's own spec (and actually being useful in bitbang mode) than the original, buggy silicon.

Now where can I get a distributor that guarantees they will supply the superior clone chips? I don't want to give FTDI any money, and these things are actually useful in bitbang mode, unlike FTDI's junk.

Are you sure you didn't get the two mixed up? Or perhaps they're both actually clones, but one passes the test enough to identify as genuine?

AFAIK the clones use a microcontroller whereas the genuine ones are a full ASIC. If true, funny to see the former beating the latter in timing stability... it's usually the other way around.

Karel, you might want to look up the interoperability court cases I posted - it's perfectly legal to make a clone, especially one that's completely different in terms of implementation. Even using FTDI's VID:PID is fine because it's required for interoperability. The only thing that's not is marking it with the FTDI name, and that's not something the driver can determine. In the previous long thread there was mention of COB clones, which are completely unmarked, and this one. Perhaps you work for FTDI...?

[nctnico]

Exactly. And FTDI whent through all of this and invested a lot of money in their driver. They have all the right to brick or sabotage counterfeit chips that abuse their driver.

Please seek legal counsil because your statement is wrong on so many levels!

[Karel]

Exactly. And FTDI whent through all of this and invested a lot of money in their driver. They have all the right to brick or sabotage counterfeit chips that abuse their driver.

Please seek legal counsil because your statement is wrong on so many levels!

So, soon we will see courtcases or a classaction suit against FTDI and FTDI will loose?
Go ahead and surprise me.

[rs20]

So, soon we will see courtcases or a classaction suit against FTDI and FTDI will loose?
Go ahead and surprise me.

  The victims of FTDI's vandalism can't afford legal action.

FTDI whent through all of this and invested a lot of money in their driver. They have all the right to brick or sabotage counterfeit chips that abuse their driver.

The way you think a company being the victim of counterfeiting* gives them cart blanche to do whatever petty vandalism they want is just astonishing. Schoolyard eye-for-an-eye rubbish, and not even directed at the people who did "the crime"* anyway.

* Given that you're so excited about hard evidence for everything, where is the evidence that FTDI is suffering from a significant, unusual amount of counterfeiting? A company that is perpetually out of stock doesn't really sound like it's actually struggling and maybe should be focussing on production... It's interesting to consider how many second-source (what an idiot would call "counterfeit") ICs exist out there... do you think the world would be a better place if the inventor of the first quad NAND gate started designing chips that bricked any connected quad NAND gates from second-source manufacturers? The fact that the counterfeit FTDI chips use real FTDI drivers is of zero relevance, FTDI wears zero marginal cost for having those drivers distributed by Windows Update. It seems more likely FTDI is a company dying of obsolescence (thank goodness) grasping at excuses and being petty little children about it?

[AlxDroidDev]

(...) it's perfectly legal to make a clone, especially one that's completely different in terms of implementation. Even using FTDI's VID:PID is fine because it's required for interoperability. The only thing that's not is marking it with the FTDI name, and that's not something the driver can determine. In the previous long thread there was mention of COB clones, which are completely unmarked, and this one. Perhaps you work for FTDI...?

That's exactly what I think too. If the guys making "second source" FT232s  (to use rs20's term!) hadn't branded them FTDI FT232RL, then they would be in the clear with possibly a better product and since they have a lower price, they'd have a huge demand for their chips.

It is possibly just a coincidence, but the CH340G chips appeared just around the time of FTDI Gate 1.0. I wonder if the manufacturer of the "second source" FT232 and CH are related. Neverthless, the CH340G chips possibly are taking a lot of market share of the FT232RL, since it is cheaper and as easy to implement (although it requires external crystal, which the FTDI part doesn't). I believe 99% of the Arduino clones are being shipped with the CH340G nowadays. 

And, for the FTDI fanboys out there, WCH (the manufacturer of the CH340G) also has working drivers (for Win, Linux and Mac), so that isn't a big deal. It's not like creating serial drivers for Windows requires an investment of millions of dollars.

[c4757p]

Karel, you might want to look up the interoperability court cases I posted - it's perfectly legal to make a clone, especially one that's completely different in terms of implementation. Even using FTDI's VID:PID is fine because it's required for interoperability. The only thing that's not is marking it with the FTDI name, and that's not something the driver can determine. In the previous long thread there was mention of COB clones, which are completely unmarked, and this one. Perhaps you work for FTDI...?

The fact that this will interfere with things that aren't FTDI counterfeits, just FTDI-compatibles, because, y'know, it can't read the markings on the chip, really should end this whole bloody argument. But clearly we have more sleazy businesspeople than real engineers here. Anything in the pursuit of profit...

[madires]

That's not the responsibility of FTDI. Every engineer that designs a possible dangerous device that uses a serial port without
any data checking protocol, is an idiot.

I agree on the latter, but the reality is that there are a lot of products with serial interfaces and no input validation. So it's not a non-issue.

[c4757p]

If you're writing a driver, and your number one priority isn't making devices work, you're not writing a driver. If you want to argue that clones are unpredictable and can't be trusted, then fine, refuse to operate with them, the same way my operating system's mouse driver won't even try to talk to my USB flash stick. It knows it can't. Even if the latter reported an incorrect VID/PID and it started to, it'd stop as soon as it realized something wasn't right. Start sending garbage or intentionally damaging the device and you're not an engineer, you're just a dick.

Whatever happened to engineering ethics? Here's a good example. Lots of stuff about not endangering life or property. Nothing about "when you can blame someone else for endangerment of life or property, have at it". Nothing about "don't worry about endangering life or property until you've actually seen it happen once, hypothetical hazards aren't real". I seriously hope I never end up owning a device made by some of the people here.

[Karel]

That's not the responsibility of FTDI. Every engineer that designs a possible dangerous device that uses a serial port without
any data checking protocol, is an idiot.

I agree on the latter, but the reality is that there are a lot of products with serial interfaces and no input validation. So it's not a non-issue.

It's an issue caused by incompetent or criminal engineers.

[Karel]

Whatever happened to engineering ethics?

You should ask that to the engineers who designed the counterfeit chips.

[c4757p]

Whatever happened to engineering ethics?

You should ask that to the engineers who designed the counterfeit chips.

Ahhhh, you're one of those people who think it's okay to do something unethical as long as you're doing it in response to something else unethical.

Okay, that explains this whole thread for me. Makes sense.

[suicidaleggroll]

1) They don't detect counterfeits. They detect non FTDI chips. It could be a legitimate compatible chip, a clone, a grey market FTDI silicon, or a counterfeit.

Legitimate manufacturers do not impersonate their competition by spoofing their vendor ID and product ID, in order to piggyback on a closed source, proprietary driver that they do not have permission to use.  If there are any manufacturers doing that (it would take some impressive mental gymnastics to continue calling them "legitimate" at this point), FTDI has every right to say "No", forcing those manufacturers to either write and distribute their own drivers, or obtain the permission of a different competitor and piggy back off of theirs.  What's wrong with competing on a level playing field?  FTDI is under no obligation to properly support chips they did not produce.