Wiznet makers

Summary

This project combines the PDNode-600 Pro baseboard with the BladeCore-M54E controller module to build a rack-oriented USB-C power distribution unit with Ethernet management. Its job is not general data processing but centralized power delivery: the system takes in AC power, converts it to a shared 24 V rail, and distributes that power across multiple USB-C PD ports, while the WIZnet W5500 provides the wired control and monitoring path through the RP2354B-based controller.

Background

The first version of PDNode-600 Pro project is called Energis, which is RP2040-based Power Distribution Unit.

What the Project Does

The easiest way to understand PDNode-600 Pro is as a managed USB-C power shelf for a compact rack. The project is described as a 600 W USB Power Delivery Unit for 10-inch rack systems, aimed at embedded developers, homelab users, test benches, and smart infrastructure. Instead of switching AC mains per outlet, it uses a centralized 24 V / 25 A industrial power supply and distributes DC internally across the system.

That internal DC bus feeds 8 independent USB-C PD outputs and 4 fixed 5 V USB-A outputs. Each USB-C port is implemented as its own PD card, with one card per slot, local power conversion from the 24 V bus, a dedicated PD controller, and per-port monitoring and fault signals. In practice, this means the product is designed to power multiple USB-C devices from one enclosure while keeping power policy, telemetry, and control centralized.

The “Pro” version is the remote-managed variant. The README describes it as being built for remote-managed racks and headless environments, with Ethernet connectivity, a web-based UI, SNMP integration, and USB service access for configuration, updates, or debugging. That is why this project is closer to a networked power controller than a simple charger bank.

Within that architecture, BladeCore-M54E is the controller module, not the power stage. The PDNode repository lists it as the system controller, and the BladeCore repository documents it as an RP2354B-based M.2 module with external flash, EEPROM, USB path control, power sequencing, and onboard Ethernet. So the PDNode baseboard and PD cards handle energy distribution, while BladeCore handles the control plane, firmware, and Ethernet-facing management logic.

Where WIZnet Fits

The WIZnet device in this design is the W5500, used on the BladeCore-M54E controller module as the system’s wired Ethernet interface. The BladeCore README explicitly describes the module as being “combined with a W5500 Ethernet controller with integrated PHY,” and the PDNode README identifies the same module as the controller board inside the PDNode-600 Pro architecture.

Its role is not power conversion. The W5500 sits on the management side of the system and provides the Ethernet link for control, monitoring, UI access, and rack integration. In this project, that makes it the transport layer for the product’s remote-management functions rather than part of the USB-C PD negotiation path itself.

That is a good fit for this kind of hardware because the system has to supervise multiple independently controlled power channels, report status, and remain reachable on a wired network in a rack or lab environment. The design choice also matches the BladeCore naming scheme, where the “E” suffix denotes integrated Ethernet support, separating the controller family into base, Ethernet, and CAN variants rather than forcing one carrier design to absorb every interface combination.

Implementation Notes

The repositories do document real WIZnet usage, but at this stage the public evidence is mainly in the hardware and design documentation rather than finished PDNode Ethernet firmware. The most useful implementation clues are therefore the hardware-level notes in the repository files.

In HW_BladeCore-M54E/README.md, the module is described as “combined with a W5500 Ethernet controller with integrated PHY.” That statement matters because it confirms Ethernet is native to the controller module itself, not added later on the PDNode baseboard. It explains why the PDNode architecture can treat BladeCore as a drop-in controller for remote management.

The same file also states that “SPI1 is used for the onboard Ethernet controller (W5500)” and lists Ethernet details such as SPI connection to the MCU, 100BASE-TX support, and dedicated reset and interrupt lines. In practical terms, that tells you the W5500 is wired as a first-class peripheral on the RP2354B controller board, with the expected control signals already accounted for in the module design.

In HW_PDNode-600-Pro/README.md, the controller block is defined as BladeCore-M54E with “100BASE Ethernet via W5500.” That is the architectural link between the two repositories: PDNode is the managed power platform, and BladeCore-M54E is the Ethernet-capable control module embedded inside it.

Practical Tips / Pitfalls

• Do not read this as a generic Ethernet board project. The primary product is a rack-mounted USB-C PD distribution system, and W5500 exists to support remote control and telemetry, not to handle the PD power path itself. 
• Keep the architecture split clear: baseboard = power distribution and slot infrastructure, PD cards = one USB-C PD output each, BladeCore-M54E = controller and Ethernet endpoint. That division is central to understanding the design. 
• The USB-C outputs share a 600 W system budget, so “8 ports” does not mean every port can run at peak output simultaneously without power budgeting. The project explicitly describes a shared input power budget. 
• The repos should be treated as early-stage hardware documentation, not a finished appliance. The published timeline shows hardware design completed, with prototyping ongoing and firmware bring-up, telemetry, validation, and integration still planned. 
• If you want to reuse the design, check licensing carefully. PDNode lists AGPL-3.0 for software and CC BY-NC-SA 4.0 for hardware, while BladeCore hardware is also documented under CC BY-NC-SA 4.0. 

FAQ

Q: Why use W5500 in this project?
A: Because PDNode-600 Pro is intended for remote-managed racks, the controller needs a stable wired management interface. In this design, the W5500 gives the RP2354B-based BladeCore-M54E a dedicated Ethernet path for web UI, monitoring, and network-based supervision, instead of making the power system depend on a local-only interface.

Q: How does W5500 connect to the platform?
A: On BladeCore-M54E, the W5500 is onboard and connected to the RP2354B over SPI1, with dedicated reset and interrupt signals documented in the module README. The module itself then plugs into the PDNode carrier through an M.2 M-key connector.

Q: What role does W5500 play in this specific project?
A: It is the Ethernet control interface for the PDNode-600 Pro, not the USB-C PD controller. The PD cards handle USB-C power generation and per-port functions, while W5500 provides the network path used for control, monitoring, and headless rack operation.

Q: Can beginners follow this project?
A: A beginner can understand the high-level idea, but building or adapting it is an intermediate-to-advanced hardware task. The project combines high-power DC distribution, USB-C PD source design, modular carrier/module integration, and Ethernet-capable embedded control, and the repos themselves show that full bring-up and validation are still in progress.

Q: How does this compare with using Wi-Fi or a monolithic controller board?
A: These repos do not publish a direct benchmark, so no measured performance claim should be invented. Architecturally, the design favors a modular Ethernet controller board because PDNode is meant for rack and headless deployment, and BladeCore already packages the RP2354B, memory, power sequencing, USB switching, and W5500 into one reusable control module instead of folding all of that into the power backplane.