Wiznet makers

Summary

This project is a compact sub-control board for an autonomous wheeled vehicle that uses a Seeed XIAO SAMD21, a WIZnet W5500 Ethernet module, and a 74LS04N inverter to convert wired network commands into an inverted SBUS output. The W5500 is the TCP/IP input stage, the XIAO SAMD21 decodes command data, and the 74LS04N converts the UART signal into the inverted logic format expected by SBUS-compatible RC or motor-control receivers.

What the Project Does

This board is not a general-purpose main controller. It is a dedicated Ethernet-to-SBUS gateway.

The repository identifies the board as OW_Sub_Seed_PCB, a sub PCB for the autonomous wheeled vehicle project. It uses a Seeed XIAO SAMD21 as the MCU, a W5500 Ethernet controller for command input, a 74LS04N hex inverter for SBUS logic inversion, an XT30 connector for 5 V input power, and a Molex 4-pin connector for SBUS output.

The board’s job is to receive command packets from a main board, PC, or vehicle computer over Ethernet, decode them on the XIAO SAMD21, transmit SBUS data through UART, invert the UART signal through the 74LS04N, and output the resulting SBUS signal to a downstream RC or motor-control receiver. The README’s system architecture shows this flow from W5500 Ethernet to XIAO decoding, UART transmit, 74LS04N inversion, and SBUS output.

A practical view of the board is:

Main board / PC / onboard computer
        │
     Ethernet
        │
      W5500
        │ SPI
 Seeed XIAO SAMD21
        │ UART TX
     74LS04N inverter
        │
    SBUS output
        │
RC receiver / motor controller

This makes the board useful when an autonomous vehicle has a network-based control source but still needs to drive an RC-style SBUS control input.

Where WIZnet Fits

The WIZnet product used here is again the W5500, but its role is narrower than in the STM32 main board. On the sub-board, the W5500 is the Ethernet receiver for command packets. It is not part of a broad vehicle I/O hub; it is the network front end for a protocol converter.

The README lists the W5500 as U1 Ethernet Controller W5500 (PCB-2 module) SPI hardwired TCP/IP Ethernet. It also maps W5500 SPI signals to the XIAO SAMD21: MISO to PA5/D9, MOSI to PA6/D10, chip select to PA11/D3, and SCLK to PA7/D8.

The W5500 is appropriate here because the XIAO SAMD21 is a small Cortex-M0+ board. Offloading TCP/IP to the W5500 lets the XIAO focus on parsing command packets and generating SBUS frames. The W5500 provides a hardware TCP/IP stack, SPI interface, 32 KB packet buffer, and 8 sockets, which fits a gateway-style design where only a small number of command channels are needed.

The important difference from the first project is output type. The main STM32 board exposes vehicle hardware interfaces such as PWM, relays, and RS-485. This sub-board exposes SBUS. The W5500 is common to both, but the downstream purpose is different.

Implementation Notes

The repository is mainly a hardware design package, but its README includes a conceptual firmware outline for Arduino/XIAO SAMD21. The visible repository file list emphasizes Gerber, images, BOM, schematic, and README materials; the Ethernet and SBUS behavior should therefore be treated as a documented architecture unless firmware source is separately verified.

Two verified hardware details define the design.

First, the README identifies the board type as “Sub PCB — Ethernet + SBUS Gateway Board.” That means its purpose is protocol bridging, not full vehicle control.

Second, SBUS requires signal inversion. The README states that SBUS uses inverted UART at 100,000 baud with 8E2 framing, and that the XIAO SAMD21’s normal UART output is inverted by the 74LS04N before reaching the SBUS connector.

The useful firmware model is straightforward: initialize W5500 Ethernet, listen for command packets, translate packet values into SBUS channel values, serialize an SBUS frame through the XIAO UART, and let the 74LS04N produce the inverted SBUS output. Timing matters more on the SBUS side than on the Ethernet side because the receiver expects the correct baud rate, parity, stop bits, frame length, and inverted idle state.

Practical Tips / Pitfalls

• Do not power this sub-board from 12 V. The README identifies it as a 5 V XT30 input board, unlike the 12 V STM32 main board.
• Keep W5500 SPI routing and firmware pin mapping aligned with PA5/D9, PA6/D10, PA7/D8, and PA11/D3.
• Confirm that the XIAO SAMD21 UART can generate 100000 baud with 8E2 framing in the selected firmware environment.
• Probe both sides of the 74LS04N. The XIAO UART should be normal logic, while the SBUS output should be inverted.
• Use a fixed packet format between Ethernet and SBUS translation. Ambiguous command framing can create unsafe channel values.
• Define fail-safe SBUS output states for Ethernet timeout, invalid packet data, or link loss.
• Keep Ethernet command latency separate from SBUS frame timing. The SBUS output should remain well-formed even if network packets arrive irregularly.

FAQ

Why use W5500 in this Ethernet-to-SBUS board?
The W5500 gives the small XIAO SAMD21 a wired TCP/IP interface through SPI. That lets the board receive network commands without making the SAMD21 handle a full software Ethernet stack.

How does the W5500 connect to the Seeed XIAO SAMD21?
It connects through SPI. The documented mapping uses PA5/D9 for MISO, PA6/D10 for MOSI, PA7/D8 for SCLK, and PA11/D3 for chip select. The W5500 side receives Ethernet packets, while the XIAO side reads them over SPI.

What role does W5500 play in this project?
It is the command input interface. Commands arrive over Ethernet, the XIAO SAMD21 decodes them, and the board outputs equivalent control information as SBUS through the 74LS04N inverter.

Can beginners follow this project?
A beginner can understand the signal flow, but reliable implementation requires knowledge of SPI Ethernet, Arduino or SAMD21 serial configuration, SBUS framing, logic inversion, and safe fail-state handling. The SBUS timing and inversion requirements are the main traps.

How is this different from using direct UART or Wi-Fi?
Direct UART is simpler but usually requires point-to-point wiring and does not integrate naturally into an IP network. Wi-Fi removes the cable but adds RF reliability and latency variation. W5500 Ethernet is better for deterministic bench testing, wired vehicle networks, and command links from a main board or onboard computer.