Patternflow v3.2.0 — patterns install over Wi-Fi

Hardware unchanged — the v3.0 board and case carry over exactly as they are. This release is about one thing: a pattern no longer needs a firmware build to reach your board.

Building one? Start here → BUILD_GUIDE.md — about 30 minutes of (deliberately easy, all through-hole) soldering, 30 minutes of assembly, ~10 hours of printer time, around US$100 in parts.

⚠️ Safety unchanged: power through the screw terminal only

The v3.0 board's USB-C power input remains withdrawn from service (#221). Power through J4, the 2-pin screw terminal, and leave USB1, R1 and R2 unpopulated. The failure is delayed — "it seems to work" proves nothing.

Patterns install over Wi-Fi now

Until now, adding a pattern meant compiling a whole firmware image — about a minute, a 1.2 MB download, and a flash over the top of the running device, all to deliver a few kilobytes of pattern.

A pattern is now a loadable module: a relocatable ELF of about 6 KB. Pick patterns in the community, send them to the board, and they appear in the list immediately — no reflash, no reboot, no USB. Switching to one takes 6–11 ms. Up to 128 can be installed, and having them installed costs nothing while they sit there; only the one you are looking at uses any memory.

The design and the working proof of concept came from Simone Majocchi (@SimonePDA), who built the whole idea as a fork and shared it: a frozen C ABI between host and module, a linker script that collapses each module to four sections, and an on-device relocator. That is the hard part, and it arrived working.

Collecting them

Every hardware-ready pattern in the community has an add-to-cart button on its card. Fill the cart, press build, and Send over Wi-Fi points your device's pattern manager at the result — it fetches and installs every file itself. Nothing to download, nothing to unzip.

The device grew a pattern manager to match: install, multi-select delete, format, with a per-file queue showing real progress and per-file results, and navigation across every console page.

Pattern Lab: from idea to board in one path

To hardware replaces Build firmware and follows the order the work actually happens in. Everything needs the pattern as a C++ header first, so that is step one — one prompt for a single layer, a deterministic scaffold with a prompt per layer for a stack. Once you have a header, the three things it makes possible are offered together: install it as a module, build a full image, or publish it to the community with the header attached, so it arrives already marked hardware-ready and you only write a title.

Opening someone else's pattern no longer stacks their layers on top of yours — the canvas is replaced, and what you were working on is parked in Recent, which keeps the last three.

Also fixed

• The browser flasher was shipping firmware without the module loader. Anyone who flashed from the site got a board that could not receive a single pattern. The stock image is now built from the release source and version-stamped per release.
• Patterns with accents work. "Dynamic Moiré" broke three layers at once — the build scripts, a loader guard that treated any non-ASCII name as a corrupt pointer, and the panel font. Names are UTF-8 everywhere; only the panel folds them.
• A pattern that fails to load says why, on the panel and in /api/status, instead of showing a torn frame.
• "Uploaded" means "verified" — the device reopens each .pfm and checks it is structurally a module, which is what catches a truncated transfer.
• A never-used board can start. The pattern partition ships unformatted, and /patterns offers an explicit Format button exactly when the volume will not mount.

Known rough edges

Written down honestly rather than left for you to discover:

• Installing many modules in a row can wedge the device; a power cycle recovers it. Undiagnosed.
• A firmware upload from the browser occasionally aborts partway and succeeds on a retry.
• Opening a console page pauses the running pattern for as long as you are browsing. A loaded module and a 16 KB page cannot both have the RAM; three fixes were tried and are documented.
• A module runs about 20 % slower than the same pattern compiled into the firmware. That is the cost of relocatable code, not something a compiler flag reaches.

Updating

Already have a board? Open http://patternflow.local → Firmware update and drop patternflow.ino.bin from the firmware bundle below. First time, or coming from a much older image? Use the browser flasher at patternflow.work — and read README.txt in the bundle if you flash manually, because boot_app0.bin matters.