chore: use settings from radio JSON files instead of hal.h

[philmoz]

Start to move away from hal.h files and use the radio JSON files for build settings.

Changes:

• Clean up creation of files generated from radio JSON files, cleanup up dependencies
• Add new generated file (hal_settings.h)
• Move some more settings from hal.h to JSON

Known concerns:

• V12 in main branch appears to be for a B&W radio instead of the color one so is probably wrong (not tested)
• No build target or JSON file for stm32h7s78-dk dev board
• horus/hal.h contains settings for X12S that are also dependant on PCBREV value which may be problematic for handling purely in JSON files

Summary by CodeRabbit

• New Features
  • Board definitions now include explicit LCD, backlight, LED and timer configuration enabling richer display/LED/timing support.
• Chores
  • Centralized hardware settings generation and schema validation for consistent board behavior and build ordering.
  • Normalized hardware feature flags to booleans for clearer capability handling.
• Refactor
  • Timer and interrupt naming standardized across targets for consistent runtime wiring.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds JSON schema/models and Jinja template to generate hal_settings.h from board JSON. Refactors CMake to centralize generation and dependencies. Migrates numerous board JSONs to new lcd/backlight/leds/timers schema. Updates companion parsing, headers, IRQ macro names, drivers, Lua/YAML/Simu wiring, and GUI gating.

Changes

Hardware definition generation and integration

Layer / File(s)

Summary

