Some of the complaints hold true, others just sound bizarre now:
> But for the vast majority of devices, you had better have your driver disk handy
Driver disks... yeah, I think I remember those?
My biggest complaint with USB isn't there, the ports can be kind of fragile. Even without regular swapping (which the design seems to encourage), USB drives and cords slowly pry them out of position. Forget about the port if anyone bumps the USB stick or trips over the cord while it's plugged in.
Even then, using USB devices WITH drivers beat the hell out of configuring IRQ and DMAs. I remember the ordeal it was when you wanted to add or change something and you had conflicting IRQs... pfff..
Because a perseverance in being stupid made the choice of a long series of bad choices.
Motorola 68K and specialized high quality embedded units? (like amiga):
no it will be overprices compared to the cough future price of an evolutive PC. Which final form are below average quality and overpriced embedded devices.
Had you followed the way of the old wise and chosen motorola architecture, you would not have theses problems. :)
Those old enough will remember the Apple II and its fully decoded, addressable expansion slots. Each slot with specific addresses for memory mapped IO and space for a small firmware (to boot a disk, output characters to a second screen and so on).
The IBM PC looked remarkably primitive in comparison.
When PCI replaced ISA (which was prior to USB taking off), dealing with IRQs and DMAs was a thing of the past, making that a poor reason to say USB is superior.
Uhmm... I guess you are correct. I indeed remember going from PCI to ISA. Also to AGP! oh my.. the speed of that thing. But I think the point still stands, maybe not that much with that specific example, but how about PS/2 keyboard and mice?
Woops... disconnected the mouse/kb by mistake? off you go rebooting the computer. I think that does indeed make it a good reason to say USB is superior.
The first time you plug a new brand of USB memory stick into a Windows 7 box, Windows goes out and downloads a driver for it.
So it's automatic, and it's "plug and play" in a sense, but it's just papering over the "driver disk" problem, not really solving it (i.e., eliminating the need for the custom driver).
And if the company that made the device doesn't feel like updating their drivers... well, you're SOL, probably. Buy a new scanner.
That's kind of an absurd situation. Yes, using USB is a little smoother than it used to be, but why is this the best we can do?
It doesn't download it from the internet if that what you mean. Windows 7 comes with a big library of generic drivers included.
I have a windows 7 machine that I've never connected to the internet or even a network and most things will have drivers installed automatically.
That's true, if you plug in a usb flash storage device, windows has the standard class driver locally and installs it without any requirement on internet access. Same with standard keyboards and mice.
But compare to linux. On windows, the first time you plug a particular model of usb device into a particular port, it takes 20 seconds to "install the driver" (and then it's almost instantaneous on future plugs of the same device into the same port). On linux, it's almost instantaneous, the first time and every time. New device, different port, still instantaneous.
It doesn't really make sense why it would take longer the first time, or need to happen again when plugged into a different port. silly windows...
Not only that, but vendors nowadays figured out that they can embed a flash chip with Windows drivers in the device. When you first plug it in it shows up as a disk drive that autoplays the driver setup then ejects the storage device and that's when the actual endpoint is connected which can be handled by the newly installed drivers and UI software.
Of course, autoplay has its own obvious drawbacks.
I just had to install a USB WiFi stick for someone last week... Windows didn't have a clue what it was, so I had to go track down the drivers off the vendor's website. Thankfully they were still around. :P
Work finally upgraded to Windows 7... I had to install a driver for the printer.. then yesterday we used a driver disk to get a second monitor running....
I have two Kindle Fires with broken micro USB ports and I've seen two LEGO NXT robotics controllers break USB B ports. Even with DB-9 connectors soldered to boards, I don't remember a lot of breakage. I think it's because those were almost always through-hole and so much today is just surface-mount so it's relying on the pads staying adhered to the board to physically hold a frequently plugged/unplugged port in place. Crazy.
#1 is just the nature of cables. If you think blutooth is the answer, try using blutooth for a while.
#2 is actually a really big deal with developing software to interact with anything USB. Well, I should say anything based on the FTDI chipset. I don't have any experience with anything else. Which is increasingly the case, given the modern proliferation of hobbyest hardware projects. There are no connection status events. RS-232 never developed any because a loss of connection with a cable that is physically bolted into the computer should be a catastrophic event.
Oh, I cannot tell you how many hours of my life I'll never get back debugging connection status issues. And it doesn't necessarily have to be a physical break in the connection that causes the problem. It could be an every so small short in the connector that only triggers once in a blue moon when you shift yourself in your seat and accidentally bump the wire with your chair handle while also plugging in your headphones.
Luckily, the latest versions of Windows (don't look at me, clients don't seem to care that they'd save a ton of money using Linux) are pretty robust to USB connection cycles. It used to be, if you lost a connection before closing the connection, you wouldn't be able to close the connection. The USB device would get assigned to the same COM port, which you couldn't open, because you still had it open. But couldn't close. Because you lost the connection. In the later days of XP, it often led to having shutting down the program, recycling the USB connection, and start the program again. In the early days of XP, it required a whole system reboot.
#3 I don't actually begrudge anymore. It's a situation that occurred due to evolution. Regular B connectors are too big for small devices, so Mini-B was developed to accomodate. But it turned out that the design was significantly flawed, creating a board connector geometry that was not very robust against repeated pluggings and unpluggings. Micro-B was developed to be significantly stronger, to support a greater number of cycles (if you look closely, they aren't just a different shape, the pins are set in the plug completely differently). Then smartphones turned into micro-microcomputers and people started to want to plug devices into them. Suddenly, what was strictly a slave interface before, needed to have the option to become a master interface at will. USB-OTG was the result, and it's actually a rather clever compromise that maintains backwards compatibility well.
#4 can be a significant problem when doing any sort of real-time data collection. It's nearly impossible to connect a variety of sensing devices to a PC and be able to synchronize the readings of them in time. For the most part, I take the system timestamp for everything, then generate a best-fit curve and use that for my calculations. There's just no confidence in the precision of the time resolution in USB.
#5 isn't USB's fault, it's device manufacturers. Hardware developers are some of the worst programmers in the world (and yes, they will say the same thing about programmers and circuit design, but you don't see me designing circuits, now do you?). Your printer has a really shitty system for installing drivers because the driver developer can't be arsed to learn how the operating system works with drivers. And he can't be arsed because his manager is probably bugging him to "get back to real work".
His list of new problems are largely obviated by FTDI. However, FTDI has its own problems, both technical and political.
> #2 is actually a really big deal with developing software to interact with anything USB. Well, I should say anything based on the FTDI chipset. I don't have any experience with anything else. Which is increasingly the case, given the modern proliferation of hobbyest hardware projects. There are no connection status events.
This is more of a Virtual Serial Port driver issue than an USB issue, right? USB itself always seems pretty good about connect/disconnect events (at least on Linux). However, the FTDI drivers which detect this don't have any way to pass it back to devices reading the COM port (because of RS-232 legacy, as you said).
However, for real USB devices (not FTDI/VCOM), connection event notifications shouldn't really be an issue. Yes, annoying to deal with, but at least you can detect it, unlike with serial...
Does the connector have much effect on the construction of the cable itself? Perhaps Micro-USB cables are more likely to have a thinner cable due to the smaller connector.
What I have experienced are the connectors on the cable either breaking or ripping off of the cable. This has happened twice with a device I use regularly, with no damage whatsoever to the port.
I agree. Micro USB was not an improvement over Mini USB. I've never had a Mini USB cable go bad, but easily a third or more of Micro USB cables I've owned are faulty, with barely any stress. Also, Mini USB cables were a huge improvement over standard USB, because I could orient them by feel alone. I've lost that ability with Micro USB, where it often takes three tries to plug it in.
That's all intentional. Mini USB cables were stronger than Mini USB ports. Its generally better to make the weaker side of a connector the cheap easy-to-replace cable.
I've had a bit of luck with Amazon Basics branded cables recently. They've got quite a chunky connector/cable that's lasted a lot longer than my default phone cables have.
If stress is placed on the connector something will break eventually. From Wikipedia; [it is] designed to reduce the mechanical wear on the device; instead the easier-to-replace cable is designed to bear the mechanical wear of connection and disconnection. Compare that to 3.5mm audio sockets where the device has to be fixed instead of the cheaper headphones.
Interesting. I've owned devices that are exclusively micro-usb for years now, and I don't think I've ever had a cable wear out on me. However, that may be because I lose them to quickly for them to wear out.
When you say the cable wears out, do you mean the plastic-encased wire wears out, the male connector wears out, or the point where the male connector is joined to the wire wears out?
The male connector wears out, I think. But maybe it's the wire side of the male connector, I've never thoroughly tested, just played with the angles till it charged.
I use Bluetooth every day with my keyboard and mouse. Generally speaking it's problem free. Although I also use it for other things like my headset where I agree it's a pain. Seems to depend on the implementation of the pairing.
I don't do high speed data collection per se, and wouldn't know how to do it on a desktop platform even if the issue of synchronizing the ports were licked. So I shove real time functions to an outboard micro that does run in real time.
FTDI has been the best thing since sliced bread for me. It has proven to be remarkably robust and portable in my use.
One example: when the usb cable is yanked under macosx while a serial port is open, 50% of the time macosx crashes, and sometimes the crash occurs randomly up to 2 hours later.
the USB connectors have no locking mechanism. [...] users
will scream in frustration when they realize their USB
mouse has been inadvertently unplugged from the back of
the computer because it wasn't locked into place.
Is this really a problem, except for high-vibration industrial applications?
I'd rather have USB than be fiddling around trying to reach thumbscrews on the back of my computer in the dark under my desk.
I've encountered certain combinations of male and female USB plugs that fit extremely loosely, to the point that minor perturbation (like from a mouse cable) might eventually result in the plug falling out. It's pretty rare though, and it's probably just a matter of the manufacturing tolerances and how well the manufacture implements the physical spec.
Not even that, now that I watch my hand truth is only my fingers do the motion but it's mostly because I like to work with a high sensitivity setting (less than 2cm to go through all the screen).
I've actually wondered why almost all mice and keyboard come with fixed cables instead of mini/micro-b connector. I guess it saves couple of cents in part costs.
A lot of them are USB low-speed devices, especially the older ones, and the USB spec requires low-speed devices to have fixed cables because they have stricter cable-length restrictions than other devices.
My Happy Hacker (pro jp) keyboard doesn't have a fixed cable, which is a nice bonus, making it even more portable. Unfortunately the HHKB lite versions seem to have fixed cables :(
It was a colossal pain in the butt using USB in mobile robots like we did at Anybots. There aren't compatible locking versions of the connectors. Ethernet/RJ45 is much better without requiring thumbscrews.
Have you tried using one of those USB-over-CAT5 adapters they sell on eBay? I've always wanted to but never had a real application for it, and robotics sound perfect. Just bolt down the adapter on one side.
There are multiple options for locking USB connectors that retain backwards-compatibility with standard USB plugs. Amphenol and TE spring to mind and I know that there are others, including IP67 solutions.
It's really a huge issue for industrial and embedded applications. The lack of any provision for a locking mechanism basically means you have to rig some kind of awkward glue or stop bolt arrangement to stop usb connectors from falling out in high impact or high vibration conditions.
That in turn is hard to qualify and expensive to assemble so it adds cost all round.
Not for me, but wow Apple has a weird relationship with USB. On the back? Really? And then there is the power cable on iMacs. If you have the power cord going behind the desk (and pinched) then tilt the monitor the power cord comes out. Maybe Apple has something against all cables?
This seems odd to me, as a consumer I remember the days before USB was around, and it _really_ sucked. Maybe USB is less lovely if you are a driver developer, but thats because its pushing more work away from the consumer and onto the driver developer. As a consumer, USB has been pretty awesome.
edit: I suppose you could argue that something much better than USB could have been possible, but thats how it is with technology, the standard that takes off isn't necessarily the best, its just one thats _good enough_ and gets traction somehow.
Developing USB drivers is actually totally fantastically easy nowadays with libusb(x). You can more-or-less just pretend your USB device is a server you talk to through a socket. No need to even write a single line of kernel-code, you can do it all in python in userland, if you so desire.
For many USB devices this is also a totally feasible thing to do, too, because most USB devices that are not providing some standard interface that the operating system takes care of (keyboard, mice, controllers, tablets, mass-storage, ...) just provide some sort of service that typically only one application would interact with, so just having the driver inside that application that interacts with it works well.
The vendor ID device ID issue is/was real. I think there was a story here a while back about a manufacturer making it so hobbyists could use their ID or something.
I never understood these jokes, I always put the USB key/cable in the good position. 99% of times you can rely on the USB logo (which has to be at the top).
I do not understand the comment about the jokes. Where are the jokes here? But anyway, if you can see the USB logo, you are observing the device. Therefore, it will not be in the superposition state.
Externally symmetric yet internally asymmetric connectors demonstrate a fundamental incompetence of their designers. It baffles me that multiple people must have approved the USB connector design and we still ended up with the abomination that lives on 'til now.
FWIW, one of the key people involved with the USB spec (which is an incredible advance relative to serial, parallel, etc. BTW for anyone who remembers those times) told me once that the twiddling to get the right orientation was one of the main things he thought they got wrong with USB.
I'm looking at a USB memory stick right now. On one side is the company name (Kingston). The other side has the device name (DataTraveler). There is no USB logo on the thing.
So, which way does it plug in? Oh, and the USB ports on the front of my computer (tower) are vertical, nor horizontal.
Ever tried reaching in the back of an iMac to plug in a USB drive? I have a 2011 iMac, and to this day I still have NO idea which way the slots are oriented. I usually just give up, stand up, and angle the entire computer just so I can plug it in.
>>> 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).
Grounding. That's why USB sucks. If you work with precision instrumentation, USB introduces ground loops and forces unpleasant grounding configurations.
I've been looking for a USB 2.0 High-Speed (who came up with these names, where Full Speed is slower than High Speed?) opto-isolator for years. (Corning's new "3.Optical" cabling looks great, once it makes it to market)
I don't see any mention of isolation in that datasheet, nevermind an actual voltage spec. Granted I haven't looked super hard, but any USB isolator I've seen only ever does full speed. I recall seeing one chip from ADI that was meant for high speed USB isolation, but that's the closest I've come.
Agreed. In the absence of a solution like the 30m 3.Optical, we're desperate enough to try it. We have a working solution using daisy-chained repeaters (for distance) landing in a powered hub, but it's hardly elegant. People make nifty USB-->WiFi interconnects too, but the one we tried can't handle full-bandwidth usage of USB 2.0.
It was a sad day when the opto-isolating ADI development board arrived and we discovered, to our chagrin, that Full Speed != High Speed. We were so stoked to have finally found it.
Those terms ("high" vs "full") are especially tricky somehow. Perhaps that ADI chip I mentioned was the same one, and they tricked me as well. At least I was just researching to determine how bad I would want an Ethernet port if I got a PC scope. (I determined the answer was "pretty bad")
I don't know why bona fide high-speed isolators are not a common thing. Maybe 12Mbit ends up being sufficient for 98% of cases? It seems like the only way is to find a type of product for which they can't cheat, like those optical 3.0 cables or an actual GigE->USB protocol converter.
Then again Tripp-Lite is a big name, and you really would want some isolation for a 300ft run. Good luck!
Answering my own question, I ran across an EEVblog post where someone pointed out the problem is the bidirectional data line. OFC that's why you can't just feed them into a GBIC etc. USB 3 has two unidirectional pairs, and so should be easier to isolate.
However, don't get your hopes up for those 3.optical cables to do what you'd like either. USB3 actually just implements 480/12/1.5 by having a parallel USB2 bus the whole way. There is no conversion between the two, which also means you can't actually aggregate 480mbit devices with a USB3 hub the way you'd hope. So who knows if Corning has actually created a full implementation or also just punted.
Corning's specs state "Compatible with USB 3.0 and USB 2.0 devices", so I'm still an optimist. We tried to get one early from them, and nearly did, but ultimately couldn't. At $100, I'm sure we'll be trying it out when they're available.
Our applications already function well without isolation [1,2], but I'd love to know for certain that the last little bit of ADC noise we see is intrinsic to our readout system and not a little bit of hash on ground.
Isolating mains-powered devices sometimes is tricky, for example in one device of [1] we resorted to specially wound transformers with increased spacing to minimize capacitive coupling to mains/ground, accepting the resulting higher losses in the low-voltage power-supplies.
If you want to research if "ground loops" are indeed of concern, try to inject them artificially (split up protective earth, feed in current from a function generator) and check the influence on your measurement, then you can quantify the "ground loop rejection ratio" of your setup. This will also tell you which frequencies are most susceptible to disturbance in your specific setup.
In your paper, you seem to only have a CCD line camera taking the data, most likely it will be easier to cut open the grounding here, mount it using plastic screws and spacers, if not already done. {EDIT:} ...or not feasible because of the heatsinking...
Agreed, and we've tried that with other USB DAQ systems. The +5 rail is still referenced to the inferior ground. You can split that guy out too, and bring in external power; but then there's the question of the signal lines - to whom are they referenced, and will they function reliably?
It's so much more satisfying to know that you have truly isolated connections than to worry about whether you've gotten a complicated system laid out correctly. I don't trust me to get the details right :).
(As you say, for cleaning up AC from the mains, isolation transformers are fabulous.)
I was able to build a serial bridge between an SNES and a PC on a simple breadboard with stock parts: http://i.imgur.com/sPKGvl.jpg (the output is from a Teensy that is running as a USB<>serial device, so the PC sees it as /dev/ttyUSB0 ... the input and passthru connect DB9 to the controller port on the console, and the switch allows the original controller to work in place of the comm board.)
The Teensy driver code was around 10KB, and the PC code that opens /dev/ttyUSB0 was around 15KB.
Have been trying for over a year to implement a true USB version so that we can take advantage of the full bandwidth capability of the system, which is 2.68MB/s, which only USB high speed can do, and it's been nothing but a nightmare.
I will be really sad in the future when little toy projects like this are out of the hands of hobbyists due to costs and complexity. We've already lost that in the desktop operating system field, where video cards alone are more complex and undocumented than entire OS kernels these days.
Well, we are currently connecting to the controller port because it's really easy to connect to those. But of course you can only hammer at those registers at around 40KB/s.
So yeah, a friend made a PCB and found some female edge connectors we can cut to size to connect to the EXT port, where we can DMA at 2.68MB/s through using eight data lines. On the other side of the PCB, we just stuck a custom sized 28-pin IDE header. Easy to do whatever with that: wire to breadboard one-at-a-time or with an IDE cable.
The hope would be to then have some device that monitors each clock rise, grab the eight bits on the data bus, and send it to the PC. It can buffer a bit and have some latency, that's not a big deal.
But even with ICs that can latch the data quickly enough, we don't have enough bandwidth over serial nor USB1 to send 2.68MB/s of data. It'll have to be high-speed USB2, and will almost certainly need to be some kind of custom driver, as I doubt you can do some kind of super baud-rate of 16,000,000+bps.
> It'll have to be high-speed USB2, and will almost certainly need to be some kind of custom driver, as I doubt you can do some kind of super baud-rate of 16,000,000+bps
The venerable FT232H claims "data transfer speeds up to 40Mbytes/s":
I'm not sure what is needed to actually accomplish such rates. Might be easier to do it with USB-enabled MCU. Either way, I wouldn't discount the standard USB classes too early. I'm "pretty sure" that you should be able to push some tens of Mbps through USB-CDC class.
i was plugging in a usb into the back of my computer and i saw a firewire port. wow i forgot those existed, i remember they were all the rage and going to replace usb
Seems to have forgotten that before USB any strange/unique device required an interface card. And resolving IRQ conflicts... what a giant pain. Oh and then they changed the interface bus (ISA, EISA, MCA, VLB, PCI, etc) every few years.
100 comments
[ 3.9 ms ] story [ 175 ms ] thread> But for the vast majority of devices, you had better have your driver disk handy
Driver disks... yeah, I think I remember those?
My biggest complaint with USB isn't there, the ports can be kind of fragile. Even without regular swapping (which the design seems to encourage), USB drives and cords slowly pry them out of position. Forget about the port if anyone bumps the USB stick or trips over the cord while it's plugged in.
Motorola 68K and specialized high quality embedded units? (like amiga): no it will be overprices compared to the cough future price of an evolutive PC. Which final form are below average quality and overpriced embedded devices.
Had you followed the way of the old wise and chosen motorola architecture, you would not have theses problems. :)
The IBM PC looked remarkably primitive in comparison.
Woops... disconnected the mouse/kb by mistake? off you go rebooting the computer. I think that does indeed make it a good reason to say USB is superior.
So it's automatic, and it's "plug and play" in a sense, but it's just papering over the "driver disk" problem, not really solving it (i.e., eliminating the need for the custom driver).
And if the company that made the device doesn't feel like updating their drivers... well, you're SOL, probably. Buy a new scanner.
That's kind of an absurd situation. Yes, using USB is a little smoother than it used to be, but why is this the best we can do?
But compare to linux. On windows, the first time you plug a particular model of usb device into a particular port, it takes 20 seconds to "install the driver" (and then it's almost instantaneous on future plugs of the same device into the same port). On linux, it's almost instantaneous, the first time and every time. New device, different port, still instantaneous.
It doesn't really make sense why it would take longer the first time, or need to happen again when plugged into a different port. silly windows...
This, most of all! As a non-driver-developer, this seems completely insane.
http://blogs.msdn.com/b/oldnewthing/archive/2004/11/10/25504...
Of course, autoplay has its own obvious drawbacks.
"Windows Vista with SP1 installs almost 1GB of drivers on the system to support plug and play of devices"
Iirc there was a follow up on how much they removed of this for win 7 but I can't find it now.
I have two Kindle Fires with broken micro USB ports and I've seen two LEGO NXT robotics controllers break USB B ports. Even with DB-9 connectors soldered to boards, I don't remember a lot of breakage. I think it's because those were almost always through-hole and so much today is just surface-mount so it's relying on the pads staying adhered to the board to physically hold a frequently plugged/unplugged port in place. Crazy.
#2 is actually a really big deal with developing software to interact with anything USB. Well, I should say anything based on the FTDI chipset. I don't have any experience with anything else. Which is increasingly the case, given the modern proliferation of hobbyest hardware projects. There are no connection status events. RS-232 never developed any because a loss of connection with a cable that is physically bolted into the computer should be a catastrophic event.
Oh, I cannot tell you how many hours of my life I'll never get back debugging connection status issues. And it doesn't necessarily have to be a physical break in the connection that causes the problem. It could be an every so small short in the connector that only triggers once in a blue moon when you shift yourself in your seat and accidentally bump the wire with your chair handle while also plugging in your headphones.
Luckily, the latest versions of Windows (don't look at me, clients don't seem to care that they'd save a ton of money using Linux) are pretty robust to USB connection cycles. It used to be, if you lost a connection before closing the connection, you wouldn't be able to close the connection. The USB device would get assigned to the same COM port, which you couldn't open, because you still had it open. But couldn't close. Because you lost the connection. In the later days of XP, it often led to having shutting down the program, recycling the USB connection, and start the program again. In the early days of XP, it required a whole system reboot.
#3 I don't actually begrudge anymore. It's a situation that occurred due to evolution. Regular B connectors are too big for small devices, so Mini-B was developed to accomodate. But it turned out that the design was significantly flawed, creating a board connector geometry that was not very robust against repeated pluggings and unpluggings. Micro-B was developed to be significantly stronger, to support a greater number of cycles (if you look closely, they aren't just a different shape, the pins are set in the plug completely differently). Then smartphones turned into micro-microcomputers and people started to want to plug devices into them. Suddenly, what was strictly a slave interface before, needed to have the option to become a master interface at will. USB-OTG was the result, and it's actually a rather clever compromise that maintains backwards compatibility well.
#4 can be a significant problem when doing any sort of real-time data collection. It's nearly impossible to connect a variety of sensing devices to a PC and be able to synchronize the readings of them in time. For the most part, I take the system timestamp for everything, then generate a best-fit curve and use that for my calculations. There's just no confidence in the precision of the time resolution in USB.
#5 isn't USB's fault, it's device manufacturers. Hardware developers are some of the worst programmers in the world (and yes, they will say the same thing about programmers and circuit design, but you don't see me designing circuits, now do you?). Your printer has a really shitty system for installing drivers because the driver developer can't be arsed to learn how the operating system works with drivers. And he can't be arsed because his manager is probably bugging him to "get back to real work".
His list of new problems are largely obviated by FTDI. However, FTDI has its own problems, both technical and political.
This is more of a Virtual Serial Port driver issue than an USB issue, right? USB itself always seems pretty good about connect/disconnect events (at least on Linux). However, the FTDI drivers which detect this don't have any way to pass it back to devices reading the COM port (because of RS-232 legacy, as you said).
However, for real USB devices (not FTDI/VCOM), connection event notifications shouldn't really be an issue. Yes, annoying to deal with, but at least you can detect it, unlike with serial...
I buy stocks upon stocks of micro USB cables, and I've switched to wireless charging, because I simply keep running out of them.
It's not simply me being reckless, my wife's cables wear out, as do my brother's and various friends.
Also, none of us had any of these issues back with mini-USB (though admittedly we used those cables much less than we use micro today).
What I have experienced are the connectors on the cable either breaking or ripping off of the cable. This has happened twice with a device I use regularly, with no damage whatsoever to the port.
When you say the cable wears out, do you mean the plastic-encased wire wears out, the male connector wears out, or the point where the male connector is joined to the wire wears out?
I don't do high speed data collection per se, and wouldn't know how to do it on a desktop platform even if the issue of synchronizing the ports were licked. So I shove real time functions to an outboard micro that does run in real time.
FTDI has been the best thing since sliced bread for me. It has proven to be remarkably robust and portable in my use.
I'd rather have USB than be fiddling around trying to reach thumbscrews on the back of my computer in the dark under my desk.
Besides, even PS2 connectors will come out if you yank on them hard enough. I can't remember owning a mouse with a locking cable ^^;
I think I have more RJ45 cables with broken tabs than ones with the tabs intact. And trying to keep RJ45 in place without the tab is hopeless.
Surely you could build some sort of retaining clip for a usb cable is you had to?
That in turn is hard to qualify and expensive to assemble so it adds cost all round.
edit: I suppose you could argue that something much better than USB could have been possible, but thats how it is with technology, the standard that takes off isn't necessarily the best, its just one thats _good enough_ and gets traction somehow.
For many USB devices this is also a totally feasible thing to do, too, because most USB devices that are not providing some standard interface that the operating system takes care of (keyboard, mice, controllers, tablets, mass-storage, ...) just provide some sort of service that typically only one application would interact with, so just having the driver inside that application that interacts with it works well.
http://www.youtube.com/watch?v=1pegVYODsn4
Externally symmetric yet internally asymmetric connectors demonstrate a fundamental incompetence of their designers. It baffles me that multiple people must have approved the USB connector design and we still ended up with the abomination that lives on 'til now.
So, which way does it plug in? Oh, and the USB ports on the front of my computer (tower) are vertical, nor horizontal.
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.
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.
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).
[1]: https://github.com/pbatard/libwdi/wiki/WCID-Devices
I've been looking for a USB 2.0 High-Speed (who came up with these names, where Full Speed is slower than High Speed?) opto-isolator for years. (Corning's new "3.Optical" cabling looks great, once it makes it to market)
HN have any pointers?
Edit: Looks like 3.Optical cables appeared for sale ten days ago! http://www.corning.com/news_center/news_releases/2014/201404... , http://www.eaccu-tech.com/usb-3-0-optical-cables/usb-3-optic...
Hm. They may be "for sale", but availability may be slim.
[1] http://www.digikey.com/product-detail/en/B203-101/B203-101-N...
If you look at the Tripp-Lite's installation manual [2], you'll see that the external power supply is connected to the remote unit.
[1] http://electronics.stackexchange.com/questions/27756/why-are...
[2] http://www.tripplite.com/shared/techdoc/Owners-Manual/933116...
It was a sad day when the opto-isolating ADI development board arrived and we discovered, to our chagrin, that Full Speed != High Speed. We were so stoked to have finally found it.
I don't know why bona fide high-speed isolators are not a common thing. Maybe 12Mbit ends up being sufficient for 98% of cases? It seems like the only way is to find a type of product for which they can't cheat, like those optical 3.0 cables or an actual GigE->USB protocol converter.
Then again Tripp-Lite is a big name, and you really would want some isolation for a 300ft run. Good luck!
However, don't get your hopes up for those 3.optical cables to do what you'd like either. USB3 actually just implements 480/12/1.5 by having a parallel USB2 bus the whole way. There is no conversion between the two, which also means you can't actually aggregate 480mbit devices with a USB3 hub the way you'd hope. So who knows if Corning has actually created a full implementation or also just punted.
Our applications already function well without isolation [1,2], but I'd love to know for certain that the last little bit of ADC noise we see is intrinsic to our readout system and not a little bit of hash on ground.
[1] http://arxiv.org/abs/1309.4828 [2] http://arxiv.org/abs/1401.4412
If you want to research if "ground loops" are indeed of concern, try to inject them artificially (split up protective earth, feed in current from a function generator) and check the influence on your measurement, then you can quantify the "ground loop rejection ratio" of your setup. This will also tell you which frequencies are most susceptible to disturbance in your specific setup.
In your paper, you seem to only have a CCD line camera taking the data, most likely it will be easier to cut open the grounding here, mount it using plastic screws and spacers, if not already done. {EDIT:} ...or not feasible because of the heatsinking...
[1] http://arxiv.org/abs/1302.6092
It's so much more satisfying to know that you have truly isolated connections than to worry about whether you've gotten a complicated system laid out correctly. I don't trust me to get the details right :).
(As you say, for cleaning up AC from the mains, isolation transformers are fabulous.)
USB requires a lot more work and on Windows the API is atrocious. On Linux the API (libusb) quite a bit nicer, but still a bit of work.
The plug and play part, device naming and unique identifiers are a special "joy" of USB.
If serial port is sufficiently fast I'll take it any day over USB.
The Teensy driver code was around 10KB, and the PC code that opens /dev/ttyUSB0 was around 15KB.
Have been trying for over a year to implement a true USB version so that we can take advantage of the full bandwidth capability of the system, which is 2.68MB/s, which only USB high speed can do, and it's been nothing but a nightmare.
I will be really sad in the future when little toy projects like this are out of the hands of hobbyists due to costs and complexity. We've already lost that in the desktop operating system field, where video cards alone are more complex and undocumented than entire OS kernels these days.
So yeah, a friend made a PCB and found some female edge connectors we can cut to size to connect to the EXT port, where we can DMA at 2.68MB/s through using eight data lines. On the other side of the PCB, we just stuck a custom sized 28-pin IDE header. Easy to do whatever with that: wire to breadboard one-at-a-time or with an IDE cable.
The hope would be to then have some device that monitors each clock rise, grab the eight bits on the data bus, and send it to the PC. It can buffer a bit and have some latency, that's not a big deal.
But even with ICs that can latch the data quickly enough, we don't have enough bandwidth over serial nor USB1 to send 2.68MB/s of data. It'll have to be high-speed USB2, and will almost certainly need to be some kind of custom driver, as I doubt you can do some kind of super baud-rate of 16,000,000+bps.
The venerable FT232H claims "data transfer speeds up to 40Mbytes/s":
http://www.ftdichip.com/Products/ICs/FT232H.htm
I'm not sure what is needed to actually accomplish such rates. Might be easier to do it with USB-enabled MCU. Either way, I wouldn't discount the standard USB classes too early. I'm "pretty sure" that you should be able to push some tens of Mbps through USB-CDC class.