boards coming in with stale defines. The defines are several versions old, so I don't think it's really worth adding code to enforce no-more-merging of these bad defines.
minimize_fpv_osd.inc force-enabled AP_MSP_VIDEOTX_ENABLED on the F405
FPV boards, costing ~1.5K of flash for a feature those boards rarely
use. Leave it to the default (off); 2MB boards that want it opt in via
their own hwdef.
These boards default a serial port to MSP DisplayPort or DJI FPV, so they
have the digital VTX hardware that MSP VTX control targets. Enable it
explicitly now that it no longer defaults on for >1MB boards.
Initial hwdef support for the SimpliFly H7 based on STM32H743:
- ICM42688P IMU on SPI, BMP280 barometer on I2C
- AT7456E (MAX7456) OSD on SPI2, W25Q128FV 16MB dataflash
- 5 UARTs, 4 motor outputs on TIM8 (BDshot capable)
- 4 servo outputs on TIM4 (BDshot capable), NeoPixel LED on TIM3
- 9V regulator GPIO control (RELAY2_PIN 81)
- Camera trigger output on CC pad (RELAY3_PIN 82)
- defaults.parm: SERVO9_FUNCTION=120 (NeoPixel), OSD_TYPE2=5 (MSP DisplayPort)
Reject a numeric DEFAULT_SERIALn_PROTOCOL/HAL_SERIALn_PROTOCOL/HAL_OTGn_PROTOCOL
value during hwdef processing, and convert the in-tree boards that used numbers
to the equivalent SerialProtocol_* name (value-preserving).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CORVON 743V2 is a 10-motor / 2-servo flight controller based on the
STM32H743VIH6. ICM-42688P and BMI088 IMUs on SPI3, BMP581 baro and
IST8310 compass on the internal I2C2 bus, dual analog battery monitor,
analog airspeed and RSSI, 8 UARTs, FDCAN1 and microSD logging.
These boards are based on FMUv3 but, unlike the Pixhawk2/Cube, do not
have an IMU heater. Now that the heater is enabled per-board rather than
inherited from fmuv3, these boards simply do not enable it.
fmuv3.inc no longer enables HAL_HAVE_IMU_HEATER (and fmuv3-bdshot.inc,
which now includes it, inherits that). Boards based on FMUv3 declare the
IMU heater explicitly, so whether a board has a heater is recorded on the
board itself rather than inherited.
The fmuv3 / fmuv3-bdshot reference targets keep the heater in their own
hwdef.dat. Boards which enable the heater but set no HAL_IMU_TEMP_DEFAULT
(and do not set BRD_HEAT_TARG in defaults.parm) carry a comment querying
whether they really have a heater. No functional change.
fmuv3-bdshot.inc was a complete sideways copy of the fmuv3 definition
that had to be kept in sync by hand. It now includes fmuv3.inc and
overrides only what differs for bi-directional dshot: PWM2/PWM3 gain
BIDIR, PWM5/PWM6 gain NODMA, SPI4 and its devices are removed to free up
DMA streams, and the DMA priorities are set accordingly.
The standalone copy lacked the Solo-specific, 1M-flash-check and external
IST8310 probing defines that fmuv3 carries, so those are undef'd to keep
behaviour identical. The generated hwdef.h for fmuv3-bdshot,
Pixhawk1-bdshot and Pixhawk1-1M-bdshot is byte-for-byte unchanged.
After the rename of the FMUv3 hardware definitions to .inc, add a thin
hwdef.dat for each board which simply includes its .inc. This keeps the
fmuv3 and fmuv3-bdshot build targets working and lets other boards share
the .inc without the board-level hwdef.dat. No functional change.
FCAPv3 shares the TBS LUCID H7 electrical design but has no MAX7456: analog
OSD comes from an on-board STM32G431 co-processor fed MSP DisplayPort over
UART5. RC input is on UART4 (SBUS), leaving USART6 as a spare. Motor pads are
numbered S1-S10 from PA0 in silk order.
ChibiOS now reports the MSIPLL-locked 4MHz MSI range at its real
3.998MHz, giving a 79.96MHz SYSCLK rather than the nominal 80MHz. That
tripped the HAL_EXPECTED_SYSCLOCK static_assert on LSE-clocked L4 boards.
Also define HAL_CAN_ALLOW_INEXACT_CLOCK for CAN timing.
computeTimings required PCLK to be an exact integer multiple of the
target bitrate. On MSI-PLL/LSE clocked L4 boards PCLK is 79.96MHz, so the
1Mbit search truncated 79.96 to 79 (prime), found no solution, and left
the CAN interface uninitialised. Round the prescaler search to nearest
and accept the closest achievable bitrate within 1%. This is a no-op
where PCLK is an exact multiple, so other boards are unaffected.
the H723/H725/H730/H733/H735 parts have FDCAN3 and the updated
ChibiOS FDCANv2 driver requires STM32_IRQ_FDCAN3_PRIORITY to be
defined. This fixes the build of BotBloxDroneNet
Peter Barker
MOS550andCursor
Andy Piper
MonikaRobu
Randy Mackay
Jacob Dahl
zhucaigui
dopelion
Brown
orbittechnologyx
Ashwani SihagandHenry Wurzburg
lvguofei
Maxim Buzdalov
HuibeanandRandy Mackay
Sharanie0612
Rahul-Karshak
holydust
Pietro Saccone
Tim Tuxworth
gokhan iha
RunnyCow
Andrew Tridgell
Norihiko Itou
Karthik Arumugham