FTDI pisses off Arduino fanboys, then launches Arduino-compatible boards

[pickle9000]

I don't suppose there's any way to actually identify a counterfeit FT232RL, is there?
I'm designing them into two different products as we speak.

This question is the definition of what FTDI did wrong.

You can say they had the right, did not, easy to fix and a million other things but designers have enough crap to deal with. As far as I know if you have to ask this sort of question best to go elsewhere. For new products that is a definite possibility and may not be limited to a single chip but to the brand.

[westfw]

Doesn't Windows have a generic CDC driver for emulated serial ports?

Yes (Arduino Uno/etc uses it, for example.)  But for windows you still need at least a .inf file to confirm to windows that the particular VID/PID is in fact a CDC device.  Or something like that :-(

I'm not sure why USB/Serial devices seem to frequently have their own drivers.  I don't recall seeing a lot of flames about the CDC specifications being awful, for example.  (However, windows and Mac apparently have different problems dealing with "composite" devices (in general) that include CDC as a component (for example, the TI launchpad wants to define both CDC "comm uart" and custom HID "debug interface", and had assorted problems.  Maple wanted to be both CDC and Mass Storage, and that had problems.)  Of course, if you use the windows driver, you're also at the mercy of bugs that it may have, without much hope of fixing them yourself...)

I really need to learn more about USB.

You can start with this "USB Design by Example" document made available by FTDI.  http://www.ftdichip.com/Support/Documents/TechnicalPublications/USBDesignByExample.htm
It does have some FTDI-specific references, but it's not bad for something that's free.  (One of the annoying thing about this whole FTDI-gate thing is that I used to think that FTDI was one of the better examples of how a complex-peripheral chip company ought to work.  Lots of documentation, the features you wanted to have, drivers for many platforms...  Sigh.)
After that, there's Jan Axelson's book: http://janaxelson.com/usbc.htm
There was also an NXP "class" presented at a trade show that I found relatively useful, maybe ?  (Hmm.  doesn't look like the video came out too good.)
Basically, you go through some relatively exacting "Enumeration" phase that defines to the host what sort of device(s) you have, and then you provide some service routines for reading and providing data for the "endpoints" of those devices.

(although, having read a lot of each of those, but not having actually written any USB code, I'm finding that it looks like there might be a pretty big gap between "theory" and "practice"   Sigh.)
(And on a lot of microcontrollers, it looks like the provided solution is "use our bloated general purpose libraries, because USB is obviously too complex for end users to actually write code."  Sigh, again.)

[amyk]

This is a good introduction to USB: http://www.beyondlogic.org/usbnutshell/usb1.shtml

The official spec isn't all that hard to read either, once you've read that one.

[SirNick]

Thanks for the links, amyk, westfw..  :-)  Looks like I have some material to dig into after I finish the book on my nightstand. 

[tszaboo]

The thing is dear FTDI:
No one will ever use the FT800. The whole concept is bad. Make ULPI USB and I2S. And a proper JTAG device to program platform flash and FPGAs.
That is all.

[westfw]

The whole concept is bad.

Huh?  If I had a chip with ULPI  USB and I2S, it'd probably be available in a version with built-in LCD support, and I wouldn't need "Eve."  The target market is people with smaller processors that can't do those.  Just like the FT232 is aimed at people who want USB connectivity without having a USB peripheral on their "main cpu."  (Hey!  Their existing customer base!  How about that!)

Now, it may not be very sensible to want to drive an LCD display with such an anemic CPU (by today's standards), but there seem to be quite a few people who want to do it anyway.

(Is there any standardization of LCD panel pinouts for the FPC cables that would presumably connect to something like this?)