evan 36953bb140 fix(gui): anti-aliased rounded rects from one distance field
Corners were drawn by two disagreeing algorithms: a hand-rolled per-row inset for
the gradient fill and TFT_eSPI's Bresenham arc for the border, so they missed each
other by a pixel and left a halo. The inset was also wrong, truncating the sqrt and
ignoring pixel centres, which over-cut the top row by 2px into a visible chamfer.

gui.roundRect now derives fill and border from the same signed distance, blending
edge pixels by coverage, and replaces fillRoundRect, drawRoundRect and
fillRectGradient. The geometry moved to src/gfx/round_rect.h so round_rect_test.cpp
can check the arc on the host, since only the eye ever checked the old one.
2026-08-01 11:04:35 -04:00

esp32-lcd

Lua-app firmware for the 4.0" ESP32-32E display (lcdwiki E32R40T): ST7796S 320x480 SPI panel + XPT2046 resistive touch + microSD. Apps are plain Lua files on the SD card, launched from an on-screen menu. Inspired by crosspoint-reader's plugin system.

Build & flash

nix develop          # provides pio
pio run              # build
pio run -t upload    # flash over USB-C
pio device monitor   # serial logs

Copy sdcard/ to the SD card root: apps live in /apps/<name>/main.lua and shared Lua modules in /lib. The launcher is itself an app (/apps/launcher/main.lua); the firmware only draws a fallback screen if it cannot start.

Lua API

Apps define optional callbacks: setup(), draw() (~30fps cap), on_touch_down(x, y), on_touch_up(x, y), on_touch(x, y) (tap alias, fired on release), and on_tick() (enabled by setting TICK_MS). Call sys.exit() to return to the launcher.

require reads from the SD card: /apps/<name>/?.lua first, then /lib/?.lua.

Module Functions
gui width(), height(), clear(color), fillRect(x,y,w,h,c), drawRect(x,y,w,h,c), fillCircle(x,y,r,c,bg), drawLine(x1,y1,x2,y2,c), drawText(text,x,y,fg,bg), roundRect(x,y,w,h,radius,bg,top,bottom,border), fontHeight(), textWidth(text), setRotation(0-3), color(r,g,b)
input getTouch() -> x,y or nil, getRawTouch() -> raw ADC x,y or nil, touched()
fs readFile(path), writeFile(path, data), exists(path), listFiles(path), listDirs(path)
sys millis(), exit(), launch(path), setCalibration(x0,y0,x1,y1), getRotation(), setRotation(deg), getTheme(), setTheme(name)
wifi scan() -> {ssid,rssi,secure}[], connect(ssid,password), status() -> {state,ssid,ip,rssi}, forget()
log info(msg) (serial)

Colors are RGB565 integers; build them with gui.color(r, g, b).

Settings

/settings.lua on the SD card is a Lua table literal, read at boot and rewritten by the settings app. It is Lua rather than JSON because the firmware already links Lua, so it needs no parser on either side:

return {
  rotation = 90,
  theme = "dark",
  touch = { x0 = 188, y0 = 232, x1 = 3799, y1 = 3800 },
  wifi = { ssid = "network", password = "secret" },
}

Missing file means the built-in defaults are used. apps/settings walks two crosshairs and saves the result via sys.setCalibration(), cycles rotation through 0, 90, 180 and 270 degrees, and scans/selects Wi-Fi networks with an on-screen password keyboard. A saved network reconnects at boot.

Wi-Fi credentials are Lua-escaped but stored as plaintext on the SD card. Treat the card like any other device containing a saved password.

Rotation never needs a recalibration: calibration is stored in the panel's rotation-0 frame (320x480 raw ADC space) and the current rotation is applied afterwards, so sys.setRotation() is safe at any time. gui.setRotation(0-3) changes only the current frame; the launcher restores the saved rotation when an app exits. The glass itself is always portrait, so a rotated UI is drawn sideways on it.

