--- title: "High-Performance ArtNet to WS2812 Controller" url: "https://maker.wiznet.io/viktor/projects/high-performance-artnet-to-ws2812-controller/" markdown_url: "https://maker.wiznet.io/viktor/projects/high-performance-artnet-to-ws2812-controller/md" type: "UCC: User Created Content" author: "Kavinda Madhubhashana" author_url: "https://www.facebook.com/watch/?v=1176776344565571" editor: "WIZnet" editor_url: "https://maker.wiznet.io/" original_author: "Kavinda Madhubhashana" original_url: "https://www.facebook.com/watch/?v=1176776344565571" published: "2026-02-06" language: "en" hardware: ["WIZnet W5500"] likes: 0 views: 385 comments: 0 source: "WIZnet Makers (https://maker.wiznet.io/)" --- # High-Performance ArtNet to WS2812 Controller > This project builds a pro-grade Art-Net (UDP) to WS2812 controller on RP2350, driving 12,288 LEDs across 12 outputs at 30+ FPS. Original author: Kavinda Madhubhashana (source: https://www.facebook.com/watch/?v=1176776344565571) ## Components - **WIZnet W5500** x 1 ([docs](https://docs.wiznet.io/Product/Chip/Ethernet/W5500)) WIZnet parts: W5500 ([Datasheet](https://docs.wiznet.io/Product/Chip/Ethernet/W5500/datasheet?utm_source=maker&utm_medium=project&utm_campaign=w5500), [product hub](https://maker.wiznet.io/products/w5500/)) ## Article ## 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. --- Source: https://maker.wiznet.io/viktor/projects/high-performance-artnet-to-ws2812-controller/