fix(cpn): derive serial ports, Bluetooth and GPS from firmware via hw_defs JSON

[pfeerick]

Summary

Companion decided which serial ports, Bluetooth and internal GPS a radio has using hand-written board-family rules and hand-maintained build-option lists. These have drifted a long way from the firmware. This PR takes those facts from the firmware itself, records them in the hw_defs JSON, and combines them with the build options selected in the radio profile.

Commits

1. AUX serial ports and port power from hw_defs JSON

New has_aux_serial, has_aux_serial_pwr, has_aux2_serial, has_aux2_serial_pwr flags, taken from the default build of every target (AUX_SERIAL_USART, AUX2_SERIAL_USART, AUX_SERIAL_PWR_GPIO, AUX2_SERIAL_PWR_GPIO). Compared with the old rules:

	Boards
AUX2 shown but not in firmware	V12, T15, T15H7, F16, V16
AUX2 in firmware but not shown	X12S
AUX1 in firmware but not shown	NV14, EL18, PL18, PL18EV, PL18U, NB4P, Boxer, Bumblebee, Pocket, GX12, V14, V14 LCD
AUX1 shown but not in firmware	T15 Pro, X10 Express
Port power only offered on	TX16S (GX15, H17, TX15, TX16S MK3, F16, V16, T15H7 and T16's AUX2 also have it)

The TX16S-only HasSoftwareSerialPower becomes per-port HasAuxSerialPower / HasAux2SerialPower.

2. chore(h17): drop the BLUETOOTH build option

H17's hal.h has no Bluetooth UART or pins, so the option only turned AUX2 off. It can come back if the hardware turns out to have a module.

3. Apply profile build options to the current firmware variant (3.0 regression)

Since #7623 the profile stores build options in fwOptions, separately from fwType, but the current firmware variant was still looked up from fwType alone. Every option-dependent capability in OpenTxFirmware::getCapability() was therefore always off: nogvars, haptic, internalelrs/crsf/multi, afhds2a/3, flyskygimbals, danger, and so on. The variant is now looked up with the options, and it is refreshed when only the options change in the profile settings.

The standalone simulator (simulator.cpp, simulatorstartupdialog.cpp) still uses fwType alone. Its id also selects the simulator library, so it is left for a follow-up.

4. Bluetooth and GPS availability from firmware

hw_defs JSON now also records, from the default build and a BLUETOOTH=ON build of every target:

• bluetooth: builtin or optional
• bluetooth_aux_port: 1/2, the AUX port an optional Bluetooth build gives up (T16/T18/TX16S/TX16S MK3: AUX2; T15/V16/V14/V14 LCD/GX12/Pocket/Boxer/Zorro/TX12 MK2: AUX1)
• has_internal_gps: INTERNAL_GPS is in the default build

Profile build options:

• bluetooth is now offered on every board where firmware supports it as an option. It's removed from GX15 and ST16, which have no Bluetooth, and added to around 25 boards that were missing it. A test checks that the offered options match the JSON.
• internalgps is replaced by nogps ("Disable internal GPS support"). INTERNAL_GPS is only a build option on the targets that declare it (gx15, h17, tx15, tx16smk3, and horus boards with an AUX port), and there it defaults to ON. So nogps is offered on exactly those 12 boards. Boards that don't provide the option get no GPS option in Companion, and GPS is reported unavailable, matching their builds. This follows the noheli/nogvars/noras convention for options that are on unless turned off. (The opt-in internalgps came from the old radio/util/build-firmware.py, which sets INTERNAL_GPS=NO unless requested; that script only accepts opentx-… firmware names.) Old profiles carrying internalgps meant "GPS on", which is the default where the option exists; the name is ignored and drops out the next time the profile is saved. Renaming "internal GPS" (e.g. to "TX GPS", matching MIXSRC_TX_GPS / getTxGPS()) is left for a future PR.
• Bluetooth no longer excludes GPS. GPS is a serial mode on an AUX port, so it is only unavailable when Bluetooth takes the last remaining AUX port (V16, T15).

New firmware-variant capabilities BluetoothEnabled, AuxSerialAvailable, Aux2SerialAvailable and InternalGPSAvailable combine the board data with the selected options. The Hardware panel (Bluetooth section, AUX1/AUX2) and the default top bar "Internal GPS" widget use them. The board-family HasBluetooth / HasInternalGPS rules are removed.

5. fix(build): hardware_defs dump misses definitions added after it

The define dump was taken at radio/src/CMakeLists.txt:193, before definitions such as add_definitions(-DBLUETOOTH) (line 318), so BLUETOOTH and anything depending on it (BT_USART) never appeared. The call is now deferred to the end of the directory with cmake_language(DEFER CALL ...), which also covers native builds that return() early.

6. chore: remove GPS settings from targets without the INTERNAL_GPS option

c14, pl18 and st16 had if(INTERNAL_GPS) blocks, and t15pro, pa01, t15h7, t22 and v12 unconditionally added -DGPS_USART_BAUDRATE=${INTERNAL_GPS_BAUDRATE}, although none of them declare the option. With INTERNAL_GPS_BAUDRATE never set, the latter gave an empty -DGPS_USART_BAUDRATE=. GPS_USART_BAUDRATE is only used inside #if defined(INTERNAL_GPS) (serial.cpp), so all of these were dead. They are removed, so a target either declares the option or has no GPS configuration at all.

How the data was produced

The values come from preprocessor define dumps of all 58 targets, made with tools/generate-hw-defs.sh: once with default options and once with EXTRA_OPTIONS=-DBLUETOOTH=ON. This needs #7880 and commit 5. A script then checked every JSON flag against the dumps. With commit 5, the committed tooling reproduces the Bluetooth data exactly (all 58 boards compared).

Testing

• gtests-companion: 40 tests pass. New BoardSerialPorts tests cover:
  • AUX/power spot checks;
  • registered bluetooth/nogps options match the JSON for every firmware;
  • variant results for tx16s, tx16s-bluetooth, tx16s-nogps, v16-bluetooth, x12s, v12.
• The full Companion app builds.
• hw_defs checks: json_validator.py, check-jsonschema with hwdef_schema.json, and test_templates.py (58 boards × 16 templates) all pass.
• H17 firmware builds without the BLUETOOTH option, with AUX2 present.
• Companion UI not yet checked by hand.

Notes

• Main / 3.0 only. 2.12's Companion doesn't read hardware flags from JSON.
• "Optional Bluetooth" means the firmware builds with it. For several Taranis-family boards the shared hal.h defines Bluetooth pins generically, so whether the hardware has a module is not something the firmware data can confirm.

🤖 Generated with Claude Code

[elecpower]

Yeah fewer dodgy IS_ rules for me to convert to Companion board json keys:values in the boards refactor.
I'm getting closer to a draft refactor PR so hopefully some more can be moved to hwdefs and Companion is left with very minimal or preferably none of its own.