We’ve used FTDI chips for years in our product line, and for years have had issues with their drivers installing / working properly on various generations of Windows. Still, the chips work great once you do get past the driver hassle, so we’ve soldiered on.
Today, I read this:
Basically, FTDI decided that the best way to deal with counterfeit chips is to write to their EEPROM in such a way that they are bricked. Now, I’m not happy about counterfeit stuff either, and we’ve never used any knock-off chips in our products, but such a draconian (and likely illegal) approach to competition is the proverbial straw that is breaking this camel’s back. So I’m looking for a new USB <—> Serial converter.
Has anyone ever used the Microchip MCP2200 with Xojo projects? Are there others I should consider?
I need windows and mac drivers, and would HUGELY prefer not to be forced to release my own WHQL certified windows drivers (which I’ve had to do for FTDI).
If anyone has input, I’m interested in this as well.
I do not know of any “better” devices than the FTDI ones, but there should be others.
I don’t really know how “illegal” it is to do what FTDI was doing (painful to customers yes). Providing a cloned device which mimics FTDI’s signature is already illegal; so FTDI would potentially be “illegaly” altering the EEPROM signature of a device which illegaly used their signature to begin with :). Not really sure how that works; but I think for FTDI to do something illegal, wouldn’t they have to be modifying something that was legal to begin with. Honest customers probably get caught in the middle for sure when they purchase “clones” without knowing. BTW, they are not the first (nor the last) to attempt to thwart clones using this.
Wow, this is interesting. So, it looks like counterfeit chips are using the native driver provided by FTDI and have been getting away with it. FTDI found a way to shut them down and they’re doing it. There is a lot of talk about the legality of this. But I bet they write to the eeprom of any device it is connected to and it just so happens that the counterfeit chips can’t deal with that and it bricks them. If somehow they only do this to non-FTDIchips I would expect that to be illegal. I bet reading the small print in their driver license it specifically says that is only to be used with Genuine FTDI products.
Counterfeit chips are a BIG issue, having been burned before on this I say more power to them. This is so pervasive in the electronics business that you will see more of this. Although not exclusively, much of this comes from Chinese manufacturers that will use competitor logo’s packaging that appear to be identical to the genuine items.
But I don’t understand how this is affecting you if you are using genuine chips and drivers?
I’ve used multiple Microchip products in the past, although not that one specifically, but all have worked as advertised. I am assuming they are providing a licensed driver with it?
We have not been directly affected by this, and don’t expect ever to be. However, we are also not directly responsible for sourcing the exact chips on our boards. We design a board, and submit it to a layout house that orders parts and solders everything up for us, then flashes the boards with our firmware and delivers ready to ship products. We have no control over where or how they get the parts for the board. I’ve read today about some people being burned because their fab / layout houses are sourcing the knockoff chips either intentionally (to save a few bucks) or inadvertently because their further-upstream supplier has done so. There is a long chain of entities involved in getting a finished board, and several of them have the opportunity to do this with zero knowledge of the end customer.
Yeah, they are intentionally doing this to only non-FTDI chips, and have admitted it.
At any rate, I don’t want to be potentially put into a position where my customers are vulnerable to their hardware becoming bricked because a chip manufacturer decides this is the best way to deal with counterfeits. They should have simply had the driver refuse to interact with these counterfeit chips, rather than actively destroy them.
However, this really is just sort of the latest in headaches in using FTDI chips for us. Since they are really common, and since most of the devices that use them simply rely on the FTDI-supplied WHQL certified drivers available on Windows Update, we’ve run into all kinds of problems with program x attempting to talk to our devices. So we have been forced to set our devices to use a custom version of the FTDI driver that we had to take through the WHQL process ourselves (which is both expensive and takes forever). So we have our own custom driver that is available on Windows Update for our devices, that really only gets installed and works properly about 75% of the time. So 1 in 4 of our windows users have to call us for help before they can ever get their new shiny from us working because the stupid driver won’t install using Windows Update. It’s aggravating for us and for our users.
I’d really love to find a device that is either 100% USB HID compliant (i.e., essentially driverless) or that does not require such shenanigans to get a driver installed and working correctly. Recent versions of Windows that completely refuse to install non-WHQL certified drivers make this process even more painful.
We’ve been using the FT232RL for years, but would love to change to something with fewer headaches.
I have been looking in to this for a device I have been working on. I found a link about a microchip product being used as an HID. There’s not much there but here’s the link:
I have ordered a couple pic micro controllers but haven’t figured how to program one yet on the mac. Looks like I need to order more hardware (pickit3). I thought I could get away with building my own programmer but it looks like a pita. Plus the IDE seems overwhelming for me at this point.
Maybe check with MeLabs. They make a basic compiler for microcip products.
These are other popular IC manufacturers for USB Bridge ICs that the company I worked for has looked at in the past:
We’ve had good experience with Silicon Labs, have not tried Cypress, and did not have a good experience with Prolific.
I may be missing something here, but what is the advantage of implementing another layer of hardware on top of the complexity of USB communications when just good old serial to serial works well.
From the language reference: [quote]Communicating with USB Devices
Most USB devices have a chip in them that makes them appear as a serial device. Typically this chip is a FTDI chip. If the device has this chip, you can communicate with the device with the SerialPort class. If that does not work for you, the Monkeybread plug-in has USB support for a handful of specific types of devices.
In a perfect world every device is true FTDI and good ole’ serial is all you need. The problem is not all devices are outfitted with the ftdi chip. In the cases listed earlier in this thread, there are some clone chips that are knock offs and FTDI is somehow damaging the clones with their driver software. The learning curve of implementing USB is large (IMO) and not worth the trouble if you can have a bridge from USB to Serial. The FTDI chips (or its counterparts) take hide all that complexity from us and present a serial port.
Simple: new computers don’t have serial ports.
Not really. A USB port is still a serial port with different connectivity.
Not really. A serial port is a serial port. It doesn’t matter what’s connected to it. USB devices may act like a serial port but I’ve worked with some USB devices that do not just work without an additional library (Lego MindStorm bricks comes to mind) - and it’s those devices that are hard to work with in Xojo.
the only similarity is really that they both have serial in the name
USB is a lot more complex than rs232 or 422 ever was
The wikipedia article covers a lot of the intricacies
Ok, If we look beyond the enhancements of a USB device being able to identify itself as a hardware class and has staggered power connectors, It still relies on a stream of data and protocol commonality with RS232.