nix run nixpkgs#lua -- test/ui_layout.lua              # layout, hit testing, capture
nix run nixpkgs#lua -- test/ui_theme.lua               # palette derivation and inheritance
nix run nixpkgs#lua -- test/settings_calibration.lua   # calibration math and menu flow

# Rounded-rect geometry and blending, built straight from the shared header:
c++ -std=c++11 test/round_rect_test.cpp -o /tmp/round_rect_test && /tmp/round_rect_test

Drawing rounded surfaces

gui.roundRect(x, y, w, h, radius, bg, top, bottom, border) draws a whole surface in one pass. Fill and border come from the same signed distance field, so they cannot disagree at the corners, and edge pixels are anti-aliased by coverage. top/bottom are gradient stops (pass one for a solid, or nil for no fill) and border may be nil. Since the panel has no alpha channel, bg is the colour underneath that edge pixels blend into — pass the surface the shape sits on, not the shape's own fill.

The geometry lives in src/gfx/round_rect.h, free of Arduino headers, because the previous hand-rolled corner arc was wrong in a way only a pixel test would catch.

UI toolkit (/lib/ui.lua)

Apps describe nesting and sizes fall out, borrowing CSS block flow and the box model without the cascade:

local ui = require("ui")

local screen = ui.screen(ui.box{pad = 12, gap = 8, color = BLACK, bg = WHITE,
  ui.text("settings"),
  ui.button{label = "calibrate touch", on_press = calibrate},
})

function draw() screen:draw() end
function on_touch_down(x, y) screen:down(x, y) end
function on_touch_up(x, y) screen:up(x, y) end

Sizes are pixels (>= 1), a fraction of the parent's content box (< 1), or "auto" (the default on the flow axis; the cross axis fills the parent). Boxes take pad, gap, row, align and at for absolute placement. color, bg, radius, gradient and the press palette inherit from the root, so a theme is set once.

The toolkit owns press capture (release outside cancels), an 80 ms minimum pressed duration, touch slop, and per-component dirty tracking. Any table with measure, place, draw and hit drops into the tree, so custom components need no buy-in.

Not implemented: scrolling, so a list longer than the screen is unreachable.

Themes (/lib/theme.lua)

A theme is three seed colors; ui.lua derives the rest, so adding a component never means editing a theme, and a theme cannot state its own contrast wrongly:

return {
  light = {bg = {255, 255, 255}, fg = {0, 0, 0}, accent = {0, 120, 255}},
  midnight = {bg = {12, 14, 30}, fg = {220, 225, 240}, accent = {255, 120, 0}},
}
Role Derivation
bg, fg, accent the seeds
muted fg blended 45% toward bg, for secondary text
accent_fg black or white, whichever the accent's luminance demands
face, face_pressed button gradients, from bg and accent
radius 6

Any derived role can be pinned in the theme file (radius = 0, muted = {120,120,120}). The settings app cycles through the names it finds, and stores only the name.

Components get the theme by inheritance, so a themed app names no colors at all. The division is: inheritance carries context (self.color, self.bg — what surface am I on), while ui.theme carries constants (ui.theme.accent). Read the theme directly only when drawing outside the component tree, like the calibration crosshair. An explicit value on any node still wins, which is how a component deviates:

ui.button{label = "delete", press_bg = DANGER}

The C++ Lua-error and SD-failure screens stay hardcoded high contrast, since they can fire when the settings that name the theme are themselves unreadable.

Pin map (fixed by the board)

  • Display (VSPI): SCK 14, MOSI 13, MISO 12, CS 15, DC 2, backlight 27, reset = EN
  • Touch: shares display SPI, CS 33, IRQ 36
  • SD: SCK 18, MOSI 23, MISO 19, CS 5

TFT_eSPI, XPT2046 and SD each grab the SPI controller but share the same wires; only one transfers at a time, which is safe here (see ponytail note in main.cpp).

S
Description
No description provided
Readme 860 KiB
Languages
C++ 50.5%
Lua 46.4%
Makefile 1.4%
C 0.9%
Nix 0.8%