Generation, schema, build, parser, targets, drivers, UI radio/util/hw_defs/*, tools/hwdef_schema.json, cmake/Macros.cmake, radio/src/CMakeLists.txt, radio/src/**/CMakeLists.txt, radio/src/boards/hw_defs/*.json, companion/src/firmwares/boardjson.cpp, radio/src/targets/**/*, radio/src/boards/generic_stm32/rgb_leds.cpp, radio/src/targets/common/arm/stm32/*, radio/src/gui/*, radio/src/lua/*

Generate hal_settings.h from board JSON; add JSON Schema and Pydantic models; extend generator context and Jinja template; update AddHWGenTarget to emit custom targets; rewire CMake dependencies and build-order; migrate board JSONs to lcd/backlight/leds/timers; update companion JSON parsing; rename IRQ macros/handlers; consolidate hal headers to include hal_settings; adjust drivers and simulator/lua/yaml generation wiring; gate GUI backlight color on HAS_BACKLIGHT_COLOR.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Dev as Developer/CMake
  participant Schema as hwdef_schema.json
  participant Gen as generator.py
  participant Tmpl as hal_settings.jinja
  participant Build as CMake Targets
  participant Code as Firmware/Headers

  Dev->>Schema: Validate board JSON
  Dev->>Build: Configure AddHWGenTarget(${FLAVOUR}.json → hal_settings.h)
  Build->>Gen: Run generator with validated JSON
  Gen->>Tmpl: Render with display/leds/backlight/timers
  Tmpl-->>Build: hal_settings.h generated
  Build->>Build: add_dependencies(... hal_settings)
  Build->>Code: Compile with new macros/IRQ names

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch philmoz/use-json-settings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 9

🧹 Nitpick comments (1)

radio/util/hw_defs/hal_settings.jinja (1)

10-45: 🏗️ Heavy lift

Boolean HAL feature macros expand to True/False, but current usage is defined(...)-gated
hal_settings.jinja emits #define OLED_SCREEN True/False-style values for boolean HAL fields, and the current codebase references OLED_SCREEN, HAS_BACKLIGHT_COLOR, STATUS_LEDS, LCD_HORIZONTAL_INVERT, and LCD_VERTICAL_INVERT via #if defined(...) / #if !defined(...) (so the True/False numeric-expression risk doesn’t show up in current consumers).
For extra robustness/future-proofing, consider switching to value-less #define for true (skip false) or emit 1/0 instead of Python True/False.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@radio/util/hw_defs/hal_settings.jinja` around lines 10 - 45, The template
currently emits Python True/False text for boolean HAL fields which can break
consumers using `#if` defined(...) checks; update the hal_settings.jinja
generation so booleans are robust: either (preferred) emit value-less defines
only when true (e.g., if val is True then output "`#define` OLED_SCREEN" and skip
when False) or consistently emit "1"/"0" integers (e.g., "`#define` OLED_SCREEN 1"
or "0"); apply this change to the boolean symbols referenced in the codebase
such as OLED_SCREEN, HAS_BACKLIGHT_COLOR, STATUS_LEDS, LCD_HORIZONTAL_INVERT,
and LCD_VERTICAL_INVERT by testing val's truthiness and emitting the appropriate
form.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@companion/src/firmwares/boardjson.cpp`:
- Around line 1229-1235: The loader currently populates display fields but omits
the new lcd_vertical_invert flag; add parsing for
o.value("lcd_vertical_invert").toBool() and assign it to the display struct
(e.g. set display.vertical_invert or display.lcd_vertical_invert depending on
the existing field name in the Display struct) alongside the other assignments
(display.w, display.h, display.phys_w, display.phys_h, display.depth,
display.color, display.oled) so the companion stays in sync with the migrated
board schema.
- Around line 1247-1250: The assignment to cfs_led_strip_length is wrong: it's
storing a boolean (toInt() > 0) instead of the actual length, causing cfs.groups
to be computed as 0; change the line that defines cfs_led_strip_length to
capture the integer length (int cfs_led_strip_length =
o.value("cfs_led_strip_length").toInt();) and keep the existing logic that
computes cfs.groups using cfs_led_strip_length and cfs_leds_per_switch, ensuring
cfs.rgb_led is set from cfs.groups as before.

In `@radio/src/boards/hw_defs/pa01.json`:
- Line 306: The led_strip_gpio value uses an octal-style integer literal; change
the pin argument in the JSON from "GPIO_PIN(GPIOF, 06)" to use a decimal literal
(e.g., "GPIO_PIN(GPIOF, 6)") so GPIO_PIN/ GPIOF evaluation is consistent with
other entries and avoids octal parsing issues; update the entry named
led_strip_gpio accordingly.

In `@radio/src/boards/hw_defs/tx15.json`:
- Around line 337-340: The backlight timer is TIM1 so the backlight_timer_freq
must use the APB2 timer domain instead of the APB1 expression; update the value
of backlight_timer_freq (currently "(PERI1_FREQUENCY * TIMER_MULT_APB1)") to use
the APB2 clock symbols (e.g. "PERI2_FREQUENCY * TIMER_MULT_APB2") so TIM1
references the correct APB2 timer frequency.

In `@radio/src/boards/hw_defs/tx16smk3.json`:
- Around line 451-454: The backlight timer TIM1 is an APB2 peripheral but the
JSON uses the APB1 clock expression; update the backlight_timer_freq value to
use the APB2 timer clock expression instead of "(PERI1_FREQUENCY *
TIMER_MULT_APB1)". Replace that string with the equivalent APB2 expression (e.g.
use PERI2_FREQUENCY and TIMER_MULT_APB2) so backlight_timer = "TIM1" has
backlight_timer_freq matching APB2.

In `@radio/src/boards/hw_defs/x9d.json`:
- Around line 353-358: The hardware definition for X9D is missing the
has_int_module_support flag which causes generated settings to omit built-in RF
module support; add "has_int_module_support": true to the "hardware" object in
x9d.json (alongside has_ext_module_support, sport_max_baudrate, cpu, cpu_type)
so the target correctly recognizes internal-module support.

In `@radio/src/boards/hw_defs/x9d`+.json:
- Around line 367-372: The hardware block for X9D+ removed the internal-module
flag which alters generated capabilities; restore the internal module support by
adding "has_int_module_support": true back into the same "hardware" object (next
to "has_ext_module_support") so X9D+ retains its built-in RF/internal module
paths.

In `@radio/src/boards/hw_defs/x9d`+2019.json:
- Around line 361-366: The hardware definition for the X9D+ 2019 JSON removed
the internal module flag; restore the "has_int_module_support" property in the
"hardware" object of x9d+2019.json (add "has_int_module_support": true) so the
generated capabilities include internal RF support for the X9D+ 2019 target.

In `@radio/src/boards/hw_defs/x9e.json`:
- Around line 559-564: The hardware block for X9E omitted the internal-module
flag, which breaks generated capabilities; update the "hardware" object in
x9e.json (where "has_ext_module_support", "sport_max_baudrate", "cpu", and
"cpu_type" are defined) to include "has_int_module_support": true so the target
correctly advertises its built-in RF hardware and internal-module functionality
is preserved.

---

Nitpick comments:
In `@radio/util/hw_defs/hal_settings.jinja`:
- Around line 10-45: The template currently emits Python True/False text for
boolean HAL fields which can break consumers using `#if` defined(...) checks;
update the hal_settings.jinja generation so booleans are robust: either
(preferred) emit value-less defines only when true (e.g., if val is True then
output "`#define` OLED_SCREEN" and skip when False) or consistently emit "1"/"0"
integers (e.g., "`#define` OLED_SCREEN 1" or "0"); apply this change to the
boolean symbols referenced in the codebase such as OLED_SCREEN,
HAS_BACKLIGHT_COLOR, STATUS_LEDS, LCD_HORIZONTAL_INVERT, and LCD_VERTICAL_INVERT
by testing val's truthiness and emitting the appropriate form.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f8c01218-433e-443b-a2e7-e38db07e594c

📥 Commits

Reviewing files that changed from the base of the PR and between 00d7544 and 623c434.

📒 Files selected for processing (82)

• cmake/Macros.cmake
• companion/src/firmwares/boardjson.cpp
• radio/src/CMakeLists.txt
• radio/src/boards/generic_stm32/CMakeLists.txt
• radio/src/boards/generic_stm32/rgb_leds.cpp
• radio/src/boards/hw_defs/boxer.json
• radio/src/boards/hw_defs/bumblebee.json
• radio/src/boards/hw_defs/commando8.json
• radio/src/boards/hw_defs/el18.json
• radio/src/boards/hw_defs/f16.json
• radio/src/boards/hw_defs/gx12.json
• radio/src/boards/hw_defs/lr3pro.json
• radio/src/boards/hw_defs/mt12.json
• radio/src/boards/hw_defs/nb4p.json
• radio/src/boards/hw_defs/nv14.json
• radio/src/boards/hw_defs/pa01.json
• radio/src/boards/hw_defs/pl18.json
• radio/src/boards/hw_defs/pl18ev.json
• radio/src/boards/hw_defs/pl18u.json
• radio/src/boards/hw_defs/pocket.json
• radio/src/boards/hw_defs/st16.json
• radio/src/boards/hw_defs/t12.json
• radio/src/boards/hw_defs/t12max.json
• radio/src/boards/hw_defs/t14.json
• radio/src/boards/hw_defs/t15.json
• radio/src/boards/hw_defs/t15pro.json
• radio/src/boards/hw_defs/t16.json
• radio/src/boards/hw_defs/t18.json
• radio/src/boards/hw_defs/t20.json
• radio/src/boards/hw_defs/t20v2.json
• radio/src/boards/hw_defs/t8.json
• radio/src/boards/hw_defs/tlite.json
• radio/src/boards/hw_defs/tpro.json
• radio/src/boards/hw_defs/tpros.json
• radio/src/boards/hw_defs/tprov2.json
• radio/src/boards/hw_defs/tx12.json
• radio/src/boards/hw_defs/tx12mk2.json
• radio/src/boards/hw_defs/tx15.json
• radio/src/boards/hw_defs/tx16s.json
• radio/src/boards/hw_defs/tx16smk3.json
• radio/src/boards/hw_defs/v12.json
• radio/src/boards/hw_defs/v14.json
• radio/src/boards/hw_defs/v16.json
• radio/src/boards/hw_defs/x10.json
• radio/src/boards/hw_defs/x10express.json
• radio/src/boards/hw_defs/x12s.json
• radio/src/boards/hw_defs/x7.json
• radio/src/boards/hw_defs/x7access.json
• radio/src/boards/hw_defs/x9d+.json
• radio/src/boards/hw_defs/x9d+2019.json
• radio/src/boards/hw_defs/x9d.json
• radio/src/boards/hw_defs/x9e.json
• radio/src/boards/hw_defs/x9lite.json
• radio/src/boards/hw_defs/x9lites.json
• radio/src/boards/hw_defs/xlite.json
• radio/src/boards/hw_defs/xlites.json
• radio/src/boards/hw_defs/zorro.json
• radio/src/bootloader/CMakeLists.txt
• radio/src/gui/212x64/radio_setup.cpp
• radio/src/gui/common/stdlcd/feature_control.h
• radio/src/hal/CMakeLists.txt
• radio/src/lua/CMakeLists.txt
• radio/src/lua/api_general.cpp
• radio/src/storage/yaml/CMakeLists.txt
• radio/src/targets/common/arm/stm32/CMakeLists.txt
• radio/src/targets/common/arm/stm32/mixer_scheduler_driver.cpp
• radio/src/targets/common/arm/stm32/timers_driver.cpp
• radio/src/targets/horus/hal.h
• radio/src/targets/pa01/hal.h
• radio/src/targets/pl18/CMakeLists.txt
• radio/src/targets/pl18/hal.h
• radio/src/targets/simu/CMakeLists.txt
• radio/src/targets/st16/hal.h
• radio/src/targets/stm32h7s78-dk/hal.h
• radio/src/targets/t15pro/hal.h
• radio/src/targets/taranis/CMakeLists.txt
• radio/src/targets/taranis/hal.h
• radio/src/targets/tx15/hal.h
• radio/src/targets/tx16smk3/hal.h
• radio/util/hw_defs/generator.py
• radio/util/hw_defs/hal_settings.jinja
• radio/util/hw_defs/models.py

💤 Files with no reviewable changes (7)

• radio/src/hal/CMakeLists.txt
• radio/src/targets/pl18/CMakeLists.txt
• radio/src/gui/common/stdlcd/feature_control.h
• radio/src/targets/taranis/CMakeLists.txt
• radio/src/lua/CMakeLists.txt
• radio/src/storage/yaml/CMakeLists.txt
• radio/src/bootloader/CMakeLists.txt

[3djc]

Overall I'm for it. The only drawback is that it starts to make the addition of new radio very complex, since we have no heleprs or validation of those .json. Before I could add it to 2.12, and use the generated json as a reference point, few additions where needed. This starts to make the task very complex

[raphaelcoeffic]

Right now in radio/util/hw_defs/hal_settings.jinja, boolean fields are emitted as their Python-stringified text. Since the only guard is val is not none, a true flag becomes #define STATUS_LEDS True and a false flag becomes #define OLED_SCREEN False.

This works today only because every false flag is omitted from the JSON. But all consumers test these with #if defined(...), which ignores the replacement text. So the moment anyone writes a flag explicitly as false (a natural thing to do for a boolean), #define OLED_SCREEN False makes defined(OLED_SCREEN) true and silently enables the feature, the opposite of intent.

I'd suggest skipping false and rendering true as 1, so the generated header is correct regardless of how the JSON is authored:

--- a/radio/util/hw_defs/hal_settings.jinja
+++ b/radio/util/hw_defs/hal_settings.jinja
@@ -8,9 +8,9 @@
 // Timers
 {% for name, val in timers %}
-{% if val is not none %}
-#define {{ name | upper }} {{ val }}
+{% if val is not none and val is not false %}
+#define {{ name | upper }} {{ 1 if val is true else val }}
 {% endif %}
 {% endfor %}
 {% endif -%}
@@ -18,9 +18,9 @@
 // Display
 {% for name, val in display %}
-{% if val is not none %}
-#define {{ name | upper }} {{ val }}
+{% if val is not none and val is not false %}
+#define {{ name | upper }} {{ 1 if val is true else val }}
 {% endif %}
 {% endfor %}
 {% endif -%}
@@ -28,9 +28,9 @@
 // Backlight
 {% for name, val in backlight %}
-{% if val is not none %}
-#define {{ name | upper }} {{ val }}
+{% if val is not none and val is not false %}
+#define {{ name | upper }} {{ 1 if val is true else val }}
 {% endif %}
 {% endfor %}
 {% endif -%}
@@ -38,9 +38,9 @@
 // LEDS
 {% for name, val in leds %}
-{% if val is not none %}
-#define {{ name | upper }} {{ val }}
+{% if val is not none and val is not false %}
+#define {{ name | upper }} {{ 1 if val is true else val }}
 {% endif %}
 {% endfor %}
 {% endif -%}

Result: true becomes #define STATUS_LEDS 1, false is omitted, and non-bool values are untouched. Note is not false / is true are identity tests, so an integer 0 (e.g. ltdc_irq_prio: 0) still correctly renders as #define LTDC_IRQ_PRIO 0 rather than being dropped.

[raphaelcoeffic]

Another minor thing: timers is Optional in pydantic but required by the schema. A JSON missing timers would pass model validation but produce a broken header since CPU_FREQ et al. are required.

[raphaelcoeffic]

Apart from the 2 nits / potential for hardening (#7411 (comment) and #7411 (comment)) I mentioned earlier, this looks pretty solid to me, thx @philmoz!

[philmoz]

Right now in radio/util/hw_defs/hal_settings.jinja, boolean fields are emitted as their Python-stringified text. Since the only guard is val is not none, a true flag becomes #define STATUS_LEDS True and a false flag becomes #define OLED_SCREEN False.

Silently dropping things could cause other problems in future.

Instead I have fixed the output for booleans to be true/false instead of True/False and changed the usage to remove the 'defined' test.
E.G.

#if defined(OLED_SCREEN)

becomes

#if OLED_SCREEN

Undefined names are treated as 0 by the preprocessor so this works as expected, and is more readable IMO.

[raphaelcoeffic]

Instead I have fixed the output for booleans to be true/false instead of True/False and changed the usage to remove the 'defined' test. E.G.

#if defined(OLED_SCREEN)

becomes

#if OLED_SCREEN

Undefined names are treated as 0 by the preprocessor so this works as expected, and is more readable IMO.

Isn't the "normal" convention to use 1 and 0, exactly because non-defined usually resolves to 0? (it's not a guarantee, but gcc and clang handle this just fine AFAIK).

[philmoz]

Isn't the "normal" convention to use 1 and 0, exactly because non-defined usually resolves to 0? (it's not a guarantee, but gcc and clang handle this just fine AFAIK).

I updated the generator to always output these #defines so it does not need to fall back to undefined behaviour.

[pfeerick]

Since tools/generate-hw-defs.sh is broken by this PR, and the flow has been changed from

hal.h → (C++ preprocessor) → ${FLAVOUR}.json.h → (generate_hw_def.py -i defines) → hw_defs/${FLAVOUR}.json

to

hw_defs/${FLAVOUR}.json → (generate_hw_def.py -i json -t hal_settings.jinja) → hal_settings.h → #include'd into hal.h

this means it and hardware_defs are now dead code, and should be removed, no?

[3djc]

We need to a think around PCBREV with those json based declarations; Will talk to Raph about it