> By "that mode", do you mean "1.5A @ 5V" permitted by BC
Neither - OP means devices with missing CC resistors which will fail to charge with a compliant PD source. (The A-to-C cable works because it provides 5V Vbus unconditionally.)
That's close, but it's not quite complete. There seems to be lots of confusion here, and that's natural: It is confusing.
For just-getting-power from a USB A port into a USB C peripheral: There are supposed to be 2 resistors in the peripheral device [always], and also 1 resistor within the cable for USB-to-legacy cables[1]. That's 3 resistors, total, to get a relatively dumb USB-C equipped peripheral device to reliably charge from both USB A and USB C hosts/chargers/whatevers:
The cable itself: It gets an internal 56k pullup resistor between Vbus and USB C pin A5 -- which is the CC line [yes singular]). This resistor signifies the capabilities of the host/charger/whatever for devices that care (some do care, some do not care).
The peripheral: This minimally needs two pulldown resistors [commonly 5.1k], between each of CC1 and CC2 [yes a plurality] and ground[2]. This tells a compliant USB C host/charger/whatever "It's OK! Send the juice juice!" regardless of connector orientation.
[bleh]: Again, it is a confusing thing. Nobody said that dealing with such flexible, ambidextrous connections would be simple. CC performs a lot of different tasks: It can be a bidirectional serial bus for active PD negotiations, and/or a resistor network for passively dealing with power, and it's the bit that performs detection of cable orientation for applications where that matters, and it probably does other stuff too.
That single little wire is clever AF. It'd be simpler to use multiple wires instead of just one, but that would take more copper. Copper is expensive, and we each save a tiny bit of money (or a large pile of money globally) by using less copper instead of more of it.
My point, which matches what you've written out in more detail, is that there's supposed to be stuff (resistors) in the cable, stuff which is often not there. There are plenty of these abhorrent cables in the wild. And when you come across one, things get weird, because some sources and sinks deviate from the standard in ways that make them work with these bad cables. Others don't do that. (I believe there were a lot more abhorrent cables in the early days, and thus began the chain of accommodation....)
So unless your cable is known-good, if you are having trouble, trying a different cable should be the first thing you do. It really does often get things working.
Contrarily, if you have identified a naughty cable, it should be immediately widlarized.
I gathered that you knew that. I'm mostly just trying to complete the picture for those following along at home, who might find some of this resistor business to be a bit weird compared to the USBs of yore.
Except the old ways were weird in unseen ways, too. Some combinations of cable, phone, and charger worked well and some barely worked at all.
We're in much better shape with USB C and PD. It's generally a good, forward-looking way of doing all kinds of things.
I just wish the cables and ports were better-marked, and that manufacturers stopped fucking around by making non-compliant stuff, and that there were a clear way with two battery-equipped USB C devices to unequivocally declare that a particular one will charge the other (and not the other way 'round).
And yes: The non-compliant widgets should ideally be named, shamed, and Widlarized -- not simply tolerated or worked around.
A-C cable assembly always works, CC signal is connected within the cable to Vbus via 56kOhm resistor, but that's only relevant to the downstream port, not to the upstream USB-A power sourcing port which does not have access to the CC signal. Upstream port provides power unconditionally within some limits depending on port type (CDP/DCP/USB3.0/2.0 data port/...).
> Usually the best place to fix it is by getting rid of the bad cables. Usually.
No. There is no USB-C to C cable that will charge a badly implemented device with a standards compliant charger. That is the entire point.
An USB A to C cable is completely standards-compliant and safe, even if it always supplies 5V on the C end - any standards compliant USB-C device should not activate the MOSFET on its Vbus line unless it successfully negotiates via CC.
They mean bad USB-A to C cables with no resistor on CC line. Of course this is broken junk which will work with some devices and won't with others. I've also seen cables with resistors on both CC lines, which is also broken but in a slightly subtler way.
But it’s not what anyone was talking about. Such a cable should be really quite rare because it’s unlikely to work at all in most situations, whereas devices with USB-C ports that don’t work with PD chargers (due to a cent’s worth of missing Rd resistors) are irritatingly common, because they do work with USB-C to A cables!
Huh? It seems clear to me that this is what exmadscientist was talking about, any other interpretation just doesn't make sense.
And no, such cables would still work in plenty of cases. You usually get them by having them bundled with devices they do work well with. In fact, they always work fine with the kind of devices you mention. These cables aren't as common as USB-C-shaped junk that's missing resistors on the receptacle, but I stumbled upon them anyway and I didn't really try to.
Right. That phrase "standards-compliant" in the above comments is doing a lot of heavy lifting.
A lot of devices are not actually standards-compliant. Some are close. (This may actually be worse.)
My experience has been that if the source and sink are broken, they are often hilariously badly broken and it is pretty easy to figure out that they are the problem, if not quite exactly what they've done wrong. But if things are flaky and weird and don't really make sense, it's probably the cable. Try a known-really-seriously-actually-standards-compliantly-good cable and many problems go away, even if the source and sink aren't perfect.
(Many sources and sinks aren't standards-compliant because, even though they easily could be, they're trying to work around the other end not being standards-compliant itself, because that's what you've got to do to sell a product. So they're close but not quite there. This is not always ideal.)
You may wish to re-read the type-c specification, especially 4.5.2.2.3.2:
"A USB 2.0 only Sink that doesn’t support accessories and is self-powered or requires only default power and does not support USB PD may transition directly to Attached.SNK when V BUS is detected."
or 4.5.2.2.5:
"A port that entered this state directly from Unattached.SNK due to detecting V BUS shall not determine orientation or availability of higher than Default USB Power and shall not use USB PD."
or 4.5.2.2.11.2:
"The port shall transition to Attached.SNK after tCCDebounce if or when V BUS is detected."
CC detection, let alone PD negotiation is not needed. You can draw up to 2.5W right away from Vbus and be standard compliant without wiring anything to CC signals.
Of course if you try this with a DRP device like a smartphone, you'll get no power. But that's not really an issue for type-c chargers or USB A-C cable assemblies.
The free software world has enough on its plate already, and there are a lot of other higher-priority targets for free firmware - e.g. mobile phones, GPUs, certain NICs, etc.
I think you are underestimating just how many computing devices have CPUs of some sort in them. For example:
- Optical mice have a processor running an image processing algorithm to detect motion.
- Hard disks have a processor implementing error correction, block remapping, and SMART. SSDs and SD cards are similar.
- Pretty much any USB device has a processor to implement the USB stack - pure hardware implementations exist but are uncommon (and are little more than hard-wired CPUs).
etc, etc. Exposing all of that complexity to the CPU is not useful, and would dramatically increase the scope of software that has to be written to make anything work.
Yes, this. It's good that the mouse, by default, only returns dx/dy/buttons. It's bad that you can't reprogram it easily if you want to and it's bad you can't view the source code of how it works.
I expect reprogramming to require a JTAG board. Easily reprogrammable (via USB) peripherals will be a malware vector really quickly.
Not just that, but also - it's not as though there's a single Optical Mouse Interface which every mouse uses internally. There's probably hundreds of slightly different sensors, all of which work differently - having a single, standard interface to them (USB HID) is a lot better than having to support every single one with its own driver.
(And that's even without getting into the bandwidth issue - the camera on a modern optical mouse captures far more data than it can transfer over USB.)
This is standard practice for low-volume legacy parts. A single production run will often yield enough parts for months or even years of demand; once demand gets low enough, the manufacturer will just sell what's left of the last batch, and discontinue the part when that runs out.
If there wasn't enough demand ~20 years ago for Intel to continue manufacturing the part, it's far less likely that there's enough demand now to justify designing, manufacturing, and qualifying a new part to replace it.
Wafer.space slots can support around 4-500,000 transistors in 1x1 titles, usually reserved for 1000 dies. The 386 (non SLC version) had 275,000. In theory this could be manufactured at 180nm/130nm https://wafer.space/
But then you would have to redo the whole layout and design of the chip right? Surely you can’t just scale the mask and manufacture the same chip at different scales and everything still works?
Check out the Intel Quark, it was a <50mhz x86 that was resized and re-done on a smaller feature fab and runs on a watch battery (its a bios battery), a full x86 SOC!
I dont know what feats of engineering went into it, it is discontinued, but it is a very tiny x86
It's a bit less of a thing than it used to be, but disposable books on technology were a thing for quite a while too. Think titles like "iPhone 6 for Dummies", "Learn Flash in 24 Hours", or "Windows 8 for Seniors" - there are a lot of books which were written (usually on the cheap) for a specific audience at a specific time, and which have no enduring value.
Also along these lines: test prep and study guide books. Same deal really.
> ... copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin ...
This should be your hint that UNIX certification is more of a box-checking exercise than a real test of functionality. UUCP has been functionally obsolete since at least the mid-1990s; it's surprising that macOS even bothers shipping its binaries, and it's exceptionally silly that UNIX certification requires it to be present and installed in /usr/local.
It doesn't look like the certification requires those UUCP binaries to be in /usr/local, that's just where you have to put them on macOS to be able to `chmod +s` them, which is what the certification actually requires. Less arbitrary, but even more clearly obsolete and bad practice for a modern OS.
Oh, that makes more sense. I'm still not sure why you couldn't give the binaries setuid in their default locations, given that compliance testing also requires SIP to be disabled - but, in any case, at least they aren't setuid by default.
Anyways, "real UNIX systems must implement UUCP" is still extremely silly.
Disabling SIP still leaves the root filesystem as read-only and signature-checked (this is referred to as SSV, 'signed system volume'). There is a separate command to disable SSV, but it breaks the ability to install OS updates and is rarely used. /usr/local is one of the paths that's redirected to the read-write data volume.
Third alternative: Mythos is so catastrophically bad at medical tasks that attempting to use it for medical research would instead create bioweapons. ;)
> This is hilarious considering you can easily[1] get a whole ARM laptop with 16GB for $425 all day, and that will also include a screen, keyboard, trackpad, battery, and storage.
That "laptop" will also absolutely smoke the Pi on performance, too:
Especially if the real change is a couple levels separated from the problem. For instance, I can imagine a situation where the manufacturer of that "special cloth" didn't even change anything themselves, but their lubricant supplier silently changed the formula of their sewing machine oil. (Or maybe even that one of the suppliers to the lubricant company changed something - it's turtles all the way down.)
Yes, you would also audit the quality system for your suppliers to confirm they are sufficiently controlling for upstream changes. In theory you can have all your ducks in a row.
"In theory" is doing a lot of heavy lifting there. ;)
Depending on the product and quantity, you can factor your purchase price level times 2-10 for every level of sub- and sub-sub-supplier you want to have audited to your "wacky spec" - which may even still sound kinda reasonable, until you realize your attack surface is basically fractal to the n-th degree. The amount of process steps and auxiliaries used in manufacturing is absolutely staggering.
Edit: I need to add this depends a lot on the sector. There's useful certificates for a lot of industries, if you choose to believe them.
Neither - OP means devices with missing CC resistors which will fail to charge with a compliant PD source. (The A-to-C cable works because it provides 5V Vbus unconditionally.)
reply