On that topic, I was a bit sad to see that USB-C alternate mode wasn't picked up as the display solution for the Pi 4. I have multiple devices that work this way, and it has been a very pleasant experience.
Its complex to implement. You need a type-C port controller that can speak the funky half-duplex 300 kHz signal of USB-PD, a set of power delivery fets, some high-speed muxes, and a little microcontroller to manage the protocol's higher layers in realtime.
http://www.ti.com/product/TPS65982 is an example of a fairly high-integration IC. Its 5USD/ea in bulk, and you still need some other supporting IC's around it, such as - I kid you not - a flash chip to hold its program code. Take a good hard look at section 9.3.4 of that manual to get a taste for how complex this gets.
They only have very reduced schematics published, but it looks like the RPi4 isn't deploying a PD solution at all. I think they are just relying on the analog signaling of Type-C. The power supply is just a "simple" type-c 5V/3A unit.
> They only have very reduced schematics published, but it looks like the RPi4 isn't deploying a PD solution at all. I think they are just relying on the analog signaling of Type-C. The power supply is just a "simple" type-c 5V/3A unit.
This is the first I've heard of the RPi 4 not having PD -- could you point me to the specs you saw? I searched around a bit but couldn't find anything either way.
You have to dig a bit. I got there via Main Page -> scroll to very bottom -> documentation -> Hardware -> Raspberry Pi -> Schematics -> Raspberry Pi 4 Model B
You can see the fixed resistors attached to the CC lines for basic Type-C analog signaling, and a simple PD_SENSE line connected to the power supply IC.
Ah, wow, that's definitely a bit of digging! Thank you very much; I had my own suspicions due to the recommended power supply but it's nice to have more concrete evidence. :)
No. You need to be able to speak PD in order to figure out that the other end has VESA capabilities.
After negotiating PD, you then ask what other vendor-specific things the other end supports. If it answers back with the code assigned to VESA, then you proceed to negotiate how the various differential pairs are wired up. There are valid configurations that don't use USB at all, but repurpose the superspeed differential pairs as additional displayport pairs.
Once the host knows what the display supports, the host can configure the high-speed mux and send a displayport hotplug detect event to the SoC. After that its all on the SoC.
In principle, you could use an existing realtime unit on the SoC to do all of this, assuming that it was electrically capable of the whole shebang. In practice, I don't know that any SoC's do it yet - all of those steps are performed by either the TCPC or an embedded controller attached to the TCPC. That's likely to change eventually, though.
Thank you for these insightful comments. So, it seems that USB PD doesn't seem to be ready to become mainstream yet...
And I had not realized you needed PD capabilities to support alternate mode. However, the protocol itself doesn't seem that complicated to manage with a microcontroller and a few discreet transistors, right?
I can easily see it become more common in the future, and hopefully the open source silicon ecosystem (spearheaded by RISC-V) will make the necessary IP ubiquitous.
The remaining issue I can see is with the high-speed muxes, though if the raspberry is already capable of HDMI, I am not sure why the SoC couldn't handle those directly as well (though if they need to support 20V I can see it being difficult to do without external components).
Another comment in the tree showed that some Rockchip SOCs do have most of the requisite widgets built-in to the SoC. So the market is already moving this way. Its just not ubiquitous yet.
The protocol is described in detail in the USB-PD spec under the physical layer chapter. Its a 300 kHz biphase mark coding scheme with lots of slop available in the timing. Looks like it was designed for low-end power supplies that considered USB 1.1 to be too expensive. The PD protocol isn't horribly broken or anything. But personally, I would have preferred to see all of it managed over the classic USB D+/D- lines as a separate device profile.
The basic set of microcontroller serial peripherals (UART, SPI, I2C, etc) aren't going to handle it well, though. Maybe you could finagle a SPI device into sampling the lines, and then figure out what the bits were in software, kindof like an oversampling UART? Maybe? Or you could bit-bang via GPIOs? Not the kind of project I would be interested in. For open source work, a small FPGA would be a much better choice to work with. Its not particularly complex logic... but doing it in software is going to be very inefficient.
Well, I thought about doing it in software (bit-banging the GPIOs should probably be enough for any kind of signal at 300Hz)... I really need to read the spec, but I guess this signal is just needed for the handshake? If that's the case, you can probably afford to do it on the CPU.
As for the open source part, yeah, I was specifically thinking about open ASIC designs (whether at the RTL level, thus compilable to an FPGA, or at the layout level). The ecosystem is blooming, with open source memory compilers, as well as academic/enthusiast tools (BAG, scala, hammer-vlsi, migen) that are making great strides.
USB-C alternate mode for Displayport currently (and probably always will) requires an external port controller to negotiate the alternate mode with the other end of the cable over the configuration channel (CC) pins, and possibly a high speed mux[2] if you want USB-3.0 over the same pins as well. Simpler applications like analogue headphones or USB-C to Type A adaptor cables just use specific resistor values instead, a wise decision by the standards body IMO.
Of course, if you have that built into the SoC[3], the cost of that is reduced a lot once the IP license is covered, and makes sense for a several hundred dollar phone/laptop, though there are some extra electical requirements that come with USB-C such as tolerating 20V (in case someone plugs in a laptop adaptor that has not discharged down to 5V in time) that is hard to implement in the same silicon as the rest of the SoC, and so some external logic is almost always needed.
In addition, an actual USB-C connector is relatively expensive due to the high pin count, fine tolerances and the shape requiring use of deep-draw or metal-injection-moulding method.
Micro HDMI has much simpler interface requirements, sometimes some discrete transistors for the hot plug detect signal and a low speed level shifter for the DDC bus. The connector can be cheaper to manufacture as well as the shell can be stamped out like a Micro USB connector.
There are licensing costs[4] for HDMI, while DisplayPort is royalty free, but I reckon Broadcom can negotiate that down considerably from the published figures, and I can't see USB-C being cheaper than the listed 5 cents per device charge.
Yeah, for some reason they decided to use a completely different oddball HDMI connector to the one used in their other product with an oddball HDMI connector. So anyone with a Pi Zero and a Pi 4 now has two different annoying adapters to keep track of.
> how many hi-res (4k@60hz) monitors can I drive from a single RPi 4 ?
Just one. If you connect a second 4K monitor it drops to 4k@30
> run at 4k@60hz over USB3
No. USB 3.0 only has a maximum bandwidth of 5 Gbit/s. It takes around 15gbit/s to drive 4k@60hz 4:4:4 8bit color. That was first available in DisplayPort 1.2 which had 17gbit/s available bandwidth.
> additionally, two USB3 ports.
The USB ports are all on a single PCI-E bus with a maximum bandwidth of 4Gbit/s. So technically you don't even get full speed of a single USB3 port, much less 2.
