firmware-patch

Firmware patch — expose OSD settings over setcfg

Why

Glider firmware 1.0 keeps all the OSD settings in config_t:

int update_mode;
int lightness;              // valid -3 .. 3
int contrast;               // valid -1 .. 6
int autoclear_mode;
int autoclear_interval;
int autoclear_threshold;
int osd_scale_2x;
int button_actions[6];

…but the setcfg command's vars[] table in fw/User/shell/shell_cmds.c stops at bitstream. Nothing after it is reachable from a host, by serial or by HID — the HID command set has no "get" of any kind.

host-control.patch adds them to that table, plus an INT32 type (the existing enum is unsigned-only, and lightness/contrast are signed).

What this buys you

Goal	After patch
Host can tell which mode the buttons selected	Yes — setcfg get update_mode. The OSD writes config.update_mode on every button change, so polling it tracks K1 exactly.
Enable/disable auto clear from the host	Settable and persisted. Applied live, since ui.c reads the autoclear config in its loop.
Lightness / contrast from the host	Yes, applied instantly.
OSD scale	Settable and persisted.

Applying instantly

In stock 1.0, lightness/contrast only reach the panel via caster_set_tone(), which is called solely from the settings-menu path (ui.c:1010, ui.c:1036), so a setcfg write would not show up until the OSD was opened or the board rebooted.

The patch closes that: shell_setcfg calls caster_set_tone() directly after lightness or contrast is set, and caster_setmode() after update_mode is set. Both are public in caster.h. caster_set_tone() only rebuilds the tone LUT and writes it to the FPGA over SPI — no state machine, no side effects — so calling it from the shell task is safe. Values are clamped to the same ranges config.c enforces before being applied.

Applying and building

git clone --recursive https://gitlab.com/zephray/Glider.git
cd Glider
git checkout ed94ef7fd95a42cfdcdaf5e5da1dcdd709122763
patch -p1 < /path/to/host-control.patch

Building the MCU firmware needs STM32CubeIDE 2.0.0 (a multi-GB install). The FPGA bitstream is NOT affected and does not need rebuilding — only the MCU image changes.

scripts/dev_flash_mcu.sh      # builds, then DFU-flashes

Enter DFU first: unplug, hold the button nearest the USB port, plug back in, connected directly to the host rather than through a hub.

Safety

This is low-risk and recoverable:

• The STM32's DFU bootloader is in ROM, not in the image being replaced. Holding the button at plug-in always enters DFU no matter how broken the application firmware is. That is how 1.0 was flashed in the first place.
• The FPGA bitstream and SPIFFS are untouched by an MCU rebuild.
• Two known-good images to fall back on:
  • ~/Downloads/glider-1.0/1.0/firmware/glider_ec_rtos.bin (stock 1.0)
  • ~/Downloads/glider-backup-0.1/glider-0.1-mcu-internal-flash.bin (stock 0.1)

Restore stock 1.0 at any time with:

dfu-util -a 0 -i 0 -s 0x08000000:leave -D glider_ec_rtos.bin

The values written are range-checked on load (config.c clamps lightness to -3..3, contrast to -1..6, and resets out-of-range autoclear values), so a bad write is corrected at next boot rather than persisting.