USB notes: Difference between revisions

From Helpful
Jump to navigation Jump to search
 
(13 intermediate revisions by the same user not shown)
Line 84: Line 84:
'''"Do you need to 'Safely Remove Hardware'?"'''
'''"Do you need to 'Safely Remove Hardware'?"'''


It's often not necessary.
tl;dr: mostly it's fine, though it's not a guarantee, and a few specific things can cause issues - mostly breaking off in the middle of a write.  
So if it involves storage, you probably want to play it safe


...yet if you want to be sure, it's still a good idea to do.
And somewhat simpler in that the explanation ''why'' is a bit longer than you want to remember.




<!--
'''At USB level''' this is easier to answer: at an electric level, and protocol level, USB was made to be hot-pluggable.
tl;dr:
Nothing will spark, and the host will almost certainly figure out a device left, even if it left in the most awkward way.
: if something is itneraction (keyboard, mouse, webcam), why would you care a little lost data?
 
: if it's not in use, it's fine (but it's not always easy to tell)
If the driver or computer crash, that is considered a bug and not your fault, so that's often resolved in testing
: if it involves storage, you probably want to play it safe
and generally does not work its way into serious products.
-->
 


The real question is what the thing on top is doing.
Say, when your device will involve a higher-level APIs in the OS (like "open sound device" and "open video device"),
you will find that they did not have changing devices in mind.


At an electric level, and protocol level, USB was made to be hot-pluggable.
More recent APIs are better with hardware that disappears and reappears at will,
Nothing will spark, and the driver and computer shouldn't crash.  
but even then, it is up to each application to deal with the same thing -- it is tempting to
write something that only scans for devices at startup, and assumes it won't change during ''use''.
Which for most uses is entirely fair.




Most drivers for USB devices are also forgiving about disconnect and reconnect - they mostly have to be.


Higher-level APIs (like sound and video) didn't use to be made with changing devices in mind. More recent variants are better.
* It depends a little on whether the thing it was doing is important to you.
: If this is a keyboard, mouse, webcam, MIDI interface, losing a few packets is irrelevant next to the fact the devise is no longer there to be used, nor was the data very important.




Apps may still not be happy, but not dealing with this is to some degree considered a lazy bug.
* It depends a ''little'' on the specific hardware and drivers.
: For custom software for custom firmware on custom hardware, even if there's nothing to corrupt by breaking of a write, you might still get it into some weird state - so you often can't really know for ''sure''.
: Yet for things like USB storage, webcams, and such, the OS-level drivers are a known quantity.


And to some degree a question of "if it was still doing something, was that important to you?"




Say, a sound card, webcam, keyboard or mouse, even if it's still transferring, probably doesn't do or store anything you would care about losing.
'''For storage'''


For a sound card, webcam, keyboard or mouse or such, you won't care to completely lose the packets it's currently transferring.


Storage, on the other hand, often does - anything from a USB stick, memory card, external hard drive, connected cameras in storage mode.
For storage, on the other hand, you usually will - anything from a USB stick, memory card, external hard drive, connected cameras in storage mode.


Disconnecting a drive while running originally wasn't a ''thing'', so filesystem APIs assume that a file stays open and available until the ''program'' that opened it says it is done.
Disconnecting a drive while running originally previously wasn't a ''thing'',  
so filesystem APIs assume that a file stays open and available until the ''program'' that opened it says it is done.




'''Yanking while reading''' from a external storage will almost certainly make the reading program unhappy,
'''Yanking while reading''' from a external storage will almost certainly make the reading program unhappy,
yet the storage itself is typically fine.
yet the storage itself is typically fine.


'''Yanking while writing''' is usually bad.
'''Yanking while writing''' is usually bad.
Line 129: Line 135:




There is a common optimization in "keep the last seconds worth of data before actually writing it" (see writeback versus writethrough).
This optimization is usually disabled for USB-connected storage - except when it's not.
Also, certain kinds of storage (non-ssd flash) erases a block before rewriting it,
so there is a time at which only the host knows the data.
So you can expect USB flash sticks to corrupts a little more easily while writing (SSDs, while based on Flash as well, have a more complex, smarter controller that avoids at part of that issue and should be more recoverable).


<!--
There are further notes.
There are further notes.


Line 149: Line 163:
:... in that it's probably in a consistent state. The filesystem ''may'' still record that you didn't unmount it, and the next system may read that out and want to do a consistency check - but it will probably find it perfectly fine.
:... in that it's probably in a consistent state. The filesystem ''may'' still record that you didn't unmount it, and the next system may read that out and want to do a consistency check - but it will probably find it perfectly fine.


 
-->
USB flash corrupts a little more easily while writing, because of how Flash works: writing small pieces of data to [[flash memory]] involves a read-erase-write cycle, leaving time in which the data is ''not'' on storage, and a non-obvious state to recover (SSDs, while based on Flash as well, have a more complex, smarter controller).




Line 624: Line 637:




===Shortish version===
USB3 and USB-C as a plug made things more capable -- but also more negotiated and more varied,
so harder to understand and to explain.


'''USB-C'''
* various things may choose to charge slower


* without PD, the specific case may limit you to USB2 and USB3 limits (500mA; 900mA or 1,500mA for dual-lane), or not (3A) {{verify}}
===Attempt at shortish answer===
:: ...at 5V, that means one of so 2.5W, 4.5W, 7.5W, 15W
====Power and charging before USB-C====


* USB-C with [https://en.wikipedia.org/wiki/USB_hardware#USB_Power_Delivery Power Delivery]
* '''On a PC''':
:: and standard cable, it probably won't try for more than 3A at 20V (for 60W)
: USB1 or USB2 root hubs (&#x2248;the port inside a PC/laptop)
:: and a heavier cable, it can try up to 5A at 20V (for 100W)
:: are more or less guaranteed to give 100mA without ever running into trouble
:: ..but there may be practical reasons any one case may not go that high
:: ''may'' supply up to 500mA after negotiation (0.5A at 5V is 2.5W)
 
:: ...and since they
This means laptops can now use one of their USB-C plugs as a power plug, which is nice to minimize the amount of sockets,
but note that not all chargers or cables will be equal here, and it's possibly there are preferred ports to do this on{{verify}}.


: USB3 root hubs guarantees 150mA and ''may'' supply up to 900mA after negotiation
: ...'may', because the PC may deny it when it knows the total device draw is more than it has, which happens more easily when you add external hubs


'''before USB-C'''


* '''On a PC''':
* external hubs
: a USB1 or USB2 root hub more or less guarantees 100mA, and ''may'' supply up to 500mA after negotiation (0.5A at 5V is 2.5W)
:: when they have their own power supply, they can guarantee the same as above
: USB3 guarantees 150mA and ''may'' supply up to 900mA after negotiation
:: when they do ''not'' have their own power supply, they effectively draw one port's worth, and supply all of their own -- part of why they're often 3 or 4 port{{verify}} (500mA into four 100mA devices is usually fine)
: ...'may', because the PC may deny it when it knows the total device draw is more than it has, which happens more easily when you add external hubs




* '''generic wallplug chargers'''
* '''generic wallplug chargers'''
: when something doesn't present as a USB host at all, it's up to devices to behave reasonably
: when something doesn't present as a USB host at all, it's up to devices to behave reasonably
: if a device cannot or does not check capability, they often draw at most 0.5A, but often less.
: (we thought up some extra conventions)
: if a device cannot or does not check capability, they often draw at most 0.5A, but often less {{comment|(0.5A is technically a violation of specs, but they're not even pretending to try to adhere to them, sooo)}}




Line 662: Line 673:
: there were various non-standardized ways of doing this (many involved putting some voltage dividers on the data lines) - Battery Charging came later.
: there were various non-standardized ways of doing this (many involved putting some voltage dividers on the data lines) - Battery Charging came later.
: Names seem to include
: Names seem to include
:: QuickCharge (from Quallcomm)
:: QuickCharge, QC (from Quallcomm), o
:: TurboPower (from Motorola)
:: TurboPower (from Motorola)
:: Adaptive Fast Charging (from Samsung)
:: Adaptive Fast Charging (from Samsung)
Line 673: Line 684:
:: iSmart (from RavPower)
:: iSmart (from RavPower)
: ...and more variations, as well as more rebrandings. These still tend to be designed for at most 10W, 15W or 20W (because of the mentioned wire thing) but are more likely to actually do more than standard 2.5W.<!-- https://www.extremetech.com/computing/115251-how-usb-charging-works-or-how-to-avoid-blowing-up-your-smartphone -->
: ...and more variations, as well as more rebrandings. These still tend to be designed for at most 10W, 15W or 20W (because of the mentioned wire thing) but are more likely to actually do more than standard 2.5W.<!-- https://www.extremetech.com/computing/115251-how-usb-charging-works-or-how-to-avoid-blowing-up-your-smartphone -->


* '''[https://en.wikipedia.org/wiki/USB_hardware#USB_Battery_Charging Battery Charging]'''
* '''[https://en.wikipedia.org/wiki/USB_hardware#USB_Battery_Charging Battery Charging]'''
Line 693: Line 705:


https://www.usb.org/sites/default/files/USB%20Type-C%20Spec%20R2.0%20-%20August%202019.pdf
https://www.usb.org/sites/default/files/USB%20Type-C%20Spec%20R2.0%20-%20August%202019.pdf
-->
====Power and charging with USB-C====
* without PD, the specific case may limit you to USB2 and USB3 limits (500mA; 900mA or 1,500mA for dual-lane), or not limit you to that (allowing 3A) {{verify}}
:: ...at 5V, that may mean any of 2.5W, 4.5W, 7.5W, or 15W
* USB-C with [https://en.wikipedia.org/wiki/USB_hardware#USB_Power_Delivery Power Delivery]
:: and standard cable, it probably won't try for more than 3A at 20V (for 60W) 
:: and a heavier cable, it can try up to 5A at 20V (for 100W)
:: ..but there may be practical reasons any one case may not go that high - like that most devices don't need that
* Some of those are now enough to meet the basic power draw of a laptop, meaning that laptops can now choose to use one of their USB-C plugs as a power plug
: at the same time not all chargers or cables will be equal here (and it's possibly there are preferred ports to do this on{{verify}})
* various smarter things may ''choose'' to charge slower
: (e.g. when it notices the adapter or cable doesn't seem to manage)
: ...so it can be hard to estimate how much faster something will charge, ''particularly'' for smarter devices
<!--
5V  3A    for 15W
9V  3A    for 21W
12V 2.5A  for 30W
15V 2A    for 30A
20V 1.5A  for 35W
-->
-->


Line 702: Line 739:




Since  
Since phones may have batteries on the order of 10Wh, that means charge will rarely take less than 4 hours - and easily double that when some part of the system is being careful
: phones may have batteries on the order of 10Wh, that means charge will rarely take less than 4 hours - and easily double that when some part of the system is being careful


: laptops have batteries on the order of ~100Wh, that means a charge would take dozens of hours -- which is why we don't use USB to charge them (before USB-C, anyway)
Since laptops have batteries on the order of ~100Wh, that means a charge would take dozens of hours -- which is why we, before USB-C, we didn't try to use USB to charge them


===PC port limits===
===PC port limits===
Line 714: Line 750:




Implementations play it a little wider than that, to avoid disconnecting devices due to transients and slight deviation -- because polyfuses may, by nature, not reset until power is removed, which is why you sometimes need to completely power off a device to get that port working again.
Implementations play it a little wider than that, to avoid disconnecting devices due to transients and slight deviation -- because polyfuses may, by nature, not reset until power is removed, which is why you sometimes need to completely power off a computer {{comment|(and sometimes even take the laptop's battery out)}} to get that port working again.


So USB2 polyfuses seem to have a trip current around 1.5A, and also a higher-than-500mA hold current (I've seen 750mA mentioned)
So USB2 polyfuses seem to have a trip current around 1.5A, and also a higher-than-500mA hold current (I've seen 750mA mentioned)
Line 729: Line 765:
And if you ever made your project into a product, it would need to actually request it to pass USB certification.
And if you ever made your project into a product, it would need to actually request it to pass USB certification.


Note also that since you are defeating the thing that lets USB guarantee power is actually available, so by cheating this way ''may'' be able to cause all USB devices that sharing that power to [[brown out]], something normally prevented by USB.
Note also that since you are defeating the thing that lets USB guarantee power to its devices,  
 
you may be able to cause all USB devices that sharing that power to [[brown out]],
<!--: There seem to be real-world devices that cheat, like Y cables that plug into two USB ports, one of them taking power and speaking data, and the other just taking more power. I assume this is still to specs, or may be a loophole.-->
something normally prevented by in-spec USB (at least in theory).
 
 


<!--
There seem to be real-world devices that cheat, like Y cables that plug into two USB ports, one of them taking power and speaking data, and the other just taking more power. I assume this is still to specs, or may be a loophole.
-->


<!--
<!--
Line 782: Line 819:


* https://www.maximintegrated.com/en/app-notes/index.mvp/id/4803
* https://www.maximintegrated.com/en/app-notes/index.mvp/id/4803


===Hub limits===
===Hub limits===
Line 843: Line 879:
====USB-A to USB-C doesn't charge====
====USB-A to USB-C doesn't charge====
<!--
<!--
So, there are two different cables we could be thinking about here:
* USB3 A to C
* USB2 A to C - seems less common, ''except'' in cheap cables




This sort of cable tends to connect only the USB2 power and data, and sticks to USB2 limits (2.5W on a real host, and even then only if it asked nicely and got the OK).
This sort of cable tends to connect only the USB2 power and data, which means devices will sticks to USB2 limits at best (2.5W on a real host, and even then only if it asked nicely and got the OK).


On an adapter it is easier to get 5 or maybe 10W charging (resistor tricks signaling this is allowed - not standard but common enough),
On an adapter it is easier to get 5 or maybe 10W charging (resistor tricks signaling this is allowed - not standard but common enough),
Line 851: Line 891:




This sounds like USB-A to USB-micro-B, but an added detail in USB-A to USB-C cables is that they are expected to have a pullup on CC to signal that the other end ''isn't'' USB-C, and what the current limit is -- and it seems not all cables do {{comment|(This seems to be largely early cables, either because engineers didn't notice, or because there were some cases of intentionally violating specs to get enough charge through if they didn't. Probably there are some knockoff cables that still have this issue)}}.
This sounds like USB-A to USB-micro-B, but an added detail in USB-A to USB-C cables is that they are expected to have a pullup on CC to signal that the other end ''isn't'' USB-C, and what the current limit is -- and it seems not all cables do {{comment|(This seems to be largely early cables, either because engineers didn't notice, or because there were some cases of intentionally violating specs to get enough charge through if they didn't. Likely there are some knockoff cables that still have this issue)}}.
 
 
When not on a real host, it seems
: some devices will conclude they can draw maybe 3A
:: but when they try, they will probably cause the supply to mess up
:: or, less commonly, for the cable to get too hot


When not on a real host, it seems some devices will conclude they can draw maybe 3A and probably cause issues,
: other devices will consider this dangerous and reject this case - meaning it fail to work, which might be preferable to the charger melting
and a few devices will consider this dangerous and reject this case.
Either way, it may fail to work (which can be preferable to the charger melting).


Both of the last cases means the same cable may charge one device and not on another.
: other devices yet may do the "I will draw more until I see the voltage drop"
 
A good amount of these cases means the same cable may charge one device and not another.




Line 864: Line 910:
https://hackaday.com/2023/01/04/all-about-usb-c-resistors-and-emarkers/
https://hackaday.com/2023/01/04/all-about-usb-c-resistors-and-emarkers/


-->


-->
===USB-C and DIY===
===USB-C and DIY===
<!--
<!--
Line 883: Line 929:


<!--
<!--
In USB-C, the cable should have pullups to signal the current limit,


Regardless of how much they asked for or resistors may suggest you may draw,
Regardless of how much they asked for or resistors may suggest you may draw,
devices that want to charge faster are expected to monitor the voltage - and more complex devices like phones often do.  
devices that want to charge faster are expected to monitor the voltage - and more complex devices like phones often do.  


This may mean they increase current until the voltage drops, intended to draw no more than the supply is comfortable with.
 
This may mean they increase current until the voltage drops.
This should draw no more than the supply is comfortable with.


Cables with overly thin wires means that voltage drops even with low currents, and may be the reason  
Cables with overly thin wires means that voltage drops even with low currents, and may be the reason  




In USB-C, the cable should have pullups to signal the current limit,  
 
-->
 
 
 
==PTP, MTP, and more==
 
<!--
PTP has been around for a long while, connecting digital cameras since the early noughts.
It is not strictly tied to USB, but mostly seen there.
 
https://en.wikipedia.org/wiki/Picture_Transfer_Protocol
 
 
MTP is an extension of PTP that supports more media types. It was a bit Windows-focused, which is why it has been supported since later in the early noughts.
 
 
Android phones have
* File transfer
* PTP
* MIDI (USB-MIDI)
* USB Tethering
 
'File transfer' seems to actually be MTP (even though it shares the [[USB class]] with PTP)
 
Nothing uses 'USB mass storage', the way, because that effectively requires exclusive access.
 


-->
-->

Latest revision as of 09:16, 4 March 2024


Connectors

See Common plugs and connectors#USB


Hardware variants

PC controllers will be one of

  • OHCI (Open Host Controller Interface)
    • USB 1
    • Open standard
  • UHCI (Universal Host Controller Interface)
    • USB 1
    • Proprietary standard
    • Intel and VIA are usually UHCI
  • EHCI (Enhanced Host Controller Interface)
    • USB 2
    • public (open?) standard
  • XHCI (eXtensible Host Controller Interface)
    • USB 3
    • in theory replaces OHCI, UHCI, and EHCI


See also:


Speeds

  • USB1 "Low speed"
    • ~178KByte/s (1.5 Mbit/s) of wire speed, max max ~120KByte/s of carried data due to 8b/10b coding (not yet accounting for protocol overhead)
    • Meant for devices that will never need much speed, such as keyboards
  • USB1 "Full speed"
    • 1.5MByte/s (12 Mbit/s) wire speed, ~1.2MByte/s of carried data
  • USB2 "High speed"
    • 60MByte/s (=480Mbit/s) wire speed, ~48MByte/s carried data
    • expect no more than 30MByte/s, and 25MB/s is more common (apparently because of offloading(verify))
  • USB3 "Superspeed+"
    • 625MByte/s (5Gbps) of wire speed, ~500MByte/s (4Gbps) carried data
    • Note: May do USB2 devices a little faster (as in, may reach 30-40MByte/s where many USB2 controller may stop at ~25MByte/s) (verify)
    • expect no more than ~400MB/s usually
  • USB3.1 "Superspeed+"
    • 1250MByte/s (10Gbps) of wire speed, before 128b/132b coding, ~1200MByte/s (~9Gbps) carried
    • expect no more than ~900MByte/s usually


Notes:

  • Hubs share speed.
  • PC USB ports often come as two ports side by side on a hub, so share their speed
This means e.g. copying between two adjacent ports may happen at half the speed you expected.
(at least up to USB2 - USB3 became smarter about a few cases(verify))
  • USB3 modes are full-duplex, everything before was half-duplex
  • I'm ignoring USB4 for now

Related to use

Unplugging USB

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

"Do you need to 'Safely Remove Hardware'?"

tl;dr: mostly it's fine, though it's not a guarantee, and a few specific things can cause issues - mostly breaking off in the middle of a write. So if it involves storage, you probably want to play it safe


At USB level this is easier to answer: at an electric level, and protocol level, USB was made to be hot-pluggable. Nothing will spark, and the host will almost certainly figure out a device left, even if it left in the most awkward way.

If the driver or computer crash, that is considered a bug and not your fault, so that's often resolved in testing and generally does not work its way into serious products.


The real question is what the thing on top is doing. Say, when your device will involve a higher-level APIs in the OS (like "open sound device" and "open video device"), you will find that they did not have changing devices in mind.

More recent APIs are better with hardware that disappears and reappears at will, but even then, it is up to each application to deal with the same thing -- it is tempting to write something that only scans for devices at startup, and assumes it won't change during use. Which for most uses is entirely fair.


  • It depends a little on whether the thing it was doing is important to you.
If this is a keyboard, mouse, webcam, MIDI interface, losing a few packets is irrelevant next to the fact the devise is no longer there to be used, nor was the data very important.


  • It depends a little on the specific hardware and drivers.
For custom software for custom firmware on custom hardware, even if there's nothing to corrupt by breaking of a write, you might still get it into some weird state - so you often can't really know for sure.
Yet for things like USB storage, webcams, and such, the OS-level drivers are a known quantity.


For storage

For a sound card, webcam, keyboard or mouse or such, you won't care to completely lose the packets it's currently transferring.

For storage, on the other hand, you usually will - anything from a USB stick, memory card, external hard drive, connected cameras in storage mode.

Disconnecting a drive while running originally previously wasn't a thing, so filesystem APIs assume that a file stays open and available until the program that opened it says it is done.


Yanking while reading from a external storage will almost certainly make the reading program unhappy, yet the storage itself is typically fine.

Yanking while writing is usually bad.

Most filesystems write file data in-place (meaning they do not implement a guaranteed recovery)
A number of filesystems are a little more robust about filesystem metadata - but you shouldn't assume it


There is a common optimization in "keep the last seconds worth of data before actually writing it" (see writeback versus writethrough). This optimization is usually disabled for USB-connected storage - except when it's not.


Also, certain kinds of storage (non-ssd flash) erases a block before rewriting it, so there is a time at which only the host knows the data. So you can expect USB flash sticks to corrupts a little more easily while writing (SSDs, while based on Flash as well, have a more complex, smarter controller that avoids at part of that issue and should be more recoverable).

USB Device Not Recognized / Device has malfunctioned

Shown in a balloon near the task bar, with the addition that "One of the USB devices attached to this computer has malfunctioned, and windows does not recognize it."

(In some cases, if the balloon message is disabled, the device only shows up as an "Unknown Device" in the device manager.)(verify)


My summary so far is that there are many possible causes, it's hard to say which one it is, and most solutions are not very clearly good ones. Reinstalling usually won't help.


Possible problems/solutions

Things you can check easily enough:

  • broken device
    • test: try in other computers - and to be sure, also with varying OSes (some devices don't have drivers for older/specific OSes)
  • broken cable (cables get stepped, yanked, etc.)
    • if it's interchangeable, try another one.
    • If it's not interchangeable, try wiggling it to see if it accidentally makes a good contact. It's not a very good test in that it not working means nothing, but if it turns up temporarily, you know that a bit of DIYing may well fix the problem.
  • broken USB socket
    • Test: Try other things in the same port, and try this device in other ports
    • Note: each pair of ports is usually the same internal hub, so only trying the one right next to it is not the best test.
    • Basic mice are the most useful test devices, as they are low-power and do not require drivers to work
  • USB port in a weird state (e.g. the previous device drew too much power and triggered the polyfuse. But there is another reason or two)
    • (some are more sensitive/careful than others. Macbook polyfuses were apparently known for triggering quickly)
    • Test/fix: Turn computer off completely, and then leave the power cord/battery out for a few minutes (that much is rarely necessary, but sometimes it is and it takes less time to wait a bit longer once than to reboot again)
  • USB knows you are crossing the limit of power it can give out, and refuses the next device
    • more likely to happen on a non-powered hub
    • Test: try plugging the device into the computer itself (or into a powered hub that has no high-powered devices)
      • Front ports may sometimes be non-powered hubs, so a back (motherboard) port may be a better test.
    • Test: try a mouse in the same port - it's low-power and so very likely to work if the port's not broken.


Harder to check well:

  • stupid/missing driver for the particular device
    • Test: Try again after a restart, try with different OS, try with a different driver,
  • stupid power management bug (happens on some hardware)
    • There is/was a bug in XP(/Vista?) where power-suspended USB ports are not re-enabled properly, and there were mixed reports about Microsoft's patches (verify). Some people report that disable this port suspending feature helps.
  • windows USB driver set/setup got wonky.
    • Bit of a last resort thing to check
    • Test/fix: Uninstall as many related drivers as you can before plugging the devices back in.
  • some devices don't like sleep/hibernate, regardless of version of anything
and may stay confused until a reboot


It seems that certain devices are likelier to trigger this problem.





It seems that Windows's collection of drivers for USB devices (one or more) can get wonky. It may be that reinstalling all of these can help. Remove controllers drives last, so peripherals drivers first. Then rebooting and let it re-detect and re-install everything.

See also

Speed and latency

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


tl;dr

"Do hubs, shared cables, etc. affect speed?"

On poll rate

Can we go lower?

Why do some devices only work on PC ports, not from hubs?

Notes on slow USB3

On USB power and charging

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

USB only accidentally became a standard for charging things, which is why the history of transferring more power through it is interesting.


USB3 and USB-C as a plug made things more capable -- but also more negotiated and more varied, so harder to understand and to explain.


Attempt at shortish answer

Power and charging before USB-C

  • On a PC:
USB1 or USB2 root hubs (≈the port inside a PC/laptop)
are more or less guaranteed to give 100mA without ever running into trouble
may supply up to 500mA after negotiation (0.5A at 5V is 2.5W)
...and since they
USB3 root hubs guarantees 150mA and may supply up to 900mA after negotiation
...'may', because the PC may deny it when it knows the total device draw is more than it has, which happens more easily when you add external hubs


  • external hubs
when they have their own power supply, they can guarantee the same as above
when they do not have their own power supply, they effectively draw one port's worth, and supply all of their own -- part of why they're often 3 or 4 port(verify) (500mA into four 100mA devices is usually fine)


  • generic wallplug chargers
when something doesn't present as a USB host at all, it's up to devices to behave reasonably
(we thought up some extra conventions)
if a device cannot or does not check capability, they often draw at most 0.5A, but often less (0.5A is technically a violation of specs, but they're not even pretending to try to adhere to them, sooo)


  • specific chargers
proprietary, often specific to brands
amounts to specific devices checking for specific chargers.
and sometimes negotiating for a higher voltage as well.
they may draw up to 1A or 2A, at 5V or sometimes higher.
The range here is 5W to at most 20W -- largely because wires used in USB2 cables cannot support more.
there were various non-standardized ways of doing this (many involved putting some voltage dividers on the data lines) - Battery Charging came later.
Names seem to include
QuickCharge, QC (from Quallcomm), o
TurboPower (from Motorola)
Adaptive Fast Charging (from Samsung)
SuperCharge (from Huawei)
Pump Express (from Mediatek)
PowerIQ (from Anker)
VOOC (from OPPO), a.k.a. Dash Charge
AiPower (from Aukey)
VoltIQ (from TronSmart)
iSmart (from RavPower)
...and more variations, as well as more rebrandings. These still tend to be designed for at most 10W, 15W or 20W (because of the mentioned wire thing) but are more likely to actually do more than standard 2.5W.


introduced later (well after many not-so-standards, mentioned above)
up to 1.5A (which is 7.5W), but devices may play it safe and don't try more than 0.5A (2.5W).
no specific logo, either labeled or you have to know(verify)
I should read it, but I'm guessing it says you should only draw current until the voltage starts drooping - basically not going beyond current capability



Power and charging with USB-C

  • without PD, the specific case may limit you to USB2 and USB3 limits (500mA; 900mA or 1,500mA for dual-lane), or not limit you to that (allowing 3A) (verify)
...at 5V, that may mean any of 2.5W, 4.5W, 7.5W, or 15W
and standard cable, it probably won't try for more than 3A at 20V (for 60W)
and a heavier cable, it can try up to 5A at 20V (for 100W)
..but there may be practical reasons any one case may not go that high - like that most devices don't need that
  • Some of those are now enough to meet the basic power draw of a laptop, meaning that laptops can now choose to use one of their USB-C plugs as a power plug
at the same time not all chargers or cables will be equal here (and it's possibly there are preferred ports to do this on(verify))
  • various smarter things may choose to charge slower
(e.g. when it notices the adapter or cable doesn't seem to manage)
...so it can be hard to estimate how much faster something will charge, particularly for smarter devices


Using USB to charge batteries

In general, don't count on classical USB supplying more than 2.5W (standard)

...or 5W or 10W if slightly special (not so standard).


Since phones may have batteries on the order of 10Wh, that means charge will rarely take less than 4 hours - and easily double that when some part of the system is being careful

Since laptops have batteries on the order of ~100Wh, that means a charge would take dozens of hours -- which is why we, before USB-C, we didn't try to use USB to charge them

PC port limits

It's often mentioned that USB ports have a polyfuse - a physical component specced so that drawing more than e.g. 500mA will lead to that power being disconnected.

(There are other solutions. A few implementations actually monitor current, and use transistors to disconnect(verify), and in some rare cases the protection is missing)


Implementations play it a little wider than that, to avoid disconnecting devices due to transients and slight deviation -- because polyfuses may, by nature, not reset until power is removed, which is why you sometimes need to completely power off a computer (and sometimes even take the laptop's battery out) to get that port working again.

So USB2 polyfuses seem to have a trip current around 1.5A, and also a higher-than-500mA hold current (I've seen 750mA mentioned)

Roughly twice that for regular USB3 ports (ports can supply 0.9A as per specs)

More so for charging ports (how much?(verify)).


DIYers will know from trial and error that you can get away with just ignoring the intended negotiation and drawing 0.5A from a USB2 PC port without requesting it (0.9A from USB3 as per specs)

...because most hosts/hubs just assume USB devices act according to specs, they assume you would always ask not just draw it. And if you ever made your project into a product, it would need to actually request it to pass USB certification.

Note also that since you are defeating the thing that lets USB guarantee power to its devices, you may be able to cause all USB devices that sharing that power to brown out, something normally prevented by in-spec USB (at least in theory).





Hub limits

USB-C won't charge

USB-C to USB-C doesn't charge

USB-A to USB-C doesn't charge

USB-C and DIY

Why do some cables charge faster than others?

PTP, MTP, and more

USB OTG

Related to coding

on libusb and platforms

A primer, some terminology

HID

Keyboard limitations

Can I write and use my own USB drivers for a device?

Can I give my DIY device a custom name?

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

tl;dr: not really



This would mostly just matter to what is shown in device manager. This might be nice for the convenience of admins.

Or, in theory, to avoid getting confused which of the many attached Arduinos you need to upload to, except that the name for a device is essentially settled by its VID and PID, so that won't work.


In Windows there is a registry trick to effectively override the name reported by a driver - but that would be for all devices that that driver applies to.

To get it to look distinct, you would really need a different PID. Which which reduces the answer to the one as "can you supply your own USB drivers", because that's roughly what it would amount to.

That said, changing only the name apparently means you don't need to alter the driver itself, just the INF around it[1] which is within reach.