>>> I note that more than a few chip companies have created USB-to-serial bridges (with accompanying drivers). This is a sure sign of USB's technical failure. Which isn't to say that USB won't thrive.
Here's my thought about those chips. I do a lot of simple prototyping, testing, data acquisition, and so forth. To these ends, I often build my own little gadgets that combine some sort of microcontroller with some analog electronics, etc. I wouldn't be insulted if you called me a hobbyist. Still, the stuff that I make works, and solves problems.
There are "USB microcontrollers" that contain a built-in USB port. Then you have to wade through each manufacturer's peculiar documentation, and hope that their demo code does what you need, or prepare to roll your own on both the embedded and desktop sides.
Or, you hook up a USB-to-serial bridge. There's nothing magic about serial, except that it only robs you of two pins, and setting it up is 100x easier. Also, the bridge chip runs independently, making it 100x easier to write real time code on the microcontroller.
If I went to any other kind of interface, I'd use the same approach of a "bridge" module plus a microcontroller. There are such modules for virtually every conceivable interface.
I've had the pleasure of watching my gadgets work on multiple platforms with no extra effort on my part. I think a platform needs to have at least one "people's port" and the FTDI chip meets that need nicely.
Exactly! While some people claim that this robs USB of some of its strength, surely having a 10 line cross platform python script control your ADC/blink the LEDs is the ultimate deal breaker for USB2uart.
And even IF your micro comes with built in USB, it's just so convenient to just let it emulate a cdc compliant serial port working everywhere out of the box.
Libusb is almost as good on non-windows (which needs some pseudo driver to allow the library to generically talk to the device)... but then one would need a serial-terminal substitute to send packets off data to arbitrary endpoints.
> Libusb is almost as good on non-windows (which needs some pseudo driver to allow the library to generically talk to the device)...
If it's your USB-device, you can add a WCID descriptor [1], and use the WinUSB/libusb API. No driver installation necessary post Vista (on XP you need to manually install the WCID driver, but only once).
Here's my thought about those chips. I do a lot of simple prototyping, testing, data acquisition, and so forth. To these ends, I often build my own little gadgets that combine some sort of microcontroller with some analog electronics, etc. I wouldn't be insulted if you called me a hobbyist. Still, the stuff that I make works, and solves problems.
There are "USB microcontrollers" that contain a built-in USB port. Then you have to wade through each manufacturer's peculiar documentation, and hope that their demo code does what you need, or prepare to roll your own on both the embedded and desktop sides.
Or, you hook up a USB-to-serial bridge. There's nothing magic about serial, except that it only robs you of two pins, and setting it up is 100x easier. Also, the bridge chip runs independently, making it 100x easier to write real time code on the microcontroller.
If I went to any other kind of interface, I'd use the same approach of a "bridge" module plus a microcontroller. There are such modules for virtually every conceivable interface.
I've had the pleasure of watching my gadgets work on multiple platforms with no extra effort on my part. I think a platform needs to have at least one "people's port" and the FTDI chip meets that need nicely.