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 colour 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#2714

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 ↗