Hacker News Reader

Comment by brandmeyer | Hacker News Reader

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.

View on HN

> 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.

https://www.raspberrypi.org/documentation/hardware/raspberry...

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. :)

Couldn't a separate USB-C plug have been use, thus not requiring power delivery?

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.

Our team had a few of https://www.totalphase.com/products/usb-power-delivery-analy... for debugging persnickety devices, and that helped tremendously.

Reply on news.ycombinator.com