Author Topic: FTDIgate 2.0?  (Read 382394 times)

0 Members and 6 Guests are viewing this topic.

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: FTDIgate 2.0?
« Reply #200 on: February 01, 2016, 03:16:32 am »
Well, now it might be too specific with the loopback configuration :) I don't have a fake chip so I can't test it, but I guess it ony sends the string, and that's the main problem why the affected devices don't work anymore. But it might alter received bytes from an independent UART source, too.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: FTDIgate 2.0?
« Reply #201 on: February 01, 2016, 06:15:50 am »
Quote
Counterfeits have been found in the legitimate supply chain.
Reference?  Counterfeit FT232 devices specifically, not just "counterfeits of some chip."  Has anyone here who has a "real product" and has been buying chips from real distributors received counterfeit FTDI devices?  (No, I'm not counting Arduino-like or nth party usb/serial modules purchased from real distributors...)

Quote
hobbyist bubble
Have any non-hobbyist products been affected?   A lot of "auction site usb/serial cables", a fair number of "arduino clones and derivatives" (perhaps including genuine Arduino Nanos, and some higher-level products that USE arduino-esque boards internally (like that tinyboy 3d printer.)  (Or are we saying that arduino modules are no longer merely hobbyist devices?  Which would be an interesting development in itself!)

Quote
life support
One does hope that if you make life-support equipment, you have in fact negotiated on that "not for use in critical applications" agreement, and DO have better-than-average supply chain management AND testing.

Quote
testing and counterfeit identification
Is anyone here a large enough FTDI customer that they can categorically state that FTDI has NOT provided such a tool to their large customers?  A "counterfeit check" tool would certainly be nicer than having to run through the full driver version/windows version matrix...  I'm not sure that I'd expect it to be available to "hobbyists", though.  Or even mid-range manufacturers buying a couple thousand chips/year through Mouser/etc.

Quote
[Official FTDI distributor network sucks.]
I can agree with that.   Prior to Arduino, FTDI chips were pretty much unobtainable, except through a few odd sources.  If you wanted to use USB/Serial adapters, your best bet was an expensive USB/RS232 cable, with subsequent RS232/TTL conversion. :-(


Has anyone checked whether the new driver "malware" behaves the same with non-FTDI VID/PID ?  (Can you even change the VID/PID of the counterfeit devices?)

Has the source of the counterfeit devices ever been determined (manufacturer?  Path?)  Maybe they should just sell their own chip and do their own driver; it can't be that hard - ch340g has penetrated pretty well, to the same sorts of vendors, even though it's significantly different.

-----

I sympathize with FTDI.  I really do.  But they sure could have handled all this much better.  I too would rather have a driver that just didn't work, and plastered the "device manager" with the "counterfeit device" label, instead of bricking chips, or polluting the data stream.

I sympathize with small manufacturers.   Or I guess "designers", really.   LOTS of manufacturing below the fortune-500 is outsourced to someone, and I really wouldn't know how to go about finding someone with "good supply chain management" when I was mostly looking for "someone who's willing to deal with small volumes from a small designer."  Putting that big ???? over FTDI would not be good.   But the problem isn't unique to FTDI - they've just made it particularly obvious.  A different chip with a different clone and a more subtle problem is just as scary, right?

I even sympathize with the hobbyist ordering off auction sites.  One might expect occasional non-working merchandise.    Things that work for a while, but suddenly stop working because of a non-controllable windows update are scarier.  (although, see above about "subtle" issues.)
 

Offline marcan

  • Regular Contributor
  • *
  • Posts: 80
  • If it ain't broke I'll fix it anyway.
    • My blog
Re: FTDIgate 2.0?
« Reply #202 on: February 01, 2016, 06:34:16 am »
After the first debacle, one could argue that perhaps FTDI didn't DELIBERATELY set out to brick chips (although the the evidence was compelling).
No. One couldn't argue that. It was proven beyond any shadow of a doubt that the bricking code was single-purpose, carefully crafted, and purposefully designed to brick clone chips. Anyone who thinks there is even the slightest chance that FTDIgate v1.0 was an accident either can't read the decompiled C code that I posted or is deluding themselves. They identified a small difference in EEPROM write behavior, then worked backwards from that to find a set of commands (including a pre-image attack on their own checksum algorithm) that would be no-ops on the real chips but brick clones. There is no chance that their driver just "happens" to include code that just "happens" to do nothing on real chips but just "happens" to know how to update EEPROM data while keeping the existing checksum correct (because it so happens that updating the checksum would affect legit chips) and just "happens" to include a write PID to 0 command that just "happens" to be a no-op on real chips due to a write buffering technicality.

But yeah, at least FTDIgate v1.0 needed reverse engineering the driver to prove intent. This one they aren't even trying to hide.

Either way, these guys have proven themselves to be utter morons in handling this issue. As I said in the past, the only REASONABLE action would be to refuse to work with clone devices with a user-visible error message informing them of the problem. Bricking devices is infantile and makes them legally liable for destruction of property. Sending garbage data is even worse, it puts USERS at risk due to malfunctioning hardware (industrial controllers and medical devices anyone?) and makes them legally liable for potential destruction of property, or worse, personal harm. Do these guys even have lawyers? Seriously, this is pathetic, wrong, and ridiculous.

Seriously, no more buying FTDI for me. After the first warning I thought maaaaybe I'd give them a second chance (if only because their chips actually work properly most of the time), but at this point I'd rather deal with quirky alternative chips than give them any money.

Incidentally, I took a look at the code and empirically tested a clone device to confirm. The driver replaces all data, TX and RX (and maybe some other things like modem status even? not sure, it's in more than 2 places), with "NON GENUINE DEVICE FOUND! " looped forever. It has nothing to do with looping back TX and RX, that is just one easy way to see it (because you need data to arrive to see the message on RX). I just cross connected a clone on a Windows PC to a legit chip on a Linux machine to confirm that both directions are clobbered. It also sets a registry key for clone devices, although it doesn't seem to check it otherwise. Maybe they're planning something even nastier for the next driver version?



« Last Edit: February 01, 2016, 06:38:34 am by marcan »
 

Offline voltlog

  • Regular Contributor
  • *
  • Posts: 101
  • Country: ro
    • VoltLog
Re: FTDIgate 2.0?
« Reply #203 on: February 01, 2016, 07:09:24 am »
That's such a bad PR stunt on their end to block people on Twitter. Don't they have any PR people to handle things like this?
It looks like they haven't learned anything from their mistakes and our response should be clear, we should stop using their products.

Offline Chris Jones

  • Regular Contributor
  • *
  • Posts: 95
  • Country: au
Re: FTDIgate 2.0?
« Reply #204 on: February 01, 2016, 07:18:46 am »
....
create a version of the chip that has such a low price point, they put the cloners out of business by providing legit-working-alternatives for a price point.

If your chip designers are better than the fakers, then you can make the chips smaller and therefore cheaper than they can, (unless they directly copy the masks, which can be challenging on recent processes). If you put more wafers through the fabs (TSMC, UMC etc) than the fakers do, then you get better wafer pricing, even if they did copy your masks. Then you can sell the genuine article for less than the fakers can make it for - admittedly without making much profit per unit. I think that such a price reduction (maybe combined with a pop-up warning about detected fake devices - without impairing functionality) would have been the honourable path for FTDI, and they might have got some market share back from their legitimate competitors too.

 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: FTDIgate 2.0?
« Reply #205 on: February 01, 2016, 07:41:21 am »
Just added FTDIGate 2.0 to Wikipedia.

https://en.wikipedia.org/wiki/FTDI

No mention of any preventive measures... only punitive measures!

Some people don't learn even from their own mistakes.
 

Offline RFZTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: FTDIgate 2.0?
« Reply #206 on: February 01, 2016, 07:58:34 am »
Does anyone know the KB that rolls out this driver so I can ignore it?
As far as I know, Driver updates don't have a KB...
The driver will be installed if you plug in a FTDI device the first time, or, if you already have an older FTDI driver it will show up as normal or optional update...
 

Offline RFZTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: FTDIgate 2.0?
« Reply #207 on: February 01, 2016, 08:08:37 am »
Just added FTDIGate 2.0 to Wikipedia.

https://en.wikipedia.org/wiki/FTDI

That's all good but apparently this driver has been up since  3 July 2015 as stated in the wiki and as per:
https://www.eevblog.com/forum/microcontrollers/ftdi-gate-2-0/msg854788/#msg854788

So it's not a new discovery, many reports since then but I guess this is the first one to bring up a bigger stink about it :)

A report about the July driver can be found here:
http://electropit.com/index.php/2015/09/06/arduino-nano-v3-0-clones/

Yep, the behavior is not new... I've updated that information in my first posting right after about half an hour later when I found out that the "garbage" the driver sends actually was "NON GENUINE DEVICE FOUND!" and I did a google search on it ;) There is no FTDIgate 2.0, it was just me seeing strange behavior and not doing enough research. But who cares ^^
However, since windows update now publishes a new driver version, lots of people will be confronted with it again... So it's actually not bad to discuss this topic again, even if it's not new. FTDI deserves that bad publicity ;)
Also, to be fair, I haven't found much discussion about the driver actually sending arbitrary data to the devices. I guess after FTDIgate bricking most devices by altering the PID, most users avoided FTDI anyways and/or found way to unbrick the devices and use the old driver. Most of them, like me, may not have been aware of that a new driver with different behavior was released.
 

Offline RFZTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: FTDIgate 2.0?
« Reply #208 on: February 01, 2016, 08:13:01 am »
Is anyone here a large enough FTDI customer that they can categorically state that FTDI has NOT provided such a tool to their large customers?  A "counterfeit check" tool would certainly be nicer than having to run through the full driver version/windows version matrix...
FTDI will never do that. There is no way to guarantee that a chip is valid with a tool (at least now with chips having no cryptographic signature or similar things), you can only guarantee that it's fake. There might be fakes already that FTDI cannot identify by now, but they will be able to in the future.
What if you buy such a chip today, the tool says it is okay, and in a year all your products get bricked because FTDI was able to identify it as fake? No... that won't happen.
« Last Edit: February 01, 2016, 08:28:11 am by RFZ »
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8240
Re: FTDIgate 2.0?
« Reply #209 on: February 01, 2016, 09:40:55 am »
Has the source of the counterfeit devices ever been determined (manufacturer?  Path?)  Maybe they should just sell their own chip and do their own driver; it can't be that hard - ch340g has penetrated pretty well, to the same sorts of vendors, even though it's significantly different.
When the first FTDIgate happened I traced it down by starting here...

http://zeptobars.ru/en/read/FTDI-FT232RL-real-vs-fake-supereal

...and ended up with this:

https://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg535577/#msg535577

The company now shows they have an "RD232A" along with the original "SR2303HX" (presumably a Prolific clone).

This page shows that CoreChips makes the Supereal brand and they appear to have written their own LAN drivers:
http://catalog.update.microsoft.com/v7/site/ScopedViewRedirect.aspx?updateid=5316ed3d-5397-446c-aaf7-4388e3d03f7a
 

Offline glynd

  • Newbie
  • Posts: 4
Re: FTDIgate 2.0?
« Reply #210 on: February 01, 2016, 10:17:00 am »
Intel used fake FTDI chips for their Gen 2 Galileo?

I expect it was a USB serial lead the guy was using with a fake FTDI chip in it...
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: FTDIgate 2.0?
« Reply #211 on: February 01, 2016, 10:24:40 am »
Intel used fake FTDI chips for their Gen 2 Galileo?

I expect it was a USB serial lead the guy was using with a fake FTDI chip in it...
yup, already brought up a couple of times, no FT232 and variants on either Gen 1 or Gen 2 BOM
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: FTDIgate 2.0?
« Reply #212 on: February 01, 2016, 10:59:15 am »
Intel used fake FTDI chips for their Gen 2 Galileo?

I expect it was a USB serial lead the guy was using with a fake FTDI chip in it...

It would have helped if the message read "NON GENUINE FTDI DEVICE FOUND", but as a measure of their ineptitude FTDI couldn't even get that right. It obviously didn't occur to them that people wouldn't immediately realise it was the seemingly innocuous USB-serial adapter screwing up their system.  |O

I have to say, in terms of PR screw-ups, this one is as bad as the last FTDI one.

Today I will be looking at how to replace FTDI chips in our designs... even if there is not a technical reason, and obviously we never intend to put counterfeit chips in our products, but we don't and could not check every chip we fit, we rely on suppliers to ship good parts. I have lost trust in FTDI that they will handle things sensibly.
Bob
"All you said is just a bunch of opinions."
 

Offline RFZTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: FTDIgate 2.0?
« Reply #213 on: February 01, 2016, 10:59:43 am »
Intel used fake FTDI chips for their Gen 2 Galileo?

I expect it was a USB serial lead the guy was using with a fake FTDI chip in it...

And that is one of the major problems with this FTDI driver. Even as a developer, if you hook up a device to your PC using a USB-RS232 converter and you get "NON GENUINE DEVICE FOUND!" on your terminal, you won't expect it to be the converter generating this message. You would think it comes from the device. This is why the user thought the Galileo board was faulty and even Intel opened a support case because they didn't know about the strange FTDI driver.
The message doesn't even contain the words USB-Serial, RS232 or FTDI in it. How, even as a developer, should you supposed to know that the message is talking about the RS232 converter?
 

Offline rasmithuk

  • Newbie
  • Posts: 3
  • Country: gb
Re: FTDIgate 2.0?
« Reply #214 on: February 01, 2016, 11:03:45 am »
apparently Microsoft is okay with it (I don't see how this should have passed WHQL).

They were ok even with the previous version that was bricking the chips and then pulled it later. I think the WHQL doesn't mean much here - FTDI has some sort of privileged position because their drivers ship directly with Windows, unlike most third-party vendors. So their stuff likely gets only the basic "does it cause BSOD/eat data" test and that's it, because they are trusted.

FTDI don't have any special deal with Microsoft because WHQL doesn't test for anything like this.

To get a WHQL cert you get the tools, take a clean machine and run them on your driver. It produces a log which gets sent back to Microsoft along with the driver.
If it passes the tests it get signed.
If your device claims to meet a standard device type it gets tested for the normal responses but that's all.

Even if Microsoft did test the driver themselves, they'ld do so with the provided hardware, which would be from TFDI and pass their tests.

If the bad driver gets reported to Microsoft they'll probably pull it. As the last version changed the VID/PID it broke hardware which is why it got pulled so fast.
 

Offline Barny

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: at
  • I'm from Austria, not Australia ;)
Re: FTDIgate 2.0?
« Reply #215 on: February 01, 2016, 11:16:23 am »
Sadly I have visited this forum to late.
Today morning, I played a little around with my dev-board while eating my breakfast.

For debug I use the UART to write most registers of my AtMega32.
I was to lazy to use proper check-sums.

And now guess who is proud owner of an fake FT232 chip on his USB-UART bridge without knewing.


The AVR was a little bit upset about getting his Pins shorted to ground while switched to output & deliver 5V.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: FTDIgate 2.0?
« Reply #216 on: February 01, 2016, 11:46:21 am »
Incidentally, I took a look at the code and empirically tested a clone device to confirm.
I found another interesting (unicode) string in the ftdibus.sys file: "The FTDIBUS driver detected a Type 1 counterfeit device and will disable this device." (and the same string with 2-5 instead of 1, can't they use sprintf in a driver?). Can't find the xref with my IDA Pro disassembler, when is it used?
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: FTDIgate 2.0?
« Reply #217 on: February 01, 2016, 01:49:22 pm »
Maybe you can answer some question, because you are already using this chip: From the datasheet it is not clear to me if it supports more than 115,000 baud. The formula says 12 MHz / x (with x integer), but in other chapters it says it supports only 300-115,200 baud. Can I use it with 1 MHz baud rate?

I haven't tried this, but I seem to recall that on paper it does support it, but you get lower bandwidth than the FTDI one because they do some silly delays between the USB transactions or something to that effect. The Microchip chip is nothing else but one of the cheap 18F14kxx PICs with a pre-programmed firmware. I think Dangerous Prototypes tried to hook it up to a PICKit when it first came out and it matched the MCU ID. It is apparently 16F1455:

http://blog.zakkemble.co.uk/mcp2221-hid-library/
and
https://www.eevblog.com/forum/reviews/alternatives-to-ftdi-usb-to-uart-converter/msg540581/#msg540581

And the datasheet says it doesn't need a driver, it uses the standard virtual COM port driver on Windows. Does this mean you don't even need a custom INF file  for it? I think it is possible in Windows, if the device enumerates as CDC USB device class (see here). Is this the case for the MCP2221? And does MacOS and Linux support it?

In Windows you don't need an inf file because it is a standard CDC device. Linux certainly supports it out of the box, no hassle. No idea about Mac, but Macs support standard CDC ACM devices without drivers as well so I would say it is supported there too. It is only Windows that is so screwed up in this regard.

For me the only use for the FTDI hw remains the bit bang mode (I have an adaptor with the FT2232H in it) and the built-in JTAG support and not needing to supply a driver. However, those things are often easier and cheaper done by simply sticking a small micro in there anyway - USB CDC code is pretty much a standard example code from every vendor of USB capable micros I have seen.

J.
« Last Edit: February 01, 2016, 01:59:27 pm by janoc »
 

Offline aandrew

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: ca
Re: FTDIgate 2.0?
« Reply #218 on: February 01, 2016, 03:03:24 pm »
FTDI put/puts a lot of time and money into writing and maintaining their drivers, getting them signed and certified, integrated into the Windows Update ecosystem and the Linux kernel, etc.  They recoup this cost through a slightly higher sales price on their products, and people pay it because of the convenience.  Why would you expect to be able to use FTDI's drivers, for free, forever, without purchasing their product?  That attitude just blows my mind.  You should consider every day you've been able to use FTDI's drivers with your counterfeit device as a gift, rather than freaking out when that privilege is finally revoked.  This attitude of entitlement bothers me to no end.  I suppose Microsoft's "Genuine Advantage" system should be renamed into Microsoft-gate too?

These counterfeit companies are welcome to build their own devices, but they should also be writing their own drivers and going through the same process as FTDI to integrate those drivers into consumer operating systems, maintaining them, etc., in order to make their devices usable to end-users.  What's that?  Doing so would mean they'd have to charge FTDI-like prices?  Oh shucks, I guess the world does make sense after-all.

Don't want to deal with this kind of BS?  Then quit shopping on eBay and Alibaba and spend an extra dollar on the real thing.

Note: I'm using "you" in the collective sense, not you specifically.

AMEN! I was very much against FTDI when they decided to "brick" (blank the EEPROM) of counterfeits because it was a (sort of) destructive operation. This, however? I'm okay with this. I buy from aliexpress/ebay all the time and expect weird shit to go down occasionally. It's the price I pay for bottom-dollar electronics and I'm okay with the risk.
 

Offline aandrew

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: ca
Re: FTDIgate 2.0?
« Reply #219 on: February 01, 2016, 03:09:25 pm »
Nobody is out there looking to save a few pennies buying counterfeit FTDI chips.

This is not true.

Manufacturers are under constant pressure to lower costs. They in turn put pressure on their procurement departments to get the price down, who then go out and find anyone offering the same line item at a lower cost. Eventually they find it.

We dealt with counterfeit Intel 80196 (motor controller) microprocessors 15 years ago. How did we get it? Exactly how I described above. No, I don't believe for a moment that Arrow will get a line of counterfeit FTDI chips since they're big enough to be talking to FTDI and its manufacturers directly.

Who will be getting counterfeit FTDI devices? The smaller suppliers/distributors who go through a supply chain that does not have the traceability required to ensure a genuine component. It's a cost of doing business with smaller outfits, who are under incredible pressure to get something as cheap as possible.
 

Offline dack

  • Newbie
  • Posts: 3
Re: FTDIgate 2.0?
« Reply #220 on: February 01, 2016, 03:19:57 pm »
The linux drivers are not made by FTDI. They are made by the linux community. That's why they've never had any issues with bricking clones, and will even undo the bricking done by the FTDI drivers.
 

Offline marcan

  • Regular Contributor
  • *
  • Posts: 80
  • If it ain't broke I'll fix it anyway.
    • My blog
Re: FTDIgate 2.0?
« Reply #221 on: February 01, 2016, 03:37:19 pm »
Incidentally, I took a look at the code and empirically tested a clone device to confirm.
I found another interesting (unicode) string in the ftdibus.sys file: "The FTDIBUS driver detected a Type 1 counterfeit device and will disable this device." (and the same string with 2-5 instead of 1, can't they use sprintf in a driver?). Can't find the xref with my IDA Pro disassembler, when is it used?
I'm not a Windows expert, but I believe those are translation/textual string resources used for the system event log. Messages are logged by code, so there wouldn't be a direct xref there, instead that's a table that maps codes to strings and something inside Windows itself does the mapping - so yeah, they can't use sprintf, this is Windows' dumb design I think? (someone with more Windows knowledge might be able to correct me here). I did find the logging code earlier, and what triggers it, but didn't check if it is indeed logged on my windows box. I just did and yeah, it's there:



Of course, they say they'll disable the device, but then go ahead and corrupt its data instead. Nice definition of "disabling".

Types 1-4 mean integrity checks on EEPROM addresses 0x40-0x4f failed (which seem to store manufacturer info, perhaps non-writable? haven't tried, the normal EEPROM user/config area is 0-0x3f), while type 5 does the good old 16-bit EEPROM writes check (what they used to brick devices in the previous version, except this time they revert their changes). It actually writes a 0 to the PID field (without fixing the checksum to match), reads it back, and restores it if written (original chips won't write it as its address is even). Amusingly, all of this is still wrapped in a "if EEPROM checksum is correct" conditional, so you can still use my Python tool to deliberately corrupt your EEPROM which will make the chip work with the official driver (if you're okay with all default configs and no serial number), but even better, if you plug it into a Windows machine with the new driver and unplug it at *just the right time*, the written PID field will cause a checksum failure and the driver will start to work fine with that device!
« Last Edit: February 01, 2016, 03:40:27 pm by marcan »
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: FTDIgate 2.0?
« Reply #222 on: February 01, 2016, 06:06:05 pm »
For me the only use for the FTDI hw remains the bit bang mode (I have an adaptor with the FT2232H in it) and the built-in JTAG support and not needing to supply a driver. However, those things are often easier and cheaper done by simply sticking a small micro in there anyway - USB CDC code is pretty much a standard example code from every vendor of USB capable micros I have seen.
Right, I guess all USB UART chips will have some kind of CPU in it and some firmware. Then it is better to use a standard microcontroller, where you can at least update the firmware, if you need to (e.g. if Windows doesn't support CDC anymore) and where you can implement special things, like bitbanging or JTAG over the serial port.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline Russ.Dill@gmail.com

  • Contributor
  • Posts: 19
Re: FTDIgate 2.0?
« Reply #223 on: February 01, 2016, 07:24:21 pm »
FTDI put/puts a lot of time and money into writing and maintaining their drivers, getting them signed and certified, integrated into the Windows Update ecosystem and the Linux kernel, etc. 

Hah, FTDI and open source. They have made extremely limited contributions to open source. The Linux kernel driver would not exist if it were up to FTDI. They have a userspace library which is of course *not* open in any way. Luckily people have taken time to make both an open kernel driver and user library. Of course, now I can't do cool things like make my Arduino act like an FTDI directly via v-usb to make integration for windows users easier.
 

Offline Monkeh

  • Super Contributor
  • ***
  • Posts: 7990
  • Country: gb
Re: FTDIgate 2.0?
« Reply #224 on: February 01, 2016, 07:27:47 pm »
Of course, now I can't do cool things like make my Arduino act like an FTDI directly via v-usb to make integration for windows users easier.

Why would you need to?

And why would you think it reasonable to make your Arduino behave like a piece of hardware with very specific capabilities when it is nothing of the sort?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf