Wiznet makers

Summary

AmeNote ProtoZOA's NetworkMIDI2_Bridge connects USB MIDI 2.0 devices to Network MIDI 2.0 over wired Ethernet using an RP2040 and a WIZnet W5500 expansion board. The RP2040 handles USB Universal MIDI Packets, Network MIDI 2.0 session logic, and lwIP, while the W5500 provides the physical Ethernet interface and MACRAW frame transport over SPI. The primary use case is developing and testing professional MIDI 2.0 equipment that needs bidirectional communication between USB and Ethernet networks.

What the Project Does

AmeNote ProtoZOA is a hardware and firmware prototyping platform created for MIDI 2.0 development. The repository contains examples for USB MIDI 2.0, MIDI bridging, FreeRTOS experiments, host-side tools, and supporting MIDI libraries. Version 2.0 of the project added the NetworkMIDI2 Bridge, which specifically connects Network MIDI 2.0 to USB MIDI 2.0 through a WIZnet W5500 Ethernet expansion module.

The bridge operates bidirectionally:

USB MIDI 2.0 → RP2040 → Network MIDI 2.0 → W5500 → Ethernet

and:

Ethernet → W5500 → Network MIDI 2.0 → RP2040 → USB MIDI 2.0

MIDI 2.0 data is represented using Universal MIDI Packets (UMP). On the USB side, the project uses tusb_ump, a TinyUSB-based MIDI 2.0 implementation. On the network side, it uses AmeNote's NetworkMIDI2 session library with UDP transport.

The bridge can operate as either a Network MIDI 2.0 host or client. Host mode listens using the recommended Network MIDI 2.0 UDP port 5004, while client mode connects to a configured remote host. Network configuration supports DHCP or static IPv4 settings, and the runtime configuration is stored in flash and can be changed through a console setup menu.

The main application is intentionally implemented as a polling loop rather than an RTOS application. Each iteration services TinyUSB, W5500/lwIP traffic, lwIP timers, and the NetworkMIDI2 session.

The primary use case is professional audio and MIDI equipment development. A developer can use ProtoZOA to prototype instruments, controllers, interfaces, processors, or other MIDI 2.0 products that need to exchange MIDI data between a USB host and an Ethernet network.

This is particularly relevant to development and interoperability testing because ProtoZOA was created around the MIDI Association's work on developing MIDI 2.0 implementations and testing interoperability between products.

Where WIZnet Fits

The Ethernet interface in this implementation is the WIZnet W5500 connected to the RP2040 through SPI.

For the ProtoZOA UUT expansion connector, the repository defines the following hardware mapping:

The project specifically uses RP2040 SPI1 because SPI0 is already occupied by the high-speed connection between the ProtoZOA Main and UUT processors. The source comments also document that GPIO8 for MISO was confirmed on physical hardware.

The interrupt signal is not currently used. Instead, Ethernet reception is polling-based.

One important architectural detail is that this project does not use the W5500 as a conventional hardware TCP/UDP socket offload engine.

Instead, it opens W5500 socket 0 in MACRAW mode:

if (socket(SOCKET_MACRAW, Sn_MR_MACRAW,
           NM2_SESSION_PORT, 0x00) < 0) {
    printf("MACRAW socket open failed\n");
}

UUT/NetworkMIDI2_Bridge/main.cpp, around lines 1262–1266.

MACRAW mode exposes raw Ethernet frames from the W5500 to the RP2040. The application then passes those frames into lwIP, which provides the IP and UDP networking used by the NetworkMIDI2 library.

The architecture is therefore:

RJ45 / Ethernet PHY → W5500 MACRAW → SPI → lwIP → UDP → NetworkMIDI2 → UMP → USB MIDI 2.0

This differs from many W5500 applications where TCP or UDP sockets are handled directly inside the W5500. Here, the W5500 is used primarily as the Ethernet MAC/PHY-facing hardware interface and frame buffer while the higher network stack runs on the RP2040.

This design is necessary because the NetworkMIDI2 library in this implementation uses an lwIP transport. The build explicitly links pico_lwip, pico_lwip_nosys, the customized WIZnet port, and the NetworkMIDI2 lwIP transport library.

Implementation Notes

The Ethernet initialization is implemented in:

UUT/NetworkMIDI2_Bridge/main.cpp

The W5500 is initialized before lwIP and the Network MIDI session:

