HAL_ChibiOS: Add Lectron Pi5 and V6X board definitions

[lectronuser]

Summary

New boards (Lectron Pi5 Autopilot and Lectron V6x ) have been added to the system.

• Onboard sensors have been enabled.
• Sensor orientations have been adjusted.

Classification & Testing (check all that apply and add your own)

• Checked by a human programmer
• Non-functional change
• No-binary change
• Infrastructure change (e.g. unit tests, helper scripts)
• Automated test(s) verify changes (e.g. unit test, autotest)
• Tested manually, description below (e.g. SITL)
• Tested on hardware
• Logs attached
• Logs available on request

Description

• New flight controller board featuring Raspberry Pi CM5 + Hailo AI module.
• Docs: https://lectronuser.github.io/Lectron-Doc-Center/md/raspberry/

• New flight controller board featuring Nvidia Jetson Nano.
• Docs: https://lectronuser.github.io/Lectron-Doc-Center/md/jetson/

• Triple IMU: 2x ICM-42670-P + BMI270
• BMM350 magnetometer, BMP390 barometer
• 10/100 Ethernet with MAVLink on UDP 14550
• USB-C device mode

Context

• Main Page: https://lectrontech.com/
• Technical Documentation Page: https://lectronuser.github.io/Lectron-Doc-Center/

[peterbarker]

CI must pass

Glancing review only.

[peterbarker]

These don't make sense for a generic autopilot.

[Hwurzburg]

@lectronuser commit structure is wrong...one commit per library....commit name begins with library:
must pass CI for me to review

[andyp1per]

Automated hwdef review (/hwdef-check)

PR 33423 · base master · new boards Lectron-Pi5-H7, Lectron-V6X-H7

Build

• ./waf configure --board Lectron-Pi5-H7: pass
• ./waf configure --board Lectron-V6X-H7: pass

Must-fix

• Bootloader binaries are missing. A new board must ship Tools/bootloaders/Lectron-Pi5-H7_bl.bin/.hex and Lectron-V6X-H7_bl.bin/.hex (build with Tools/scripts/build_bootloaders.py <Board>). The main firmware embeds the bootloader, so the board can't be flashed or updated without them.
• READMEs are missing the mandatory hardware sections for a Pixhawk-class board: UART mapping, PWM outputs, battery monitor (INA238), dual CAN, Ethernet, compass, RC input, and the Loading Firmware blurb. Right now they are just a short feature list.

Should-fix

• Commit structure: the changes are squashed into one commit. Split per subsystem - AP_Bootloader: for board_types.txt, bootloaders: for the binaries, AP_HAL_ChibiOS: for the hwdef dirs. Also the first commit prefix HAL_ChibiOS: should be AP_HAL_ChibiOS:.
• Non-ASCII characters throughout both hwdef.dat and hwdef-bl.dat: em-dashes (—), arrows (→, e.g. 28V→3V), and Turkish words (standardı, ayrımı, dahili demek). hwdef comments should be plain ASCII English.
• STM32_ST_USE_TIMER 2 is set in hwdef.dat but absent from hwdef-bl.dat (H7 defaults to TIM5). §7.2 requires both to agree - add it to both bootloader hwdefs.
• Second baro: code probes BARO BMP388 I2C:3:0x77 but the adjacent comment says the sensor-board baro is at 0x76. If the part is at 0x76 it will never be found - verify the address. (The README/comments say "BMP390" while the driver line is BMP388; the BMP388 driver does cover the 390 family, but reconcile the naming.)
• Lectron-V6X-H7/hwdef.dat header comment says AP_HW_LECTRON_V6X = 7130, but board_types.txt assigns it 7131 (7130 is the Pi5). Stale copy-paste - fix the comment.
• Redundant defines (§7.7): DEFAULT_SERIAL0/1/2_PROTOCOL = MAVLink2 and SERIAL3/4 = GPS already match the in-code defaults, as do DEFAULT_SERIAL1-4_BAUD. Drop them; keep only the SERIAL5/6/7 MAVLink2 overrides which do differ from the default.

Notes

• The Pi5 and V6X hwdefs are byte-identical except for name/board-ID and one IMU rotation (icm42670_fmu ROLL_180 vs NONE). If that is genuinely the only hardware difference between the two boards, fine - otherwise re-check.
• IMU rotations and SDCARD_DETECT are marked "TBD / to be verified on first bench test". Wrong IMU rotations break attitude estimation; these should be confirmed before merge.
• Board image PNGs are ~5 MB each. Most board images in the tree are well under 500 KB - consider downsizing.
• CS/DRDY labels use SP1_CS1/SP1_DRDY1 style. They parse (configure succeeds), but §7.3 prefers descriptive names like IMU1_CS, IMU1_DRDY.
• SERIAL_ORDER is Pixhawk6X-style and matches the TELEM/GPS labelling in the comments, so the non-natural order is correct - not a defect.

_{Generated by Claude via /hwdef-check. Not a substitute for a human review pass.}

[andyp1per]

See comment