Wiznet makers

W5500 MACRAW EtherCAT Frame Path

rp2350_ethercat_wiznet is firmware for an RP2350 / RP2354A board that uses a WIZnet W5500 Ethernet module as a raw Ethernet interface for a small EtherCAT master. Instead of building a TCP, UDP, HTTP, or MQTT device, the project opens the W5500 in MACRAW mode and sends EtherCAT frames with EtherType 0x88A4 directly to CiA-402 servo or stepper drives. The technical interest is that it shows the W5500 being used at the Ethernet frame level, with the RP2350 firmware handling the EtherCAT master logic, drive discovery, mailbox exchange, motion command path, and OLED status display.

EtherCAT is an industrial Ethernet fieldbus used for motion control and automation. A normal EtherCAT master is usually a PC, PLC, or industrial controller with strict timing support. This project is different: it is a compact bench and demo implementation that runs on a microcontroller. The README is clear about this scope. The W5500 is not an EtherCAT slave controller, there are no Distributed Clocks, and every frame requires an SPI round trip between the RP2350 and the W5500. That makes it useful for learning, bring-up, and demonstration, not a replacement for a hard real-time production controller.

This distinction matters because many microcontroller Ethernet examples stop at IP services. They prove that a board can obtain an address, answer a socket, or publish data. This firmware instead stays below that layer and treats Ethernet as the carrier for a fieldbus frame format. For readers evaluating W5500 behavior, that makes the repository a useful MACRAW reference as well as an EtherCAT experiment.

The hardware side is intentionally simple. The firmware uses SPI0 for the W5500, I2C0 for a 128x128 SH1107 OLED, and two active-low buttons to request motion. The README and src/board.h agree on the W5500 wiring: GP18 is SCK, GP19 is MOSI, GP16 is MISO, GP17 is chip select, GP20 resets the W5500, and GP21 is the interrupt input. The OLED uses GP4 and GP5, while GP2 and GP3 are used as run buttons for two drive windows.

EtherCAT Logic in the Firmware

The main implementation is in src/ethercat.c. After the W5500 is initialized by src/w5500_hal.c, the firmware sets the W5500 socket mode to MACRAW and exchanges raw Ethernet frames. From there, the code builds a minimal EtherCAT master path. It scans the segment with a broadcast read of the AL status register, assigns station addresses, reads mailbox layout from the slave SII EEPROM when possible, configures mailbox SyncManagers, and walks each slave through INIT, PRE-OP, SAFE-OP, and OP.

The project also implements a useful CoE path. In PRE-OP, it reads drive identity objects such as vendor ID, product code, revision, serial number, and device name. It can query standard objects, dump object dictionary information through SDO-Information when the drive supports it, and configure CiA-402 process data. The active mapping in the source uses a controlword plus target position on the output side and a statusword plus actual position on the input side. The code then runs a cyclic process data loop with logical write and logical read datagrams.

The user interaction is easy to understand. Once a drive is found and configured, the OLED shows the decoded model name and live position. Holding the run button ramps motion, and releasing it ramps back down. The displayed speed is derived from actual position feedback, not only from the commanded target. The USB-CDC logger gives more detail, including W5500 bring-up, PHY link state, slave scan, AL-state transitions, CoE reads, and one motion line per second per drive.

One small detail in the source shows why this is more than a generic Ethernet wiring example. EtherCAT slaves return frames through the segment, and the firmware notes that the W5500 can drop received frames whose source MAC address equals its own configured source address. To avoid losing the returned EtherCAT frame, the firmware uses a transmitted source MAC that differs from the W5500 SHAR value. That is a practical MACRAW implementation detail, and it is the kind of issue a reader would miss if they only looked at the hardware photos.

The process data loop is also written in a way that is easy to follow. The firmware builds an output image for each detected drive, advances the CiA-402 controlword through the normal enable sequence, integrates a ramp into a target position, then reads back statusword and actual position. The target position is held to the actual position until the drive is enabled, which helps avoid a sudden jump when motion starts. The measured rpm shown on the OLED is calculated from position feedback over time, then smoothed for display. These choices keep the demo understandable: the button asks for motion, the master generates a position target, and the drive feedback confirms what actually happened.

