Wiznet makers

Project intro (from the author’s description)

The controller targets professional stage/event lighting: receive Art-Net DMX over Ethernet and render it on long WS2812 pixel lines without flicker, tearing, or dropped frames. The reported configuration is 12 parallel outputs × 1024 pixels (12,288 total), mapped from 72 Art-Net universes (72 × 512 DMX channels = 36,864 channels) at 30+ FPS for 24+ hours.

Why W5500 is used here

Art-Net transports DMX data over UDP (commonly to UDP port 6454). On a busy lighting LAN, UDP frames can arrive bursty and occasionally out of order, and a pixel controller that can’t ingest packets deterministically will show visible artifacts. The WIZnet W5500 is a strong match because it is a hardwired TCP/IP Ethernet controller with a socket interface, integrated 10/100 MAC+PHY, and hardware support for UDP receive.

Three practical benefits matter for this project:

• 32 KB internal packet buffer smooths bursts so the MCU can drain RX without dropping universes.
• Up to 8 hardware sockets helps separate Art-Net stream reception from discovery/management traffic if needed.
• SPI up to 80 MHz keeps “packet in → payload in RAM” time bounded, which is crucial when the other core must output strict waveforms.

Technical analysis (what makes it stage-grade)

This design works because it treats the system as a real-time pipeline, not “Ethernet + LEDs” glued together:

1) One video frame spans many UDP packets
With 72 universes, each rendered frame is distributed across 72 ArtDMX packets. ArtDMX includes Universe and (optionally) Sequence fields, so the receiver can route data quickly and detect stale/out-of-order packets. At 30 FPS the network stage must digest ~2,160 packets/s (72 × 30). Payload alone is ~36,864 bytes/frame × 30 ≈ 1.1 MB/s, but the hard part is per-packet overhead (interrupts, validation, routing). W5500’s socket buffering plus burst SPI reads reduce “must service now” moments when multiple universes land back-to-back.

2) WS2812 timing is non-negotiable
WS2812 LEDs use a single-wire NRZ protocol with tight pulse-width constraints (for example T0H ≈ 0.4 µs and T1H ≈ 0.8 µs). If network I/O steals cycles from LED bit generation, you get jitter that the LEDs interpret as wrong bits—visible as sparkle, flicker, or wrong colors. That’s why the author dedicates Core 1 to PIO-driven signaling and DMA-fed FIFOs: waveform timing is hardware-deterministic and largely independent of CPU load.

3) Memory discipline prevents tearing
72 universes × 512 bytes equals 36,864 channel bytes per frame, exactly matching 12,288 pixels × 3 bytes. Many high-throughput designs store pixels as 32-bit words for alignment, which aligns with the author’s stated ~49,152 bytes (≈48 KB) moved per frame via DMA. Double-buffering is the critical anti-tear mechanism: one buffer is “front” (DMA/PIO transmitting) while the other is “back” (Core 0 writing universes), and swap happens only on DMA completion.

Where W5500 contributes is predictability: hardwired sockets + buffering make RX service time closer to constant, which makes it much easier to keep the LED core’s schedule clean under burst traffic.

Architecture explanation (conceptual)

Ethernet ingest on Core 0:

Configure a UDP socket for Art-Net reception (port 6454) and allocate sufficient RX buffer from the W5500’s 32 KB internal memory pool.

Use the W5500 INT pin to trigger interrupt-driven reads instead of polling; read payloads via SPI burst transfers and immediately release RX space so bursts don’t pile up.

Validate Art-Net header/opcode/length, then compute a destination offset from the Universe field. A hash/table-based mapping keeps routing O(1) even at 72 universes.

Track per-frame completeness with a 72-entry bitmap; publish a “frame ready” flag only after all universes are written to the back buffer, so Core 1 never swaps to a partial frame.

Output engine on Core 1:

Configure PIO state machines for WS2812 waveforms and arm DMA streams that feed PIO FIFOs for 12 outputs.

Use DMA chaining (or rapid re-arming) so an output restarts immediately after completion.

Swap front/back buffers only in the DMA-complete interrupt, and synchronize cross-core handoff using cache-friendly alignment and explicit memory barriers.

Hardware note for stage reliability: keep SPI/RJ45 traces clean, add proper decoupling, and use appropriate Ethernet magnetics/ESD protection so electrical noise doesn’t become “phantom” packet or ground issues.

FAQ

1) Why use W5500 for an Art-Net pixel controller?
W5500 combines Ethernet MAC+PHY and a hardwired TCP/IP stack with a socket API, so your MCU can focus on ArtDMX parsing and pixel mapping rather than implementing a full network stack. Its 32 KB internal buffer helps absorb UDP bursts that would otherwise cause universe drops and visible tearing.

2) How do you interface W5500 to RP2350-class MCUs?
W5500 connects via SPI (up to 80 MHz) plus CS/RESET and an INT pin for “packet arrived” interrupts. INT-driven reads reduce wasted cycles from polling. W5500 is a 3.3 V device and is commonly specified with 5 V-tolerant I/O, simplifying mixed-voltage boards.

3) What role does W5500 play in the dual-core architecture?
It is the deterministic UDP front end on Core 0: receive Art-Net packets on port 6454, buffer them, and expose payloads through hardware sockets so Core 0 can validate and demultiplex 72 universes efficiently. If reception is unstable, you swap incomplete frames and see tearing or “sparkle.”

4) Can beginners build something similar with W5500?
Yes, if you scale up in steps. Start with one universe and one WS2812 output to validate UDP reception and mapping. The advanced part is artifact-free scaling: double-buffering, avoiding extra copies, and moving WS2812 generation into hardware (PIO/DMA/timers) so network load cannot cause timing jitter.

5) How does W5500 compare with Wi-Fi or ENC28J60-class Ethernet parts?
Wi-Fi can introduce variable latency and congestion that undermines tight frame deadlines in event venues. ENC28J60-class chips provide Ethernet MAC/PHY but still rely heavily on your MCU/IP stack for packet handling. W5500’s hardwired TCP/IP, sockets, internal buffering, and fast SPI are aimed at keeping receive latency bounded while firmware stays simpler.