Heck, the whole process to build Qt and its browser-du-jour (webkit then, chromium now) amounts to configure followed by make, and that's whether you're on Windows or Unix.

IBM's mainframe processing power is a bit different than your typical desktop processing power. Mainframes have, historically, never been used for much numerical computation, but are heavy data/string pushers. All the while a desktop CPU has several subsystems optimized to crunch numbers in a way that is not useful at all in a mainframe that pushes, say, product data around.

Amazon Prime isn't a handout, let there be no doubts about that. Even if you anecdotally have used it as a handout (I did, too), averaged across the customer base it's not a handout.

Huh? Why on Earth would there be all the unused pads then? It looks to me like a bog-standard USB microcontroller, although I haven't look at all that much die pictures in my life.

My vendors have pockets deep enough that if push came to shove, I'm sure we could extract sufficient damages. Again, if you understand your supply chain, there won't be surprises.

It was their chip in as much as the chip tried very hard to be detected by their driver. IMHO at that point all the bets are off. I've been thinking about it a lot and FTDI did the right thing. The people who say "ooh we won't use FTDI chips anymore" aren't really their customers. They have no real grasp of who is who in the supply chain, and they themselves will gladly purchase counterfeit chips without even realizing it. FTDI can piss those off without any loss of revenue. I've been using FTDI for a long time - since their first A revision hardware came out. I see no reason to stop using their products. If any of our product stops working, I have the mainstream vendor invoices to back up all of my purchases, and I'll gladly ship the nonworking chips back to the vendor, and demand damages/downtime compensation from them as well.

FTDI owns the entire PID range. You're thinking of the VID. They didn't change the VID.

So far, we know that the FTDI clones are just generic mask-ROM microcontrollers. Probably the Prolific ones are similar. No counterfeiter would go as far as duplicating the functionality at the level of silicon, unless they wanted to go against the copyright and simply copy the masks. They must be somewhat flaky because it's just a microcontroller with its GPIO packaged to look "like" an FTDI chip. The electrical specs don't quite match, the behavior doesn't quite match, it can't but be flaky.

The counterfeit chip is an off-the-shelf microcontroller. That's why it's cheaper. Whoever packages it didn't have to do all the silicon and driver R&D. They wrote a little bit of firmware that makes it behave like an FTDI chip and that's it.

Fry's is "mainstream" in an alternate universe. They sell stuff that the real electronics distributors woudln't touch with a long pole. Newark, Mouser, Allied Electronics, Digi-Key, ELFA, Distrelec are the big names. There's also Jameco, although I would only buy branded brand name stuff there. If it's an FTDI converter not branded FTDI, I wouldn't get it at Jameco.

There are some dirt cheap USB-toting MCUs that could be used instead. Way cheaper than any FTDI chips. Heck, IIRC even Zilog has caught up with times and has something to offer here for cheap. ZILOG, man :) I mean, Zilog has been a trainwreck for such a long time.

All you need to do is to use any VID/PID combination for which an .inf file is bundled with Windows :)

"What process are they assigned a PID?" They start up with defaults in the EEPROM, and there are also hard-coded defaults in the silicon. The silicon tests the EEPROM area for a correct CRC, if there's a CRC mismatch, the hardwired defaults are used. So, the process on power-up might be:

1. A read attempt is done from external EEPROM. If the reads fail or the CRC doesn't match, the data is not used. Otherwise, it's copied to internal RAM.
2. A read attempt is done from the internal EEPROM (if such exists). If the reads fail or the CRC doesn't match, the data is not used. Otherwise, it's copied to internal RAM.
3. If RAM hasn't been initialized yet, it's initialized with hardwired defaults (copied from a masked ROM).
4. The state machine moves into a "ready to connect" state.

The EEPROM layout can't be different since the PC-based tools access it directly, and the counterfeit chips would simply not work for anyone who puts their own Manufacturer string in them etc. The "command sequence" is completely PID-agnostic on the wire. What goes on between the USB host and the FTDI device is a control request to write an EEPROM byte at a certain address. The chip doesn't care about the meaning of this byte until it's power cycled, and even then, it won't care if the CRC at the end of the configuration area is wrong.

So, I back out of my claim the FTDI merely does a wrap-around to erase the PID. It also has to update the CRC, since otherwise the chip would ignore the contents of the EEPROM and start up with default VID, PID and other configuration. What they do is very much deliberate.

As for the chips with the built-in EEPROM, as I've stated, it's rather simple to attach an external, pre-programmed EEPROM. Heck, perhaps it'd be a good thing to offer as a product for people who wish to unbrick their devices - as long as the counterfeit chips implement this. Perhaps the counterfeits don't implement it, though? I really wonder how much do the counterfeit FT232R chips do as far as emulation of the real FTDI chips. Do they, for example, offer the clock outputs, like the real FT232R chips do? I bet they don't, and I bet that it'd be rather trivial for an amateur to check if a given chip is real or not by doing one well-placed behavioral test like that (specifically, set one CBUS output to 48MHz clock). After all, the counterfeit chips are really just a standard microcontroller with masked ROM. How many mack-programmable microcontrollers can output the system clock on one of 5 GPIO pins? The counterfeits aren't custom silicon, after all.

While on that topic, I have to check if some FTDI chips that I have with wildly off-spec silicon oscillator frequency are genuine or not. If they aren't, DigiKey is gonna get some talking to :)

I was talking about CDC. If FTDI chips did implement the CDC, then they'd work out of the box on Vista and higher, and of course on OS X and Linux. Now since the FTDI chips don't implement the CDC, Microsoft doesn't provide drivers for them, and FTDI has to have their own drivers bundled with Windows and available via Windows Update.