Wiznet makers

Thumbnail image: AI-generated image

An Ethernet ↔ Synchronous V.24 (RS-232/V.28) L3 IP Router on W55RP20 (RP2040 + W5500)

PIO-built synchronous serial PHY + W5500 hardware offloads + HDLC/CRC framing for IP packet transport

Introduction

ether2ser is an embedded networking project that routes IP packets between Ethernet and synchronous V.24 serial (clocked RS-232/V.28). Unlike common “UART-to-Ethernet” bridges, this project targets synchronous serial links with TXC/RXC clocks, and encapsulates IP packets using a PPP-like payload format with HDLC framing and CRC16 for robust transport over the serial side.

What makes this repository especially useful for engineers is that it’s not “code only.” The project publishes:

• full firmware source,
• hardware design files (KiCad schematic + PCB),
• wiring/connection documentation,
• unit-testable protocol components,
• build/flash targets and example firmware.

GitHub: https://github.com/daredem0/ether2ser

Quick background: Why synchronous V.24 is hard

Synchronous V.24 includes separate clock lines (TXC/RXC) in addition to data (TXD/RXD). Data must be sampled and shifted exactly on clock edges. That deterministic timing is difficult to achieve via software bit-banging on typical MCUs.

ether2ser addresses this by implementing the serial PHY using RP2040 PIO, which is designed specifically for precise, deterministic I/O timing.

What this project is

In one sentence:
A W55RP20-based (RP2040 + W5500) device that performs L3 IP routing between Ethernet and a synchronous V.24 serial link using PPP-like encapsulation and HDLC+CRC.

What you get (reproducible, reusable components)

1) Full source code + build/flash targets

The repository uses a CMake-based flow with flash targets for the main router firmware and example programs (e.g., W5500 UDP echo and basic bring-up utilities). This supports quick functional verification before integrating the full pipeline.

2) Hardware design files (KiCad) + wiring documentation

The project includes a complete KiCad design for the device and a wiring/connection document. That makes it feasible to reproduce the hardware or adapt the design for a specific deployment.

3) Unit-testable protocol core

HDLC framing, CRC16 logic, and related helpers are designed to be testable via a dedicated build option, reinforcing that this is intended as an engineering-grade reference rather than a “single demo sketch.”

How it works (W5500 role & data flow)

AI-generated image

A) Clear partitioning: W5500 = Ethernet engine, RP2040 CPU = routing/protocol, PIO = synchronous PHY

ether2ser is designed around explicit role separation:

• W5500 (Ethernet) handles frame I/O and leverages hardware offloading (including checksum-related functionality) to reduce MCU load on the Ethernet side.
• RP2040 (APU/CPU) performs L3 routing and link-layer encapsulation/decapsulation (PPP-like payload, HDLC framing, CRC verification).
• RP2040 PIO implements the deterministic synchronous V.24 PHY, sampling RXD on RXC edges and shifting TXD on TXC edges.

B) Forward direction: Ethernet → Serial

1. Receive an IP packet from the Ethernet side.
2. Encapsulate it in a PPP-like payload format.
3. Apply HDLC framing and CRC16.
4. Hand the encoded byte stream to the PIO TX pipeline, which outputs TXD aligned to TXC.

C) Reverse direction: Serial → Ethernet

1. PIO samples RXD on RXC and reconstructs bytes.
2. HDLC framing is decoded and CRC16 is verified.
3. PPP-like headers are removed to recover the IP packet.
4. The IP packet is transmitted out via W5500 Ethernet.

D) Burst/idle behavior is managed intentionally

Instead of continuously emitting unnecessary serial idle patterns, the project includes a transmission state policy so the serial link stays quiet when there’s nothing to send and only emits framing when required. This is a practical detail that matters in real deployments.

E) Operations tooling: USB CDC CLI + persistent configuration

A USB CDC CLI is included for status checks and configuration, and the project includes mechanisms for storing configuration with integrity checks (CRC). Settings are applied safely (e.g., when transmission is idle), which improves reliability in field use.

Why it matters

AI-generated image

1) A rare but valuable bridge for legacy clocked serial systems

