LED Strip: add rainbow overlay

[HereComesWhitey]

Adds a new RGB sweep/rainbow overlay ('V') to the LED strip system.

When enabled on any LED, the overlay continuously sweeps through the color spectrum using a fixed-point accumulator for efficient hue advancement. The sweep rate and per-LED hue offset are configurable via two new settings:

• ledstrip_rainbow_sweep_rate (0-255, default 10) — controls sweep speed. Higher values sweep faster. 0 freezes the rainbow.
• ledstrip_rainbow_delta_deg (0-359, default 30) — hue offset in degrees between adjacent rainbow LEDs. Larger values spread more of the spectrum across the strip.

Companion configurator PR: iNavFlight/inav-configurator#2718

Testing: Verified on SKYSTARSH743HD with 14 LEDs configured with the rainbow overlay active.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Add configurable rainbow LED strip overlay

✨ Enhancement ⚙️ Configuration changes 🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Adds a configurable V rainbow overlay with efficient fixed-point hue animation.
• Exposes sweep speed and per-LED hue spacing through LED strip settings.
• Makes CI size reporting locate CMake-downloaded ARM size tools.

Diagram

graph TD
  CFG["CLI settings"] --> SCHEMA["Settings schema"] --> PG["LED config"] --> SCHED["Layer scheduler"] --> RAIN["Rainbow layer"] --> OUTPUT["LED output"]
  ARTIFACTS["Build artifacts"] --> REPORT["Size reporter"]

Loading

High-Level Assessment

A dedicated timed overlay using a fixed-point accumulator fits the existing layer architecture and avoids floating-point work on embedded targets. Before merging, reconcile the default sweep rate: settings.yaml declares 100 while pgResetFn_ledStripConfig initializes 10, and add focused tests for zero speed, accumulator rollover, hue wrapping, and overlay parsing if practical.

Files changed (4) +80 / -4

Enhancement (2) +45 / -3

ledstrip.cRender the timed rainbow overlay +40/-1

Render the timed rainbow overlay

• Registers overlay code 'V' and a new scheduled rainbow layer. The layer advances hue through a fixed-point accumulator, applies configurable index-based hue offsets, supports a frozen zero-speed state, and initializes firmware defaults to rate 10 and delta 30.

src/main/io/ledstrip.c

ledstrip.hDefine rainbow overlay and configuration fields +5/-2

Define rainbow overlay and configuration fields

• Expands the overlay count and enum with 'LED_OVERLAY_RAINBOW'. Extends persistent LED strip configuration with sweep-rate and hue-delta fields.

src/main/io/ledstrip.h

Bug fix (1) +18 / -1

extract-size-report.shLocate downloaded ARM size tool when PATH lookup fails +18/-1

Locate downloaded ARM size tool when PATH lookup fails

• Allows an explicitly supplied tool, prefers 'arm-none-eabi-size' from PATH, then searches the CMake-downloaded toolchain directory. Emits a clear CI error when no executable can be found.

.github/scripts/extract-size-report.sh

Other (1) +17 / -0

settings.yamlExpose rainbow sweep and hue-offset settings +17/-0

Expose rainbow sweep and hue-offset settings

• Adds the LED strip parameter group entries for configurable sweep rate and adjacent-LED hue delta, including validation ranges and descriptions. The schema declares a sweep-rate default of 100.

src/main/fc/settings.yaml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Sweep default is inconsistent ✓ Resolved 🐞 Bug ≡ Correctness

Description

The settings schema declares ledstrip_rainbow_sweep_rate default as 100, while
pgResetFn_ledStripConfig initializes it to 10. Factory reset and older saved configurations
therefore use a different sweep speed than the generated settings metadata/configurator default.

Code

src/main/fc/settings.yaml[4512]

+      default_value: 100

Evidence

The schema emits 100 as generated setting metadata, but the registered parameter group's reset
function writes 10; PG loading resets first and only copies bytes available in an older record, so
upgraded configurations also retain 10 for this appended field.

src/main/fc/settings.yaml[4510-4515]
src/main/io/ledstrip.c[146-158]
src/utils/settings.rb[427-459]
src/main/config/parameter_group.c[48-60]
src/main/config/parameter_group.c[86-93]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The settings schema advertises a sweep-rate default of 100, but firmware reset and migration initialize the field to 10. Make both default paths use the intended value from the PR specification.
## Issue Context
The runtime reset function is authoritative after factory reset and supplies missing tail fields when loading older PG records, while settings generation exposes the YAML default to API/configurator consumers.
## Fix Focus Areas
- src/main/fc/settings.yaml[4510-4515]
- src/main/io/ledstrip.c[146-158]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unrelated LEDs shift hues ✓ Resolved 🐞 Bug ≡ Correctness

Description

The hue calculation multiplies the delta by the absolute configured LED index, even though the
setting defines the offset between adjacent LEDs carrying the rainbow overlay. Interspersing a
non-rainbow LED therefore adds an extra delta and changes the intended rainbow spacing.

Code

src/main/io/ledstrip.c[873]

+            ledColor.h = (rainbowHue + (i * rainbowDelta)) % 360;

Evidence

The loop visits every configured LED and uses i * rainbowDelta, but applies the result only when
the rainbow bit is present; the setting text defines adjacency specifically among rainbow LEDs.

