I am looking at USB2 for powering a device at 5V/1A with some communication in the production setup. I will use a USB-C plug
I can use CC pins to boost the power to 1.5A if I use a USB-C port to drive it. If I use a USB-A port to drive this device, then I need data handshaking to boost the power to 1.5A (no CC pins)
I assume if I use resistors on a USB-C CC1 and CC2, then I can boost the power and do not need a Vendor ID that would cost 5000 USD per year
If I use data to boost the power, do I then need the Vendor ID?
Also, maybe to avoid the Vendor ID, use a subset VID from ST, NXP or Microchip?
Just get a USB VID/PID from MCS Electronics. Guaranteed unique, perfectly valid, but will not pass USB-IF testing.
USB can get complicated, but if you are just doing UART-style communications using CDC at less than 1 Mbps (USB full-speed), it’s not bad. Go with TinyUSB and a well-supported chip. All of the vendor-provided code also works well enough for this use case. Don’t try to write your own USB stack or complain that it should fit in less RAM/Flash, and you’ll be fine.
I’d like to bring a bit of clarification here and potentially clear up any confusion you might have through a little bit of history.
When they noticed the demand for more power than the old 500mA@5V could provide, the USB Implementers Forum came up in 2007 with USB Battery Charging (currently in rev 1.2, specification here) which, allowed devices to request 1.5A@5V while still maintaining a data link with a computer.
They later came up in 2012 with USB Power Delivery rev 1.0 which allowed for negotiation of up to 5A@20V on Type-A and Type-B connectors, but I believe in only started to get adopted with the rev 2.0 (specification here) and the introduction of the Type-C connector.
USB VID and PID are completely separate from any BC or PD consideration, they are necessary when you want to make use of the data link provided by USB, which seems to be your case so you should probably have that sorted out. But buying a VID and PID is not mandatory, as some microcontroller manufacturers will already have default ones you can use, and some dedicated chips manufacturers such as FTDI will take care of the whole USB stack for you.
USB BC has a handshake based on voltage on D+/D- lines before any data link is established. I have not clue as to how USB PD 1.0 works. USB PD 2.0/3.0 communicates over CCx lines completely separate from D+/D- lines.
So as a quick recap :
You don’t need a data link to negotiate more power.
You don’t need to buy a VID/PID to have a data link (unless you have specific needs).
PD negotiation is more complicated than using resistors on CCx pins, it requires firmware.
A chip like STMicroelectronics STUSB4500 will take care of PD negotiation without you needing to write firmware.
The PD protocol is not that complicated, I heard Dave’s rant about it in the podcast, but I’ve managed to write firmware for a Sink device in about 1500 lines, but I wouldn’t have succeeded without a protocol analyzer.
I feel like I should also mention USB Quick Charge, which is a proprietary protocol from Qualcomm that can deliver up to 1.5A@12V and that has been reverse engineered.
Just to clarify: USB-IF VID/PID is a one time purchase. Being a member of USB-IF or getting a license to use their logo, that requires a subscription/recurring payment. Although, not very clear from their website.
Or you can do what the Raspberry Pi does and pull 2.5A from a Type micro-B connector (or 3A from a Type-C) and just tell everyone in the instruction booklet to use a sufficiently rated USB power pack.
Hi @kvk,
USB 2.0 is slow speed and up to 500mA per the spec. Computers and other (somewhat) intelligent sources of power will limit you to max 500mA on a USB 2.0 port. If plugged into a USB 3.0 port, you can pull up to 900mA, but many computers can deliver more. If your device has a USB 3.1 capable power supply, or it’s plugged into a PC’s USB 3.1 port, you can pull up to 3A@5V by just setting two resistors. PD is only required if you need more than this, but the source of power is the clue here.
As a clarification, what you are describing is called “USB Type-C Current” as described in this table below taken from the USB Type-C specification. It is not as simple as “just setting two resistors” and still requires some logic circuitry.
The resistors you mention are Rp pull-up resistors on the Source side used to inform the Sink how much current the Source can provide, but this still requires the Sink to expose Rd pull-down resistors and monitor the voltage generated by this voltage divider to determine how much current it can draw.
@nicolas.schurando:
There’s a lot of documents at that site. Can I ask which one you found the table 4-17 in?
I am looking at the USB-C. I have a client which wants to run debugging signals in parallel with the standard data (I am not sure why yet). So I have been looking at using TX1+, TX1-, TX2+, TX2-, RX1+, RX1-, RX2+ and RX2- for other purposes, using D+/D- for communication
Those other purposes will only be for a test setup, so the USB-C cable will be plugged into a breakout box that will let only D+/D- go to the computer along with VBUS. The other signals will run into a separate debugging unit
I guess RX1 is 3V compliant, so if the debugging signals is present when the USB-C cable is plugged directly into the computer, nothing will happen, since it has not negotiated use of the other data channels
True. And on paper that’s a lot simpler. But given that a chip like the STUSB4500 I mentioned earlier makes the complexity of PD disappear, I’d personally still go with PD.
No, I would not make the assumption.
A compliant USB2.0 host device does not need to implement support for the Battery Charger Spec.
Another can of worms in the mix… If you are planning on using the PD protocol, or the CC pins options, do you have a plan for how to deal with ports that report they cannot supply the requested power? Because this is a possibility.
I think a lot of consumer PC peripherals still come with external power bricks for this very reason, in order to fully support backwards compatibility you cannot make use of some newer features.
The behavior you’re describing is ok. It would fall into the USB-C “Debug Accessory Mode”.
There are some hardware consideration you need to follow in order for an upstream port to correctly detect this mode and not attempt to drive USB3 signals.
See: Appendix B of the USB Type-C Cable and Connector Specification.
You mention that you are planning on using an in-line breakout to remove these debug signals before a PC. I’d still recommend trying to follow this specification so that in the event someone just uses a standard cable, without the breakout, nothing breaks.
Correct. I was thinking to use the TX/RX signals, and use them within the specs of the standard. That way if someone hooks it up with a fully populated cable to a USB C port, nothing happens
In the test equipment, I can then add the breakoutbox, to disconnect the PC USB-C port (except for power and D+/D-), and the couple the TX/RX wires with my own protocol to the unit
I second what @gregdavill said. It is tempting to route the debug signals directly in the connector, but your product will likely be safer in the wild only exposing those signals when you expect it to.
If I recall correctly Debug Accessory Mode requires the detection of some resistors, so still a bit of logic needed but maybe some ICs could take care of that for you.
I’d be curious to know what you end up doing, keep us updated!
