Add Waveshare ESP32-S3-ePaper-1.54 board support

[pritom-kun]

Add Waveshare ESP32-S3-ePaper-1.54 board support

This adds support for the Waveshare ESP32-S3-ePaper-1.54 — a 200×200 monochrome
SSD1681 e-paper panel with no touch, no PMU, and no IMU. It's the first
non-AMOLED, non-color display in the project, so it bumps into a few assumptions
the HAL was built around. I've kept the shared footprint as small as I could and
flagged every place I had to step outside the "just add a board folder" model.

What lives in the board folder (the bulk of the change)

Everything specific to this panel is in firmware/src/boards/waveshare_epaper_154/,
as the porting guide intends:

• A small vendored SSD1681 driver (epd.h/epd.cpp) plus a display.cpp that
  bridges the HAL's RGB565 framebuffer down to the panel's 1-bit-per-pixel format.
• The shared UI uses a dark theme (light text on a black background), which would
  look wrong on e-paper, so the driver inverts as it packs pixels: light UI pixels
  become black ink, dark pixels become white paper. The result is black-on-white
  without the UI code knowing anything about it.
• The light/dark threshold is tuned (64 rather than a naive 128) so that every
  foreground color in the palette — including the red used for the "disconnected"
  state, which sits at the low end — still renders as visible ink, while the
  background and card fills stay white. This is what let me avoid scattering
  e-paper-specific color overrides through the shared UI.
• Refresh is handled entirely here too: a full refresh at boot, fast partial
  refreshes during use, and a periodic full refresh (every 10 minutes) to clear
  ghosting. A rate-limit keeps the panel to at most one partial per second, so the
  UI's normal animation speed doesn't thrash a display that physically needs
  ~300 ms per update.

The touch/IMU/power stubs are trivial, and there's a new PlatformIO env. None of
this touches shared code.

Files outside the board folder, and why they were necessary

The porting guide says you shouldn't need to edit main.cpp, ui.cpp, or
anything under hal/, and to open an issue if you do because it points at a HAL
gap. E-paper surfaced a couple of real gaps. Here's each one so you can decide
whether you'd prefer a different shape.

hal/board_caps.h and main.cpp — leaving the splash screen without a touchscreen.
On the AMOLED boards you dismiss the boot splash by tapping it. This board has no
touch panel, and its only inputs are the BOOT button (a HID key) and the PWR
button (which, on the splash, cycles through animations). With zero shared edits a
touchless board boots to the splash and can never reach the usage or Bluetooth
screens — it's genuinely stuck. There was no runtime way to express "this board
has no touch," so I added a single has_touch boolean to BoardCaps and one
branch in the PWR handler: touch boards keep cycling animations (you leave via
tap), touchless boards use PWR to advance off the splash. That's the whole change
— one struct field and one if.

ui.cpp — a layout tier for 200×200.
The smallest existing layout targets 368×448 and overflows badly on 200×200.
Step 7 of the porting guide explicitly anticipates this and says to add a
breakpoint to compute_layout() for a new screen size, which is what I did: a
self-contained "tiny" tier alongside the existing two. The screen-builder
functions pull their fonts and sizes from the active tier, so the AMOLED layouts
are unchanged. (One related touch in this file: the "Current"/"Weekly" pill is
inverted on this tier — light fill, dark text — so that after the 1-bit inversion
it shows as a solid black pill with white text instead of disappearing into the
white background.)

The other boards' caps.cpp / board.h, and capability-flags.md.
Adding the has_touch field meant the three existing boards and the template had
to set it; otherwise the designated-initializer default would leave them at
false and silently change their splash behavior. So each gets a one-line
has_touch = true. The capability-flags doc gets a matching row, in keeping with
the existing convention of holding that table in sync with the struct.

Testing

The new waveshare_epaper_154 env builds and links cleanly, and both ESP32-S3
AMOLED envs still build unchanged as a regression check. The ESP32-C6 env's
RISC-V toolchain isn't installed locally, so its has_touch wiring was verified
statically rather than with a full build. On-device navigation (PWR moving off the
splash into usage/Bluetooth), black-on-white rendering, and the inverted pill have
been checked on the physical panel.

🤖 Generated with Claude Code

[HermannBjorgvin]

Looks very nice, I assume the * honking animations aren't able to refresh at a high enough rate to look nice on ePaper displays, how did you solve that?

[pritom-kun]

Thanks for taking a look. The panel supports both partial and full refresh capabilities. The spinner updates its RAM-side frame every 130–260 ms, but the panel commits only one frame per second using partial refresh. It always displays the latest RAM state when each 1-second window opens, so intermediate spinner frames are silently skipped. While the display's partial refresh rate is around 300 ms, I've set the spinner refresh rate to 1 second to minimize battery consumption and screen wear. You can easily adjust this using the MIN_PARTIAL_MS constant in the board's display.cpp file.