[nanolith]

I could spot the clone because I'm familiar with the form factor of the FTDI IC, and I'm familiar enough with the datasheet to spot the expected passives.

I'm not too keen these days with FTDI's reputation for manipulating their Windows device drivers to brick clones. So, while I'm familiar with their IC, I don't give them any more money. The next time I need a USB to serial cable, I'll bust out KiCad to build it using one of the ubiquitous ARM microcontrollers with USB features built in. Of course, this is easier for me, since I can write my own Linux or BSD device driver as well. Those using OSes with signing restrictions on drivers would have a harder time, unless they chose to disable driver signing.

[the_biot]

I think that's what happened here. I spotted the fake because it has a large number of unused pins, which would not be the case with an FTDI chip that was literally made for this.

I think it's just some generic microcontroller emulating FTDI's protocol in software, but it can't keep up with high-speed transfers of course, and that's how they noticed there was a problem.

[Liftyee]

It helps that USB to serial is a solved problem. Plenty of manufacturers make parts that work well and don't need to try and imitate FTDI.

[LiamPowell]

You don't actually need your own driver, you can just use the CDC device class.

[nanolith]

That's true. The only advantage of writing a driver in this case is if I wanted to add functions, such as a programmable level shifter.