Patternflow now runs on panels other than the stock 128×64, and on patterns composed for a grid that isn't the panel's. Both paths are new, and between panel driver ICs, chain lengths and PSRAM budgets there is more variety out there than we can test on one desk.
If you try either, please leave a comment — working or broken. A one-line "64×64 FM6126A, fine" is genuinely useful; so is a photo of something coming out sideways.
The two things you might be doing
A different panel. Edit three lines in firmware/patternflow/config.h to match your hardware and reflash:
#define PANEL_RES_W 128
#define PANEL_RES_H 64
#define PANEL_CHAIN 1
That should be the whole change — nothing else in the firmware hardcodes a size. The HUB75 driver config, the canvas buffer, the radius/angle tables and the on-screen menus all derive from those three values.
A pattern composed for a different grid. Pick the frame in Pattern Lab's header (presets, or Custom… for any size from 8 to 512). It is written into the pattern as one line — // @matrix 64x128 — and travels with it through generation, publishing and the C++ export. On the device, PFCanvas maps the frame onto the panel: same size draws straight through, a swapped size rotates a quarter turn, anything else is centred and letterboxed.
Details in firmware/patternflow/README.md.
What's useful in a comment
- Panel: size, chain length, driver IC if you know it (
PANEL_PROFILE)
- What you set
PANEL_RES_W / PANEL_RES_H / PANEL_CHAIN to
- The pattern's
@matrix frame, if it isn't the panel's
- What happened — and if it went wrong, how: rotated the wrong way, mirrored, cropped, squashed, torn, dark, boot loop?
- A photo if you have one. Orientation problems are much easier to read from a picture than from a description.
Known rough edges
- Rotation direction is only verified one way. A 64×128 pattern on a 128×64 panel has been tested on a real device. The other combinations are reasoned, not observed. If yours comes out turned the wrong way, that's a real bug — please say so.
PFTables::rT / thetaT are panel-space. They're indexed by the panel grid and measured from the panel's centre, so they're wrong inside a declared frame. Patterns exported from Pattern Lab are told to avoid them; a hand-written one has to remember.- Pattern Lab assumes the stock panel when it writes the C++ conversion prompt. If yours is different the generated header still works — a declared frame that happens to match your panel just draws straight through — but the prompt may talk you out of
PFTables when it would have been fine.
- Large frames cost real time. The browser preview and the ESP32 both pay per pixel. Pattern Lab flags anything past four times the stock pixel count, but that's a hint, not a measurement of your board.
If it doesn't work
Please don't file a separate issue first — comment here. Once a case turns out to be a genuine bug rather than a setup problem, it gets split out into its own issue and linked from this thread.
Patternflow now runs on panels other than the stock 128×64, and on patterns composed for a grid that isn't the panel's. Both paths are new, and between panel driver ICs, chain lengths and PSRAM budgets there is more variety out there than we can test on one desk.
If you try either, please leave a comment — working or broken. A one-line "64×64 FM6126A, fine" is genuinely useful; so is a photo of something coming out sideways.
The two things you might be doing
A different panel. Edit three lines in
firmware/patternflow/config.hto match your hardware and reflash:That should be the whole change — nothing else in the firmware hardcodes a size. The HUB75 driver config, the canvas buffer, the radius/angle tables and the on-screen menus all derive from those three values.
A pattern composed for a different grid. Pick the frame in Pattern Lab's header (presets, or
Custom…for any size from 8 to 512). It is written into the pattern as one line —// @matrix 64x128— and travels with it through generation, publishing and the C++ export. On the device,PFCanvasmaps the frame onto the panel: same size draws straight through, a swapped size rotates a quarter turn, anything else is centred and letterboxed.Details in
firmware/patternflow/README.md.What's useful in a comment
PANEL_PROFILE)PANEL_RES_W/PANEL_RES_H/PANEL_CHAINto@matrixframe, if it isn't the panel'sKnown rough edges
PFTables::rT/thetaTare panel-space. They're indexed by the panel grid and measured from the panel's centre, so they're wrong inside a declared frame. Patterns exported from Pattern Lab are told to avoid them; a hand-written one has to remember.PFTableswhen it would have been fine.If it doesn't work
Please don't file a separate issue first — comment here. Once a case turns out to be a genuine bug rather than a setup problem, it gets split out into its own issue and linked from this thread.