pu · HackerTrans

7 months agodiscuss

I confirm, baseus chargers really reset all ports when you change the number of consumers. But I think you usually have a choice between caring about a custom power source or using a standard one. IMHO, using a dedicated PD charge is still more convenient than alternatives.

7 months agodiscuss

pdsink was done for more advanced scenarios, when a simple "trigger" is not enough or not rational.

- When you need dynamic load control - When mcu already has embedded USPD (some stm32g/WCH and others)

See the link to the reflow table protect in the readme.

In other words, when a simple "trigger" is ok for you, use it and be happy :). If something more complex required - then pdsink may be a good choice.

7 months agodiscuss

Usually, devices are constructed to work at 5v without a main load, then handshake PD, select the desired profile, and turn the heavy load on.

8 months agodiscuss

Hi HN,

I’ve released a new USB Power Delivery sink stack for embedded devices called pdsink:

  • USB-PD Rev 3.2, SPR and EPR modes.
  • Platform-agnostic C++ core.
  • Reference: FUSB302B + FreeRTOS.
  • MIT license.

Repo: https://github.com/pdsink/pdsink

Motivation: available PD stacks usually come with at least one hard constraint: • vendor lock-in / NDA / no public sources, • tied to a specific OS or framework, • incomplete feature set on the sink side (e.g. no EPR), • corner cases where behaviour doesn’t fully match the spec, • or they are difficult to extend to new TCPC / MCU combinations.

pdsink is an attempt to cover the most common “sink” (power consumer) use case with a small, readable stack that is easy to adapt to different platforms and controllers. People who deal with PD in practice may find the layering and extension model interesting compared to existing solutions.

pu

Submissions

Show HN: Pdsink – A new USB-PD 3.2 sink stack for embedded devices

comments