10
\$\begingroup\$

In the USB-UART ICs field the best known warrior-with-counterfeit is FTDI with the FTDIgate-2014 and FTDIgate2.0-2016.

Do other vendors (like SiLabs, Prolific, Microchip, Cypress, MaxLinear or Nanjing Qinheng (CH340)) do such things that have been widely publicized?

\$\endgroup\$
5
  • \$\begingroup\$ "...that have been widely publicized?" - One would hope that if they did such a thing they would publicize it widely, because to not do so would be very stupid. \$\endgroup\$ Jan 24, 2023 at 18:22
  • 2
    \$\begingroup\$ The thing that made FTDI’s BS such big news items was that they actively damaged or destroyed hardware with those moves (and they actually tried to push that crap into the Linux kernel as well and got laughed off the stage by the maintainers, which is actually why I know about all of this). Simply choosing not to work with known bogus hardware is relatively normal, and doesn’t generally make the news. \$\endgroup\$ Jan 24, 2023 at 21:20
  • \$\begingroup\$ Moreover, the whole reason this issue exists is Microsoft's badly outdated (and misaligned with USB) driver model of having drivers for specific vendors rather than device classes, supporting a legacy cottage industry of "driver development houses" that just slap a new vendor ID on their driver code for an existing device class, push it to Windows Update channels, and charge $20k-50k a pop for the service (and for each update). On other operating systems, USB drivers like this have absolutely nothing to do with vendors. \$\endgroup\$ Jan 25, 2023 at 5:24
  • \$\begingroup\$ @AustinHemmelgarn I'd suggest that it's arguable whether FTDI's countermeasure damaged any chips. What they actually did was overwrite the vid:pid identifier in the counterfeit EEPROM: and that vid:pid had been explicitly allocated to FTDI (by a trade body that they paid to be a member of) so the counterfeit had absolutely no right to be using it. \$\endgroup\$ Jan 25, 2023 at 7:58
  • \$\begingroup\$ MS does have drivers for classes in a number of cases (for example HID and mass storage), but a generic USB to serial driver never became a thing on windows, perhaps because USB to serial kinda goes against the whole idea USB is supposed to represent. \$\endgroup\$ Jan 25, 2023 at 14:47

2 Answers 2

11
\$\begingroup\$

Prolific did, we ended up holding some "PL2302" USB-RS232 cables that were "Linux only" around 2010 some time, the windows driver didn't try to break the chip.

I recall Silicon Labs complaining about counterfeits, but never encountered any.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ I also have an old "PL2302" cable that works with the Windows driver 3.3.2.105 dated end of 2008, but the device manager shows "THIS IS NOT PROLIFIC" as device name and the device doesn't work with the driver distributed via Windows Update today. \$\endgroup\$ Jan 25, 2023 at 6:57
  • \$\begingroup\$ Chips badged Prolific were notorious for this: apparently they were being emulated by a generic microcontroller and in some cases didn't even have the right pinout. eevblog.com/forum/reviews/… \$\endgroup\$ Jan 25, 2023 at 7:54
8
\$\begingroup\$

The question is certainly of historical interest but of little current relevance. It’s troublesome to design for anything but standard USB class - CDC. Even if say FTDI may not be offering a chip for that, all you need is a small cheap microcontroller with built-in USB peripheral to act as a bridge.

In practice, a Teensy will do, either as a complete module, or just the MCU programmed with code that uses Teensy[duino] core libraries. Making a serial-to-USB bridge that way involves a paragraph or two of code to set things up and that’s it. Teensy libraries work with more chip variants than just the exact ones on the Teensy boards. There are of course other open source libraries that work across many chips, like, say, tinyusb. I just found Teensyduino libs to be a “no-brainer” of sorts.

There are Arduino boards out there that use a separate tiny microcontroller as a serial-USB bridge - it's cheaper and less cumbersome for everyone than dealing with USB-to-serial bridges. A CDC class is nowadays driver-less and works on just about everything but iOS (sad face).

\$\endgroup\$
1
  • 4
    \$\begingroup\$ I'll add more - most USB capable MCUs have a CDC example from the vendor. Transforming that example into a USB-serial bridge is, usually, relatively trivial. \$\endgroup\$
    – jaskij
    Jan 24, 2023 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.