Firmware Structure and Practical Scope

The repository is organized as a complete firmware project rather than a short sketch. CMakeLists.txt fetches pico-sdk, FreeRTOS, LVGL, picotool, and WIZnet ioLibrary_Driver into extern/. The WIZnet dependency is kept narrow: the build includes the W5500 core and socket layer, while higher level IP helpers such as DHCP, DNS, SNTP, MQTT, or an HTTP stack are not part of this application path.

There is also a pre-built UF2 image at firmware/rp2350_w5500.uf2, so a reader with matching hardware can try the firmware without building the full toolchain. For development, the documented flow is a normal CMake build followed by make flash monitor, using picotool for flashing and tio for the USB serial log.

The main limitation is also the reason this project is interesting. It is not trying to hide EtherCAT inside a large industrial stack. It exposes the frame path, mailbox details, and CiA-402 state transitions in a small RP2350 firmware project. For WIZnet users, this is a good example of the W5500 as a flexible Ethernet controller in a specialized protocol experiment, while still being honest about the timing and production-use limits.

There are a few boundaries to keep in mind before reusing it. The repository does not include a schematic or BOM, so the wiring table and src/board.h are the main hardware references. The source also contains some comments that look older than the current implementation, such as references to velocity-mode mapping where the active objects use target position and CSP mode. The safer way to read the project is to treat src/ethercat.c and src/board.h as the current behavior, then tune the product codes, mailbox addresses, process data addresses, counts per revolution, and motion limits for the actual drive on the bench.

Related Maker projects 

Related Maker projects place this repository in a useful MACRAW lineage. EtherCAT #4 Master - STM32 + W5500 with SOEM RAW Communication is the closest comparison because it also uses an MCU and W5500 raw Ethernet path for an EtherCAT master, but it leans on SOEM while this RP2350 project exposes a smaller from-scratch master with an OLED UI and a source-MAC workaround. TMS320F28335 - W5300 MACRAW EtherCAT Test shows the same MACRAW-for-EtherCAT idea on W5300 and DSP hardware, while RP2040-HAT-C-MACRAW is a lower-level RP/Pico MACRAW reference. Together, these older posts make this project a good bridge from generic raw Ethernet examples to a concrete CiA-402 motion-control experiment.

FAQ

What does this project use the W5500 for?

It uses the W5500 as a raw Ethernet interface. The firmware opens W5500 socket 0 in MACRAW mode and sends EtherCAT frames directly, rather than running TCP, UDP, DHCP, HTTP, MQTT, or Modbus.

Is this a complete industrial EtherCAT controller?

No. The README describes it as a soft, best-effort master for bench and demo use. The W5500 is not an EtherCAT slave controller and the design does not provide Distributed Clocks.

Which drive was it tested with?

The README says it was developed and verified against a Lichuan CL3-E57H closed-loop stepper drive. The source also contains product-code and CiA-402 configuration constants that users may need to adjust for other drives.

Can it be flashed without building from source?

Yes. The repository includes a pre-built UF2 file at firmware/rp2350_w5500.uf2. Users can also build with CMake if they want to modify the firmware.

What should be changed for another CiA-402 drive?

Start with src/board.h and the drive-specific EtherCAT settings: product-code matching, mailbox fallbacks, process data addresses, counts per revolution, and motion limits. The code can read some mailbox layout data from SII, but drive-specific PDO and mode support still matter.

Documents

• README: README.md / Project description, hardware photos, wiring, build flow, and demo link
• W5500 HAL: src/w5500_hal.c / SPI glue, reset, W5500 detection, and PHY link handling
• EtherCAT master: src/ethercat.c / MACRAW frame exchange, CoE/SDO, PDO setup, and cyclic process data
• Board configuration: src/board.h / Pin map and EtherCAT configuration constants
• Build file: CMakeLists.txt / Dependency fetch and firmware build targets
• Pre-built firmware: firmware/rp2350_w5500.uf2 / UF2 image included in the repository
• Demo video: YouTube demo / Demo linked from the README