Given this has happened time and time again, it seems like a process flaw more than a document flaw. Maybe well-meaning people just make mistakes. Or maybe people knowingly cut corners to save money (because saving on parts is a pressure that will never go away). Or something else.
So some sort of process fix seems to be needed, one that will (1) reward those who succeed and/or (2) punish those who try to get away with violating the spec and/or (3) create tools (like test equipment or certification services or processes) to make compliance easier to achieve for those who are trying to.
So, for example, could the Pi people have used some kind of device that would plug in and run through all the combinations? Or could there have been a canned list of test cases (representatives of different types of chargers, how they should behave) they should have run? Or could they have sent a prototype device off to USB Shouldn't Suck Labs to have them test it? Or email a schematic to them to have it reviewed by an engineer?
I wasn’t aware there were different specs until a few weeks ago. I’m sure the rpi4 was in development since last year. They should have tested more cables, maybe they can fix it somehow.
Given the problem description (wrong number of resistors), I doubt that they'll be able to fix it in the existing boards. I don't know how feasible it is for them to retool, but maybe we'll see a model 4.1 with an additional resistor show up at some point.
If they'd instead specified that every detachable USB C cable must be 40 Gbps / 100 watt capable, and any lower-spec cable must be captive to the device (like mouse and keyboard cables are) then this problem wouldn't have happened.
If you are specifying that every cable is going to be $30 minimum, then your spec is dead from day 0. The USB-C committee has to balance a spec that will be used by a significant chunk of the planet, not all of whom can afford expensive cables.
If all USB-C detached cables had to meet full-spec then there would be price competition.
I could see making a mistake like this. The earlier USB specs called for goofy things like grounding the shield to the enclosure entrance via parallel RC networks instead of bonding it properly, as well as adding various bypass capacitors to the data lines(!). These guidelines were poorly thought out, widely misinterpreted and even more widely ignored. They have conditioned engineers to make their own judgment calls in areas where they really should have been both more descriptive and more prescriptive, so maybe this is one of those cases.
I haven't looked at the post-USB 2 specs at all but wouldn't be surprised if they are nowhere near as clear, unambiguous, and well-thought-out as people here are saying.
Obviously not, since there is a way to get it almost right, which is what the Pi 4 demonstrates here. Experience from cryptography suggests that for a spec to be truly unambiguous, any deviation should make the implementation fail obviously in as many situations as possible.
That would have been right in line with demanding that everyone buy 65,536 IDs at a time for thousands of dollars while attempting to prohibit resale.
I started digging into USB for a project and the rabbit hole kept going deeper and deeper; I never fathomed the amount of complexity hidden under the hood of USB until I needed to start talking to a Qualcomm modem on the other side of a USB 3.0 connection (and the modem, even though it is a single device, enumerates 16+ USB 3.0 endpoints, which is a problem for a lot of ARM SoCs, or at least the vendors we tried!).
I'd assume there are a bunch of reference designs, probably provided by the USB consortium itself, which should make it unnecessary to know anything about the spec to produce a USB C port.
The hard bit is fitting all those traces (some potentially high current) around that dinky connector with 24+ ground pins - with many all trying to do the swap thing at the same time
7 bits even parity? 8 bits no parity? hardware or software flow control? how do I know the modem is connected? lots o' fun!
The specs weren’t that simple (why would a serial port connector need 25 wires?).
It’s more the implementations that were simple, going down to 5, 3 or even 2 wires (https://en.m.wikipedia.org/wiki/RS-232#3-wire_and_5-wire_RS-...)
Composing simple devices in a hierarchical address is much better than the old complex devices that had everything explained on the same datasheet, but it had 300 pages and no two devices were alike.
"The Figure 4–9 I posted above isn’t simply a rough guideline of one way of making a USB-C receptacle. It’s actually normative, meaning mandatory, required by the spec in order to call your system a compliant USB-C power sink. Just copy it."
The reason this is wrong on the Pi is not because of "a huge matrix of incompatibility", but of ignorance to a mandatory design spec that is provided to everyone already.
It seems to parallel crypto from a high level. Yes, USB-C can be complex. But they did the hard work here so: don't roll your own and use this free and complete reference implementation.
And yet people keep saying USB-C will get better, the controller will get better, the quality of USB-C cable will get better. And Time and Time again it has proved vendors only care about cost, not quality.
Maybe people remember the beginning of USB. No cable marked charging/data but some are charging-only. Different resistances interfering with charging. USB 1 hubs pretending to be 2. It was all sorted out with time. Now USB 2 seems like magic that just works everywhere, but it really used to suck. (The experience, not the tech itself)
In fact, you can buy lightning connectors that will destroy your iphone.
Poor quality implementations in order to save costs have nothing to do with USB-C vs Lightning.
In fact, because Apple charges so much to be able to build official lightning devices, people are more likely to go with unofficial cables from unknown brands. At least USB-C cables and chargers are a lot cheaper for reputed brands to manufacture officially.