Well, I disagree about that being the only place. Serial ports are absolutely huge in the embedded world. A large number of consumer devices also use serial internally, and maybe convert to USB right at the edge of the box.
Networking brings up an interesting point. I actually prefer to add Ethernet to an embedded design over USB. It's actually easier, if you can believe that bull****. It's also massively more flexible and quite a bit faster.
Many TCP/IP stacks can be ported to a new platform by simply implementing a read, a write, and a status function to talk to your specific MAC.
USB is usually a horrible kludge taking some vendor's usb-to-serial or mass-storage example code and hacking the crap out of it until it works. The USB module registers are so different from vendor to vendor, etc.
At the PC level, it's different. There are some standards there. Even there, it usually takes custom device driver work to get a new device working... something that Microsoft should be totally ashamed about. They really should have provided something like libusb on Linux.
To summarize, USB is a horrible horrible bus for the thousands of smaller embeddded shops out there. It requires dealing with incredibly poor quality vendor example code, and worst of all you have to find someone who can write you a Windows device driver. Well... unless you're lucky enough to know how to do that yourself. I can, but it's such a pain in the ass that I'd much rather use Ethernet... which doesn't require a stupid driver on every OS you want to use it with.
Just a few days ago I hacked together a 9600 baud serial output in like an hour to help me debug an embedded microcontroller design using only a single IO pin and a crude spin-delay based bit-bang function. It worked great, and I found the trouble.
There's no way you could add something like USB nearly as easily. FTDI makes some great chips / cables, but at the microcontroller it's still TTL-level serial IO.
Plenty of microcontrollers have lots of extra serial IO ports. Many are adding USB ports as well, but it takes an absolutely stupid amount of firmware to make USB work.
There are several microcontrollers I can do USB for, since I've done it before. However, it takes weeks of work to implement USB the first time on any new microcontroller. It's usually really prone to bugs, too. USB is just too complex for the simple dumb pipes that most embedded developers need. On top of that... most of the time the micro vendor's USB firmware examples just barely work, and aren't designed very well so they're very hard to modularize and include in another design.
Slashdot Mirror
Yeah. This is a really easy way to go. The -really- annoying thing is when they don't bother to change the USB product ID.
It sucks when you have three devices that all show up as the same vendor/product combination.
Well, I disagree about that being the only place. Serial ports are absolutely huge in the embedded world. A large number of consumer devices also use serial internally, and maybe convert to USB right at the edge of the box.
Networking brings up an interesting point. I actually prefer to add Ethernet to an embedded design over USB. It's actually easier, if you can believe that bull****. It's also massively more flexible and quite a bit faster.
Many TCP/IP stacks can be ported to a new platform by simply implementing a read, a write, and a status function to talk to your specific MAC.
USB is usually a horrible kludge taking some vendor's usb-to-serial or mass-storage example code and hacking the crap out of it until it works. The USB module registers are so different from vendor to vendor, etc.
At the PC level, it's different. There are some standards there. Even there, it usually takes custom device driver work to get a new device working... something that Microsoft should be totally ashamed about. They really should have provided something like libusb on Linux.
To summarize, USB is a horrible horrible bus for the thousands of smaller embeddded shops out there. It requires dealing with incredibly poor quality vendor example code, and worst of all you have to find someone who can write you a Windows device driver. Well... unless you're lucky enough to know how to do that yourself. I can, but it's such a pain in the ass that I'd much rather use Ethernet... which doesn't require a stupid driver on every OS you want to use it with.
Simplicity really is the key.
Just a few days ago I hacked together a 9600 baud serial output in like an hour to help me debug an embedded microcontroller design using only a single IO pin and a crude spin-delay based bit-bang function. It worked great, and I found the trouble.
There's no way you could add something like USB nearly as easily. FTDI makes some great chips / cables, but at the microcontroller it's still TTL-level serial IO.
Plenty of microcontrollers have lots of extra serial IO ports. Many are adding USB ports as well, but it takes an absolutely stupid amount of firmware to make USB work.
There are several microcontrollers I can do USB for, since I've done it before. However, it takes weeks of work to implement USB the first time on any new microcontroller. It's usually really prone to bugs, too. USB is just too complex for the simple dumb pipes that most embedded developers need. On top of that... most of the time the micro vendor's USB firmware examples just barely work, and aren't designed very well so they're very hard to modularize and include in another design.
okay, recovered my login. This is me. I'll skip reposting the whole thing.