Wiznet makers

Summary

muc-plc is an experimental PLC runtime that moves industrial control execution onto embedded microcontrollers, including the WIZnet W55RP20 platform. It implements a deterministic scan cycle, PLC-style process memory, compiled control bytecode, and industrial Ethernet protocols. The W55RP20 runs the control runtime while its integrated W5500 provides hardware TCP/IP sockets for OPC UA, Modbus TCP, and other PLC-facing network services.

What the Project Does

muc-plc stands for “Modular UDP-based Controller,” although the repository has expanded beyond UDP into a broader embedded PLC architecture. Its purpose is to run PLC logic directly on microcontrollers rather than requiring a desktop computer, Linux single-board computer, or conventional proprietary PLC CPU.

The runtime is divided into several functional layers:

• A PLC scan executive runs on a fixed cycle.
• A bytecode interpreter executes compiled control instructions.
• A process-memory store represents PLC inputs, outputs, markers, and local data.
• Protocol handlers expose that memory to external engineering tools, HMIs, SCADA systems, or other controllers.
• Diagnostic and protection components monitor jitter, state transitions, communication faults, and invalid writes.

The scan executive targets a 1 kHz cycle. The repository records cycle timing, builds a jitter histogram, and opens a controlled execution window for communication services after scan work is complete. This arrangement reflects a basic PLC requirement: control logic must run predictably even while network clients are reading or changing process data.

The bytecode interpreter supports 158 canonical operations aligned with the associated QuackPLC compiler representation. It includes Boolean logic, arithmetic, comparisons, edge detection, floating-point operations, and an S7-300/400-style status word. The project therefore behaves more like a small PLC virtual machine than a simple collection of hard-coded GPIO rules.

Its process memory uses PLC-oriented regions:

• I for inputs
• Q for outputs
• M for internal marker memory
• L for local data

Industrial protocol handlers map requests into these regions. For example, the Modbus TCP implementation reads coils from the Q region, discrete inputs from I, and holding registers from M. Write requests are submitted through a write coalescer instead of modifying runtime memory directly, helping separate asynchronous Ethernet requests from the deterministic control cycle.

The implemented protocol components include Modbus TCP, a compact OPC UA server, and S7comm support. The repository also contains connection filtering, write authorization, diagnostic event handling, multi-core synchronization, and runtime states such as startup, run, stop, and hold.

This makes muc-plc related to PLC technology in three concrete ways:

1. It executes control programs cyclically.
2. It maintains a PLC-style process image.
3. It communicates through protocols already used by PLC engineering and supervisory systems.

It is not yet equivalent to a certified industrial PLC. The repository reports successful host-side tests, but physical hardware verification remains listed as unfinished. There is also no published release in the repository at the reviewed revision.

Where WIZnet Fits

The RP2040 build explicitly targets W55RP20_EVB_PICO and compiles WIZnet’s ioLibrary driver for the W5500. The build defines _WIZCHIP_=W5500, includes the W5500 socket implementation, and adds DHCP support. This confirms that W55RP20 is an actual firmware target rather than a proposed replacement board.

W55RP20 combines the RP2040 microcontroller and W5500 Ethernet controller in one package. In muc-plc, the two parts have distinct responsibilities:

• The RP2040 side runs the PLC scan, process memory, interpreter, diagnostics, and protocol application logic.
• The W5500 side manages Ethernet framing and hardware TCP/IP sockets.
• The firmware exchanges commands and payloads with the W5500 through its internal SPI connection.
• External PLC clients communicate with services such as OPC UA over those W5500 sockets.

The repository initially considered LwIP for its protocol satellites but changed to hardware TCP/IP on the RP2040/W55RP20 target. Its status document states that the protocol handlers are transport-independent and that W55RP20 uses the W5500 without an LwIP dependency.

This matters for a small PLC runtime because a software TCP/IP stack consumes MCU RAM, flash, interrupt time, and CPU cycles. The W5500 instead provides eight hardware sockets and 32 KB of internal TX/RX memory. muc-plc can therefore reserve more RP2040 resources for the scan interpreter and process memory while isolating much of the TCP state handling inside the Ethernet controller.

The W55RP20 is also relevant mechanically. A separate RP2040 and W5500 design requires two packages, external SPI routing, and additional board-level integration. The combined device reduces that boundary while retaining the RP2040 programming model and W5500 socket interface.

The advantage should not be overstated. Hardware TCP/IP reduces network-stack work, but it does not automatically make the entire controller deterministic. Firmware still has to control when socket processing occurs, protect shared process memory, limit long network operations, handle disconnects, and prevent communication tasks from delaying the scan. muc-plc addresses this through execution windows, snapshot mechanisms, write coalescing, and timing diagnostics.

Implementation Notes

The W55RP20 support appears in both the build configuration and the Ethernet initialization code.

W55RP20 Build Target

File: src/CMakeLists.txt

target_compile_definitions(quackplc-rp2040 PRIVATE
    PICO_BUILD
    _WIZCHIP_=W5500
    DEVICE_BOARD_NAME=W55RP20_EVB_PICO
    MUCPLC_FIRMWARE_TARGET
)

This selects the W5500 variant of ioLibrary and identifies the target board as the W55RP20-EVB-Pico. The same build includes WIZnet’s W5500 driver, socket API, and DHCP implementation. These definitions connect the generic PLC runtime to the W55RP20 network hardware.

W5500 Initialization

File: src/w5500_hal.c

spi_init(W5500_SPI, 31250000);

reg_wizchip_cs_cbfunc(cs_select, cs_deselect);
reg_wizchip_spi_cbfunc(spi_readbyte, spi_writebyte);
reg_wizchip_spiburst_cbfunc(spi_readburst, spi_writeburst);