src/main/io/ledstrip.c[868-876]
src/main/fc/settings.yaml[4516-4519]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Hue spacing currently advances for every configured LED rather than only for LEDs carrying the rainbow overlay. Track a rainbow-LED ordinal and use that ordinal in the hue calculation.
## Issue Context
The loop index includes non-rainbow entries, while the setting explicitly promises an offset between adjacent rainbow-overlay LEDs.
## Fix Focus Areas
- src/main/io/ledstrip.c[868-877]
- src/main/fc/settings.yaml[4516-4520]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Rainbow suppresses other overlays ✓ Resolved 🐞 Bug ≡ Correctness

Description

The new rainbow layer runs after Blink and Larson and unconditionally rewrites full HSV values, so
valid combinations with Blink, Strobe, Landing Flash, or Larson never display those effects. This
breaks the existing combinable-overlay model and documented behavior such as blinking the current
active color.

Code

src/main/io/ledstrip.c[974]

+    [timRainbow] = &applyLedRainbowLayer,

Evidence

The parser permits multiple overlay flags, the update loop invokes layers in table order,
Blink/Larson modify color or brightness first, and the subsequently inserted rainbow layer resets
all HSV components including value to 255.

src/main/io/ledstrip.c[287-303]
src/main/io/ledstrip.c[822-843]
src/main/io/ledstrip.c[868-876]
src/main/io/ledstrip.c[881-909]
src/main/io/ledstrip.c[971-985]
src/main/io/ledstrip.c[1024-1031]
docs/LedStrip.md[209-221]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Rainbow is applied after existing effect overlays and overwrites their color or brightness output. Reorder the layer so rainbow supplies the active color before Blink, Strobe, Landing Flash, and Larson modify it.
## Issue Context
LED configuration parsing ORs multiple overlay bits together, and every layer runs in table order. Rainbow writes hue, saturation, and value on every update, erasing effects produced by earlier layers.
## Fix Focus Areas
- src/main/io/ledstrip.c[971-985]
- src/main/io/ledstrip.c[846-879]
- src/main/io/ledstrip.c[822-843]
- src/main/io/ledstrip.c[881-909]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[github-actions]

RAM / Flash usage vs. base branch — commit fdf4f50

Target	Flash Δ	RAM Δ
MATEKF405 ⚠️	-41920 B (-5.97%)	-5808 B (-3.89%)
MATEKF722 ⚠️	-2016 B (-0.43%)	-156 B (-0.12%)
MATEKF765 ⚠️	-50556 B (-6.87%)	-15420 B (-9.32%)
MATEKH743 ⚠️	-51204 B (-6.66%)	-15328 B (-9.09%)

See RAM/flash optimization guide for techniques to reduce usage.

[github-actions]

Test firmware build ready — commit fdf4f50

Download firmware for PR #11820

246 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[sensei-hacker]

Thanks for the PR — the rainbow overlay is a nice addition, and it fits the existing timed-layer architecture really cleanly. I took a look at this with an AI-based review tool I have; it may well be wrong on any of the points below — please treat them as questions to check rather than a verdict, and correct me if I have misread anything.

1. Did you intend to change the WHITE palette entry? It looks like it renders RED now

In the last commit (fdf4f50, "Corrected LED Rainbow overlay logic and execution order"), ledstrip.c changed the default palette:

-    [COLOR_WHITE] =        {  0, 255, 255},
+    [COLOR_WHITE] =        {  0,   0, 255},

INAV uses an inverted-saturation HSV convention — hsvToRgb24 computes sat = 255 - c->s, so S=255 is white and S=0 is fully saturated. If I am reading that right, {0, 0, 255} renders as pure red, which would change COLOR_WHITE everywhere it is used (orientation NORTH LED, animation/strobe special colors, the CHANNEL HSV(WHITE) endpoint) — and since the PG version bump resets every existing user's LED config, it would propagate to all users on upgrade. Was that change intentional, or was it meant to be { 0, 255, 255 }?

2. The 8-overlay configuration now overflows a 20-byte stack buffer in the CLI

cli.c:2044 has char ledConfigBuffer[20], and generateLedConfig emits "%u,%u:%s:%s:%u" — with all 8 overlays + a 2-digit color that is up to ~27 bytes including NUL. This was already borderline with 7 overlays, but this PR raises LED_OVERLAY_COUNT 7→8 (ledstrip.h:29), making it reachable. There is even a // TODO - check buffer length at ledstrip.c:343. Should we bump the buffer to 32 (and implement that TODO) as part of this change?

3. Minor questions/notes (no urgency)

• Stale PR description: the body still says ledstrip_rainbow_sweep_rate default is 10, but the code/settings/docs consistently use 100 now.
• Dead read: in the rainbow layer (ledstrip.c:874-878) getLedHsv(i, &ledColor) is called but every field is then overwritten — could just initialize the struct directly.
• update_cli_docs.py chmod (100755 → 100644) looks accidental.

Positive notes (for the record)

The fixed-point accumulator checks out (no overflow, exact average rate, clean 358°→0° wrap), the overlay placement first in layerTable lets later layers scale brightness correctly, and the settings plumbing (yaml + PG defaults + regenerated docs) is consistent.

Really appreciate the work — the architecture integration is the clean part. Looking forward to your take on #1 and #2!