Synchronous V.24 links still exist in specialized legacy systems, test benches, and niche industrial environments. ether2ser provides a concrete implementation path to bring those links onto IP/Ethernet networks.

2) A strong reference architecture: offload + PIO PHY + L3 routing

The design is notable for its clean separation of concerns:

• W5500 for Ethernet acceleration and predictable I/O,
• RP2040 CPU for routing and protocol logic,
• PIO for deterministic synchronous signaling.

That separation makes the approach reusable for other embedded networking gateways and “legacy-to-IP” adapters.

3) Immediately reusable building blocks

HDLC/CRC components, the CLI framework, and example firmware make this project a useful template. Even if your end goal isn’t the exact same router, the repository provides a solid starting point for custom embedded gateways.

Quick notes

• This is a synchronous serial project (clocked V.24). It’s not a drop-in solution for ordinary asynchronous UART devices.
• RS-232/V.28 voltage levels require proper level shifting; hardware design files are included to support correct electrical interfacing.
• The toolchain setup script is oriented toward Arch-based environments; other OSes can adapt the dependency installation.
• If you’re reproducing the build from source, follow the repository’s submodule and build instructions closely—Ethernet stack integration depends on the included WIZnet components.

FAQ: ether2ser 

Q1. What is ether2ser?

ether2ser is an embedded networking device that acts as an L3 IP router between Ethernet and Synchronous V.24 serial (Clocked RS-232/V.28). Built on the W55RP20 (RP2040 + W5500), it encapsulates IP packets using a PPP-like format with HDLC framing and CRC16 for robust transport, rather than just bridging raw data.

Q2. How is this different from a standard "UART-to-Ethernet" bridge?

The key difference is the support for Synchronous communication.

• Standard Bridges: Typically support only Asynchronous UART (no clock lines).
• ether2ser: Supports Synchronous V.24 which requires separate clock lines (TXC/RXC) in addition to data. It utilizes the RP2040’s PIO to manage precise clock-edge sampling and shifting, which standard UART bridges cannot do.

Q3. How is the hardware architecture partitioned?

The project leverages the W55RP20 to clearly separate concerns for maximum reliability:

• W5500 (Ethernet): Handles frame I/O and hardware offloading (checksums), reducing CPU load.
• RP2040 (CPU): Manages L3 routing, payload encapsulation/decapsulation, and protocol logic (HDLC/CRC).
• RP2040 (PIO): Implements the Synchronous V.24 PHY, ensuring deterministic I/O timing for sampling RXD and shifting TXD on clock edges.

Q4. How does the data routing process work?

• Ethernet → Serial (Forward): The W5500 receives an IP packet. The RP2040 encapsulates it (PPP-like + HDLC + CRC16) and passes the byte stream to the PIO, which outputs TXD aligned to the TXC clock.
• Serial → Ethernet (Reverse): The PIO samples RXD on RXC edges. The RP2040 decodes the HDLC framing, verifies the CRC16, removes headers to recover the IP packet, and transmits it via the W5500.

Q5. Why use RP2040 PIO instead of software bit-banging?

Synchronous V.24 requires data to be sampled or shifted exactly on specific clock edges. Achieving this deterministic timing via software bit-banging on typical MCUs is unreliable due to interrupts and jitter. PIO (Programmable I/O) allows the RP2040 to handle this physical layer timing precisely in hardware without burdening the main CPU.

Q6. What is included in this repository?

This is a complete engineering reference, not just code. It includes:

• Full Firmware Source: CMake-based build system with flash targets for the router and examples.
• Hardware Design: Complete KiCad schematics and PCB layout files.
• Documentation: Wiring guides and connection details.
• Testable Core: Unit-testable protocol components (HDLC, CRC logic).
• Tools: A USB CDC CLI for configuration and status monitoring.

Q7. Who is this project for?

• Engineers needing to bridge legacy synchronous systems (industrial, defense, or telecom test benches) to modern IP networks.
• Developers looking for a reference design using W5500 + RP2040 for L3 routing or custom gateways.
• Anyone needing a robust implementation of HDLC framing over a synchronous serial link.