uint8_t txsize[8] = {2,2,2,2,2,2,2,2};
uint8_t rxsize[8] = {2,2,2,2,2,2,2,2};
wizchip_init(txsize, rxsize);

The firmware configures the W5500 connection at 31.25 MHz, registers byte and burst SPI callbacks with ioLibrary, and assigns 2 KB of transmit and receive memory to each of the eight hardware sockets. Equal allocation is simple and predictable, although a production PLC may benefit from assigning larger buffers to heavily used services and disabling unused sockets.

The same file defines a static network configuration of 192.168.2.200/24 with gateway 192.168.2.1, while another runtime path includes DHCP callbacks and a DHCP timer. This indicates that network provisioning is still evolving and should be consolidated before deployment.

OPC UA over a W5500 Socket

File: src/w5500_opcua_tcp.cpp

#define OPCUA_TCP_PORT 4840
#define OPCUA_SOCKET 1

int rc = socket(OPCUA_SOCKET, Sn_MR_TCP, OPCUA_TCP_PORT, 0x00);
if (rc != OPCUA_SOCKET)
    return MU_STATUS_BAD_TCPSERVERTOOBUSY;

rc = listen(OPCUA_SOCKET);

The OPC UA transport binds W5500 socket 1 to the standard OPC UA TCP port, 4840. It then uses ioLibrary’s recv(), send(), and close() functions as the transport backend for the project’s compact OPC UA implementation. The W5500 is therefore not interpreting OPC UA itself; it supplies the TCP connection while the RP2040 parses and produces OPC UA messages.

Comparison with Alternative Architectures

Versus a traditional PLC: muc-plc offers source-level control, low hardware cost, and protocol experimentation. A traditional PLC normally provides certified I/O, isolation, industrial power conditioning, environmental ratings, vendor engineering software, long-term support, and safety or regulatory options. muc-plc currently provides the runtime layer, not that complete industrial hardware and certification package.

Versus RP2040 plus an external W5500: software behavior is broadly similar because both use an RP2040-class MCU and W5500 socket API. W55RP20 reduces component count and the exposed MCU-to-Ethernet interconnect. A discrete design may remain preferable when the Ethernet controller must be placed separately, replaced independently, or isolated through a custom hardware architecture.

Versus RP2040 with LwIP: LwIP offers more control over the network stack and can support protocols or packet behavior outside the W5500 socket model. It also consumes MCU memory and processing time. W55RP20 moves TCP/IP state and buffering into the W5500, which better matches muc-plc’s goal of preserving MCU time for the cyclic runtime.

Versus Wi-Fi: Wi-Fi can simplify installation where cabling is unavailable, but it introduces radio association, interference, roaming, and less predictable availability. Wired Ethernet is generally easier to reason about for a fixed controller. W55RP20 does not guarantee real-time Ethernet, but it provides a stable physical link and a bounded hardware-socket model.

Practical Tips / Pitfalls

• Verify which W55RP20 board revision and pin mapping the firmware expects. w5500_hal.c labels one set of GPIOs as the W55RP20-EVB-Pico pinout, while other WIZnet examples may use different internal or board-level mappings.
• Replace the hard-coded MAC address before operating multiple controllers. Every unit on the same Layer 2 network requires a unique MAC address.
• Choose either DHCP or static addressing as an explicit product policy. The repository currently contains both a static configuration and DHCP-related runtime code.
• Reserve W5500 sockets deliberately. OPC UA already uses socket 1, and Modbus TCP, S7comm, diagnostics, or programming services must not claim the same socket.
• Revisit the equal 2 KB socket-buffer allocation when realistic traffic is available. OPC UA messages and concurrent clients may require different RX/TX allocations.
• Keep protocol work outside the critical scan section. A connected client can stall, fragment messages, or send malformed data even when the W5500 handles TCP state.
• Add physical-layer, watchdog, brownout, EMI, isolation, and fail-safe output testing before treating the system as a field PLC. The repository explicitly lists physical-board verification as remaining work.

FAQ

Q: Why does muc-plc use W55RP20?

W55RP20 combines the RP2040 execution platform with W5500 hardware TCP/IP. This lets the firmware run the PLC interpreter and deterministic scan on the MCU while the W5500 manages TCP connections and packet buffering. The repository specifically moved away from an LwIP dependency for this target.

Q: How does W55RP20 connect to the PLC runtime?

The RP2040 side accesses the integrated W5500 through SPI and WIZnet ioLibrary callbacks. The firmware registers chip-select, single-byte, and burst-transfer functions, initializes the W5500 socket buffers, and then uses the ioLibrary socket API for TCP services.

Q: What role does W55RP20 play in this specific PLC project?

It is both the processor platform and the Ethernet interface. The RP2040 executes PLC bytecode, updates process memory, and measures scan timing. The W5500 exposes that controller to industrial clients through services such as OPC UA and potentially Modbus TCP or S7comm transports.

Q: Can beginners build this project?

The project is better suited to developers already familiar with C/C++, CMake, RP2040 firmware, PLC scan semantics, and industrial Ethernet protocols. The repository contains substantial runtime and protocol code, but it does not yet present a finished beginner-oriented hardware tutorial or production image.

Q: How does W55RP20 compare with LwIP on a normal RP2040?

W55RP20 provides hardware TCP/IP sockets and dedicated packet memory, reducing the RAM and CPU work required from the RP2040. LwIP is more flexible because the full network stack runs in software, but that flexibility adds memory use, timer processing, and interaction with the control task. For muc-plc, the W5500 approach aligns better with separating communications from the 1 kHz scan cycle.