static void wiznet_lwip_init(const BridgeConfig &cfg) {
    wizchip_spi_initialize();
    wizchip_cris_initialize();
    wizchip_reset();
    wizchip_initialize();
    wizchip_check();
    setSHAR(mac);
    ctlwizchip(CW_RESET_PHY, 0);

This code initializes the RP2040 SPI interface, configures WIZnet ioLibrary callbacks and critical sections, resets and verifies the W5500, programs its MAC address, and resets the PHY before the software network stack is started.

DHCP and static addressing are both supported. The code selects the corresponding WIZnet network mode from the persistent bridge configuration and then starts lwIP:

if (cfg.useDhcp) {
    netInfo.dhcp = NETINFO_DHCP;
} else {
    netInfo.dhcp = NETINFO_STATIC;
    parseDottedIp(cfg.staticIp, netInfo.ip);
    parseDottedIp(cfg.staticNetmask, netInfo.sn);
    parseDottedIp(cfg.staticGateway, netInfo.gw);
}

UUT/NetworkMIDI2_Bridge/main.cpp, around lines 1214–1227.

The repository identifies its WIZnet dependency as WIZnet's official ioLibrary driver and RP2040/lwIP reference work. The project vendors and customizes the board-specific glue in wiznet_port/, including w5x00_spi.*, w5x00_lwip.*, and lwipopts.h.

MIDI 2.0 Bridge Logic

The actual USB-to-network bridge is visible in the main loop.

uint8_t umpCount = tud_ump_read_ntoh(0, UMPpacket, 4);

if (umpCount) {
    ...
    if (messageType != 0xF) {
        nm2Session->sendUmp(UMPpacket, umpCount);
    }
}

UUT/NetworkMIDI2_Bridge/main.cpp, around lines 1444–1476.

USB MIDI packets are read from TinyUSB as UMP words. MIDI Endpoint and Function Block discovery messages are processed locally, while normal MIDI traffic is forwarded into the NetworkMIDI2 session.

The reverse direction is even more direct:

static void onNetworkUmp(
    void *ctx,
    const uint32_t *words,
    size_t wordCount) {

    tud_ump_write_hton(
        0,
        const_cast<uint32_t *>(words),
        (uint8_t) wordCount);
}

UUT/NetworkMIDI2_Bridge/main.cpp, around lines 1166–1170.

When NetworkMIDI2 receives a UMP message, its callback writes the message into the USB MIDI 2.0 FIFO. This is the core bridge operation.

The runtime loop continuously services all three layers:

TinyUSB
   ↓
W5500 / lwIP polling
   ↓
lwIP timers
   ↓
NetworkMIDI2 session

The repository uses lwIP with NO_SYS=1, meaning there is no dedicated TCP/IP thread. Incoming W5500 frames and lwIP timers therefore need to be serviced continuously from the application's main loop.

Practical Tips / Pitfalls

The ProtoZOA implementation uses SPI1, not SPI0, because SPI0 is already allocated to another ProtoZOA interface. Use the exact GPIO mapping defined in wiznet_port/w5x00_spi.h.

W5500 interrupt GPIO15 is currently unused, so Ethernet RX servicing depends on regular polling from the main loop. Long blocking operations could therefore delay network processing.

DHCP is supported, but fixed installations such as studio racks may benefit from static addressing or predictable discovery behavior.

Each bridge should have a unique MAC address when several units are connected to the same LAN. The repository explicitly warns against using the same locally administered default MAC for multiple boards.

The application uses W5500 MACRAW mode plus lwIP, so socket and memory planning differs from a normal ioLibrary application using the W5500's hardware TCP/UDP sockets directly.

Keep the W5500/lwIP polling loop responsive. The code explicitly calls both wiznet_lwip_poll() and sys_check_timeouts() every iteration because the stack runs without an RTOS TCP/IP thread.

The source includes a corrected receive-buffer bounds check for full Ethernet frames, which is important when adapting this port or changing packet buffers.

FAQ

Q: Why does this project use W5500 for Network MIDI 2.0?

The W5500 provides the RP2040 with a wired 100BASE-T Ethernet interface over SPI and is directly integrated into the project's NetworkMIDI2 transport path. In this specific design, it operates in MACRAW mode while lwIP performs IP and UDP processing on the RP2040, allowing the existing NetworkMIDI2 lwIP transport to run over WIZnet hardware.

Q: How does the W5500 connect to the RP2040?

The ProtoZOA expansion board uses SPI1. GPIO9 is chip select, GPIO10 is SCK, GPIO11 is MOSI, and GPIO8 is MISO, with GPIO3 controlling W5500 reset. GPIO15 is assigned to the W5500 interrupt output but is not currently used by the polling-based firmware.

Q: What exactly does the W5500 do in this MIDI project?

It moves Ethernet frames between the physical network and the RP2040. Received frames are extracted from the W5500's MACRAW socket and injected into lwIP; NetworkMIDI2 then processes UDP session traffic and ultimately delivers UMP messages to the USB MIDI interface. Transmission follows the reverse path.

Q: Can beginners build the NetworkMIDI2 Bridge?

The project is better suited to intermediate embedded developers. Following it requires familiarity with Raspberry Pi Pico SDK builds, SPI, Ethernet addressing, USB device firmware, and at least basic MIDI concepts. Developers modifying the transport layer also need to understand lwIP's NO_SYS mode and W5500 MACRAW operation.

Q: How does W5500 Ethernet compare with Wi-Fi for Network MIDI 2.0?

Wired Ethernet removes several variables present in Wi-Fi, including radio interference, channel contention, roaming, association state, and changes in RF conditions. Those properties can make Ethernet easier to control in fixed professional audio installations where repeatable connectivity is important.

Wi-Fi has a clear advantage when cabling is undesirable and mobility matters. However, Network MIDI transports are latency-sensitive, so variable wireless medium access and interference can introduce behavior that is harder to predict than a switched wired LAN.

The ProtoZOA repository does not provide a measured W5500-versus-Wi-Fi latency or jitter benchmark, so no numerical performance advantage can be claimed from this project alone. The comparison is architectural: this implementation deliberately uses wired W5500 Ethernet for its Network MIDI 2.0 transport.