[HGLRC-T]

Summary

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

Adds support for the HGLRC H743 PRO flight controller.

The board uses an STM32H743VI, ICM42688-P IMU, SPA06-003 barometer,
AT7456E analog OSD, 16 MiB SPI flash, eight motor outputs, a serial LED
output, switchable 10 V VTX power, and a dual-camera analog switch.

The battery voltage divider is 20K:1K, so the default voltage multiplier
is set to 21.0.

Hardware verification

• USB connection and MAVLink communication verified
• ICM42688-P detected and IMU orientation verified
• SPA06-003 barometer detected and pressure/altitude readings verified
• UART2 serial RC input verified with CRSF/ELRS
• UART4 SBUS input verified
• All eight motor outputs verified
• Addressable LED output verified
• AT7456E analog OSD verified
• VTX 10 V relay verified
• Camera-switch relay verified
• Battery voltage measurement verified with a bench supply
  • Supply voltage: <value> V
  • Reported voltage: <value> V
• Battery current measurement verified with a known load
  • Load current: <value> A
  • Reported current: <value> A
• I2C connector and external pull-ups verified

[andyp1per]

Automated hwdef review (/hwdef-check)

PR 33873 · base upstream/master · new board HGLRC_H743_PRO

Build

• ./waf configure --board HGLRC_H743_PRO: pass
• ./waf copter: pass (1407740 B used, 296184 B free)
• Required files present; board ID 1526 is unique.

Must-fix

Everything is in one commit. ArduPilot wants one commit per subsystem: AP_Bootloader: for board_types.txt, bootloaders: for the _bl.bin/_bl.hex pair, AP_HAL_ChibiOS: for the hwdef directory.

hwdef.dat:107 - HAL_BATT_VOLT_SCALE 200 is off by roughly an order of magnitude. It's the only value >= 100 anywhere in the tree; the rest sit between 10 and 21, and 12S boards use ~21. At 12S a 200:1 divider puts 0.25 V into a 3.3 V ADC, which would throw away most of the range. HAL_BATT_CURR_SCALE 120 is also high (100 is the in-tree maximum, used by 7 boards) though not impossible. Please measure both against a bench supply and a known load.

The PR description is the unfilled template - no summary, no description, no testing checkboxes ticked. For a new board that's the only evidence a reviewer has. Please say what was verified on hardware: IMU orientation, baro, USB, RC input, all 8 motor outputs, the VTX and camera relays, and the battery readings above.

Should-fix

hwdef.dat:28 - SERIAL_ORDER skips USART6 without a placeholder, so SERIAL6 is UART7 and SERIAL7 is UART8. README:30 tells users the pads are marked Rn/Tn for UARTn, so anyone wiring to T7 will reach for SERIAL7 and land on UART8. Every comparable board inserts EMPTY to keep the numbering aligned (BROTHERHOBBYH743/hwdef.dat:90, AEDROXH7/hwdef.dat:30, BeastF7v2/hwdef.dat:26); this is the only board in tree with the un-placeheld form. Suggest SERIAL_ORDER OTG1 USART1 USART2 USART3 UART4 UART5 EMPTY UART7 UART8, with defaults.parm and the README table renumbered to follow.

Related: README:13 claims 8 UARTs but the hwdef defines 7. If USART6 really is broken out on the board, it's missing from the hwdef; if not, the count needs correcting.

The addressable LED doesn't work out of the box. README:15 and :62 advertise it and hwdef.dat:84 assigns PWM(9), but nothing sets SERVO9_FUNCTION 120 and the NeoPixel notify type is never enabled. AEDROXH7 is the direct analogue - SERVO9_FUNCTION 120 in defaults.parm plus define DEFAULT_NTF_LED_TYPES 455 in hwdef.dat.

README:38 lists SERIAL4's default use as "RC input (SBUS)", but nothing sets SERIAL4's protocol, so the in-code default applies and it comes up as GPS. Either set the protocol or fix the column.

defaults.parm holds settings that belong in hwdef.dat (§7.6). OSD_TYPE 1 is a straight duplicate - hwdef.dat:152 already sets HAL_OSD_TYPE_DEFAULT 1. SERIAL5_PROTOCOL -1 is a no-op since SERIAL5+ already defaults to None. The remaining SERIALn_PROTOCOL lines want define DEFAULT_SERIALn_PROTOCOL in hwdef, and the relay block has an established hwdef form (RELAY1_PIN_DEFAULT, as in BlitzH743Pro/hwdef.dat:118 and BROTHERHOBBYH743/hwdef.dat:161). To be fair, ~50 boards do put serial protocols and OSD_TYPE in defaults.parm, so that part isn't unprecedented - but the duplicated OSD_TYPE should go regardless.

Dead or redundant defines:

• hwdef.dat:98,99 HAL_BUZZER_ON / HAL_BUZZER_OFF - neither name is read anywhere in the tree
• hwdef.dat:112 AP_BARO_SPL06_ENABLED 1 - the BARO SPL06 line already emits it (generated hwdef.h:243)
• hwdef.dat:165 HAL_COMPASS_AUTO_ROT_DEFAULT 2 - already the default (AP_Compass.cpp:72)
• hwdef.dat:141 HAL_DEFAULT_INS_FAST_SAMPLE 3 - single IMU here (INS_MAX_INSTANCES 1), so bit 1 is a no-op; use 1

hwdef.dat:89 - LED3 on PD7 gets GPIO(2) but only AP_NOTIFY_GPIO_LED_2_ENABLED is set and HAL_GPIO_C_LED_PIN is never defined, so the pin just sits at its idle level. Either add define AP_NOTIFY_GPIO_LED_3_ENABLED 1 with define HAL_GPIO_C_LED_PIN 2, or drop the line.

Notes

STM32_ST_USE_TIMER 12 with CH_CFG_ST_RESOLUTION 16 is valid, and the override is genuinely needed because TIM5 drives the LED strip. But TIM2 is unused on this board and is 32-bit, so STM32_ST_USE_TIMER 2 would avoid 16-bit tick mode entirely - that's what §7.2 recommends for exactly this case.

Ignore the helper's bootloader STM32_ST_USE_TIMER mismatch warning. The bootloader has no PWM, and virtually no board in tree sets it in hwdef-bl.dat.

BARO SPL06 is correct for the SPA06-003 despite the name - the driver detects chip ID 0x11 as SPA06 (AP_Baro_SPL06.cpp:131). Flagging so nobody "fixes" it.

BIDIR placement is right: one per channel pair (CH1 and CH3 on both TIM1 and TIM4) and nothing on TIM4_CH4. DMA_NOSHARE/DMA_PRIORITY on TIM1_UP/TIM4_UP/SPI1 is the correct call.

DMA2 stream 7 carries six peripherals: USART1_TX (the MSP DisplayPort VTX link), UART7_TX, UART8_TX, TIM5_UP (LED strip), SPI2_RX (OSD) and SPI3_RX (dataflash). Everything did get a stream and sharing is normal on H7, but that's a crowded stream for a link §13.1 calls high-priority - worth checking DisplayPort behaviour with logging active.

Clock is 400 MHz (HAL_EXPECTED_SYSCLOCK 400000000) since MCU_CLOCKRATE_MHZ isn't set; 26 H743 boards set 480. Deliberate?

I2C1 pull-ups: PB7/PB8 are bare, which is correct if the board fits external resistors and non-functional if it doesn't - the .dat can't distinguish the two. Please confirm. The SPA06 is the only device on the bus, so a missing pull-up shows up as a missing baro.

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

[HGLRC-T]

Automated hwdef review (/hwdef-check)

PR 33873 · base upstream/master · new board HGLRC_H743_PRO

Build

• ./waf configure --board HGLRC_H743_PRO: pass
• ./waf copter: pass (1407740 B used, 296184 B free)
• Required files present; board ID 1526 is unique.

Must-fix

Everything is in one commit. ArduPilot wants one commit per subsystem: AP_Bootloader: for board_types.txt, bootloaders: for the _bl.bin/_bl.hex pair, AP_HAL_ChibiOS: for the hwdef directory.

hwdef.dat:107 - HAL_BATT_VOLT_SCALE 200 is off by roughly an order of magnitude. It's the only value >= 100 anywhere in the tree; the rest sit between 10 and 21, and 12S boards use ~21. At 12S a 200:1 divider puts 0.25 V into a 3.3 V ADC, which would throw away most of the range. HAL_BATT_CURR_SCALE 120 is also high (100 is the in-tree maximum, used by 7 boards) though not impossible. Please measure both against a bench supply and a known load.

The PR description is the unfilled template - no summary, no description, no testing checkboxes ticked. For a new board that's the only evidence a reviewer has. Please say what was verified on hardware: IMU orientation, baro, USB, RC input, all 8 motor outputs, the VTX and camera relays, and the battery readings above.

Should-fix

hwdef.dat:28 - SERIAL_ORDER skips USART6 without a placeholder, so SERIAL6 is UART7 and SERIAL7 is UART8. README:30 tells users the pads are marked Rn/Tn for UARTn, so anyone wiring to T7 will reach for SERIAL7 and land on UART8. Every comparable board inserts EMPTY to keep the numbering aligned (BROTHERHOBBYH743/hwdef.dat:90, AEDROXH7/hwdef.dat:30, BeastF7v2/hwdef.dat:26); this is the only board in tree with the un-placeheld form. Suggest SERIAL_ORDER OTG1 USART1 USART2 USART3 UART4 UART5 EMPTY UART7 UART8, with defaults.parm and the README table renumbered to follow.

Related: README:13 claims 8 UARTs but the hwdef defines 7. If USART6 really is broken out on the board, it's missing from the hwdef; if not, the count needs correcting.

The addressable LED doesn't work out of the box. README:15 and :62 advertise it and hwdef.dat:84 assigns PWM(9), but nothing sets SERVO9_FUNCTION 120 and the NeoPixel notify type is never enabled. AEDROXH7 is the direct analogue - SERVO9_FUNCTION 120 in defaults.parm plus define DEFAULT_NTF_LED_TYPES 455 in hwdef.dat.

README:38 lists SERIAL4's default use as "RC input (SBUS)", but nothing sets SERIAL4's protocol, so the in-code default applies and it comes up as GPS. Either set the protocol or fix the column.

defaults.parm holds settings that belong in hwdef.dat (§7.6). OSD_TYPE 1 is a straight duplicate - hwdef.dat:152 already sets HAL_OSD_TYPE_DEFAULT 1. SERIAL5_PROTOCOL -1 is a no-op since SERIAL5+ already defaults to None. The remaining SERIALn_PROTOCOL lines want define DEFAULT_SERIALn_PROTOCOL in hwdef, and the relay block has an established hwdef form (RELAY1_PIN_DEFAULT, as in BlitzH743Pro/hwdef.dat:118 and BROTHERHOBBYH743/hwdef.dat:161). To be fair, ~50 boards do put serial protocols and OSD_TYPE in defaults.parm, so that part isn't unprecedented - but the duplicated OSD_TYPE should go regardless.

Dead or redundant defines:

• hwdef.dat:98,99 HAL_BUZZER_ON / HAL_BUZZER_OFF - neither name is read anywhere in the tree
• hwdef.dat:112 AP_BARO_SPL06_ENABLED 1 - the BARO SPL06 line already emits it (generated hwdef.h:243)
• hwdef.dat:165 HAL_COMPASS_AUTO_ROT_DEFAULT 2 - already the default (AP_Compass.cpp:72)
• hwdef.dat:141 HAL_DEFAULT_INS_FAST_SAMPLE 3 - single IMU here (INS_MAX_INSTANCES 1), so bit 1 is a no-op; use 1

hwdef.dat:89 - LED3 on PD7 gets GPIO(2) but only AP_NOTIFY_GPIO_LED_2_ENABLED is set and HAL_GPIO_C_LED_PIN is never defined, so the pin just sits at its idle level. Either add define AP_NOTIFY_GPIO_LED_3_ENABLED 1 with define HAL_GPIO_C_LED_PIN 2, or drop the line.

Notes

STM32_ST_USE_TIMER 12 with CH_CFG_ST_RESOLUTION 16 is valid, and the override is genuinely needed because TIM5 drives the LED strip. But TIM2 is unused on this board and is 32-bit, so STM32_ST_USE_TIMER 2 would avoid 16-bit tick mode entirely - that's what §7.2 recommends for exactly this case.

Ignore the helper's bootloader STM32_ST_USE_TIMER mismatch warning. The bootloader has no PWM, and virtually no board in tree sets it in hwdef-bl.dat.

BARO SPL06 is correct for the SPA06-003 despite the name - the driver detects chip ID 0x11 as SPA06 (AP_Baro_SPL06.cpp:131). Flagging so nobody "fixes" it.

BIDIR placement is right: one per channel pair (CH1 and CH3 on both TIM1 and TIM4) and nothing on TIM4_CH4. DMA_NOSHARE/DMA_PRIORITY on TIM1_UP/TIM4_UP/SPI1 is the correct call.

DMA2 stream 7 carries six peripherals: USART1_TX (the MSP DisplayPort VTX link), UART7_TX, UART8_TX, TIM5_UP (LED strip), SPI2_RX (OSD) and SPI3_RX (dataflash). Everything did get a stream and sharing is normal on H7, but that's a crowded stream for a link §13.1 calls high-priority - worth checking DisplayPort behaviour with logging active.

Clock is 400 MHz (HAL_EXPECTED_SYSCLOCK 400000000) since MCU_CLOCKRATE_MHZ isn't set; 26 H743 boards set 480. Deliberate?

I2C1 pull-ups: PB7/PB8 are bare, which is correct if the board fits external resistors and non-functional if it doesn't - the .dat can't distinguish the two. Please confirm. The SPA06 is the only device on the bus, so a missing pull-up shows up as a missing baro.

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

Fixed all, please review the code again.

[HGLRC-T]

How can we move forward with merging this PR? I see that all CI processes have passed.

[Hwurzburg]

Its in my queue to review....

[Hwurzburg]

Preliminary

• No Where to Buy section. Without a purchase link the board won't be added to the wiki — please add one before I do a full review.

README.md

Loading Firmware is wrong on two counts, and it's the first thing a new user will do. This board does not ship with the ArduPilot bootloader pre-installed, so the first load has to be DFU — but as written:

• "using Mission Planner or another DFU-capable tool" — Mission Planner cannot do DFU.
• "Load the HGLRC_H743_PRO firmware file ending in _with_bl.hex" — DFU tools don't parse Intel HEX; loading a .hex via DFU writes the literal ASCII text of the file to flash and the board won't boot. The DFU target is always the .bin, and there's no file in this PR named _with_bl.hex anyway (the committed bootloader is HGLRC_H743_PRO_bl.bin/.hex).

## Firmware

Firmware for the HGLRC H743 PRO can be found [here](https://firmware.ardupilot.org) in sub-folders labeled "HGLRC_H743_PRO".

## Loading Firmware

To load ArduPilot firmware, hold boot button or pad low while powering up the board. Then use the STM32CubeProgrammer app or other DFU utility to load the "HGLRC_H743_PRO_bl.bin" file. Subsequently, a GCS can update firmware using the *.apj files.

RC Input section is missing the required bidirectional-protocol detail. It tells users to wire CRSF/ELRS to T2/R2 but never gives SERIAL2_OPTIONS, and there's no link to common-rc-systems. Since this is an H7 board, the FPort value (if anyone wants it) is 15; CRSF/ELRS is 0. Add:

UART2 is configured by default for serial RC input and supports protocols such as CRSF and ELRS. Connect the receiver to the `T2` and `R2` pads. Set `SERIAL2_OPTIONS` to `0` for CRSF/ELRS.

UART4 can also be used for SBUS or another serial RC protocol. PPM input is not supported.

See [Radio Control Systems](https://ardupilot.org/copter/docs/common-rc-systems.html) for other protocols and SERIALx_OPTIONS values.

UART Mapping table has no DMA columns and no blanket DMA statement. I built the board and checked the generated hwdef.h — every UART on this board gets DMA in both directions (UART5 is RX-only by wiring, not DMA absence). Either add TX DMA/RX DMA columns per the template, or add a one-line blanket statement ("All UARTs have DMA in both directions except UART5, which is RX-only.").

PWM Outputs doesn't say which outputs support DShot or BIDIR. hwdef.dat tags PWM1/3/5/7 BIDIR (bidirectional DShot with RPM telemetry) — the README doesn't mention DShot capability at all. I built the board and checked the DMA resolver's output: the BIDIR channels get a dedicated stream per timer (not shared with the IMU's SPI1 bus, and DMA_NOSHARE/DMA_PRIORITY correctly protect it), so this is safe to document as working. Add which outputs support DShot and which of those are bidirectional.

GPIOs table is missing. PWM1-9 (GPIO(50)-GPIO(58)), the buzzer (GPIO(80)), VTX power (GPIO(81)), and camera switch (GPIO(82)) are all assigned GPIO numbers in the hwdef and none are listed. Add the standard table.

VTX Power Control says the 10V rail "is enabled at startup" — it isn't, as shipped. See the hwdef.dat/defaults.parm finding below; without a defaults.parm, this board boots with VTX power off regardless of what this section claims.

hwdef.dat

define RELAY1_DEFAULT 1 does nothing. There's no RELAY1_DEFAULT macro anywhere in AP_Relay — I have aPR to add that for future use in hwdefs. The only hwdef-level relay macro is RELAY1_PIN_DEFAULT (which is set correctly, 81). The relay's boot state is a runtime parameter (AP_Relay_Params.cpp), hardcoded to DefaultState::OFF at compile time with no hwdef override — it has to be set via RELAYn_DEFAULT=1 in defaults.parm. As it stands this board has no defaults.parm at all, so RELAY1 (VTX power) will default OFF at boot despite the README claiming otherwise and despite PC14 VTX_PWR OUTPUT HIGH in the hwdef — AP_Relay::init() overwrites that raw level with the (OFF) parameter default once it runs. Remove the dead define RELAY1_DEFAULT 1 line and add the real fix below.

defaults.parm (missing)

This PR has no defaults.parm file. It needs one with at least:

RELAY1_DEFAULT=1
SERVO9_FUNCTION=120

RELAY1_DEFAULT=1 is what actually makes VTX power default ON (see above). SERVO9_FUNCTION=120 is needed for the addressable LED on PWM9 to work plug-and-play — DEFAULT_NTF_LED_TYPES 455 in the hwdef alone isn't sufficient without the output being assigned the LED function.

Re-request my review when these changes are made.

[Hwurzburg]

Preliminary

The last two commits both touch AP_HAL_ChibiOS (AP_HAL_ChibiOS: add HGLRC_H743_PRO board support and AP_HAL_ChibiOS: fix HGLRC H743 PRO defaults) — the second is a fixup of the first, same three files. Please squash those into one AP_HAL_ChibiOS: commit before merge.

hwdef.dat / defaults.parm

DEFAULT_SERIAL1_PROTOCOL is set to SerialProtocol_MSP_DisplayPort, but nothing sets OSD_TYPE2. Without OSD_TYPE2=5 the DisplayPort/MSP OSD backend never gets instantiated, so SERIAL1 sits idle even though the README documents it as the board's default HD-VTX/DisplayPort port. Add to defaults.parm:

OSD_TYPE2 5

RELAY1_DEFAULT=1 (VTX power boot state) is set in defaults.parm, but AP_Relay now takes a compiled RELAYn_DEFAULT default directly in hwdef, the same way RELAYn_PIN_DEFAULT already works. Move it next to RELAY1_PIN_DEFAULT in hwdef.dat instead:

define RELAY1_PIN_DEFAULT 81
define RELAY1_DEFAULT 1

and drop the RELAY1_DEFAULT=1 line from defaults.parm.

README.md

OSD Support doesn't mention the DisplayPort/HD-VTX path SERIAL1 is wired for by default. Once OSD_TYPE2 is added above, document it here:

## OSD Support

The HGLRC H743 PRO has an onboard AT7456E analog OSD, enabled by default with `OSD_TYPE=1`. SERIAL1 defaults to MSP DisplayPort protocol, and `OSD_TYPE2` is set to `5` by default to enable simultaneous DisplayPort OSD for an HD VTX. Connect an analog camera to `C1` or `C2` and the analog video transmitter to `VTX`.

The board silkscreens the camera pads C1/C2, not CAM1/CAM2 — Camera Switch should use the labels actually printed on the board:

The analog video input can be switched between `C1` and `C2` using GPIO 82, which is assigned to Relay 2 by default. Assign an RC channel the `Relay2 Control` auxiliary function to select the camera.

PWM Outputs undersells bidirectional DShot. Tagging one channel of a timer pair BIDIR
makes both channels in that pair capable, not just the tagged one — TIM1_CH1+TIM1_CH3
cover both of TIM1's pairs (PWM1-4), and TIM4_CH1+TIM4_CH3 cover both of TIM4's pairs
(PWM5-8). So all 8 outputs support bidirectional DShot, not just 1/3/5/7:

- PWM 1 to 4 use TIM1 and support DShot and bidirectional DShot with RPM telemetry
- PWM 5 to 8 use TIM4 and support DShot and bidirectional DShot with RPM telemetry

Re-request my review when these changes are made.

[Hwurzburg]

based on some changes you made for Andy's comments, I re-reviewed and caught some things that need updating now that his requests are resloved

[andyp1per]

Think you changed the wrong line

[HGLRC-T]

@andyp1per Any other problem?

[Hwurzburg]

One issue found while auditing VTX-power-pin/bootloader consistency across in-tree and open board PRs.

[HGLRC-T]

Hope to see support for ArduPilot as soon as possible. betaflight/config#944 @andyp1per @Hwurzburg Are there any other concerns regarding the merger?

[Hwurzburg]

Preliminary

This no longer builds on current master. Since your last push, master's hwdef generator has made ALLOW_ARM_NO_COMPASS a hard error, so configure fails with:

Error: ALLOW_ARM_NO_COMPASS is no longer used; remove it from your hwdef (use ARMING_SKIPCHK to skip compass checks)

Remove define ALLOW_ARM_NO_COMPASS from hwdef.dat and rebase on master, so CI re-runs against the current tree.

hwdef.dat

• The GPS connector (the one with T7/R7 and DA/CL) is UART7, which is SERIAL7. But SERIAL3 (USART3) also defaults to GPS, and it comes first, so the first GPS is looked for on SERIAL3. SERIAL7 only becomes the second GPS, which is off by default (GPS2_TYPE = 0). As shipped, a GPS plugged into the GPS connector isn't detected. The README already calls SERIAL3 "GPS or general-purpose serial", so set it to None:

define DEFAULT_SERIAL3_PROTOCOL SerialProtocol_None

and change SERIAL3's Default use in the README table to None.

• This board needs DFU for its first firmware load, so it most likely ships running Betaflight. Consider adding define HAL_FRAME_TYPE_DEFAULT 12 (as HGLRC_H743_EVO does) to ease the transition to ArduPilot for Betaflight users of this board (not a blocker).

README.md

• OSD Support: add the protocol-change caveat:

Note: if `SERIAL1_PROTOCOL` is ever changed from MSP DisplayPort, `OSD_TYPE2` must be set to `0`, or a pre-arm failure will result.

Also needs merge conflict resolution now...since you will need to fixup the commit tree again after these changes, use hwdef instead of AP+HAL_ChibiOS...its the new preference for library name

Re-request my review when these changes are made.

[HGLRC-T]

Preliminary

This no longer builds on current master. Since your last push, master's hwdef generator has made ALLOW_ARM_NO_COMPASS a hard error, so configure fails with:

Error: ALLOW_ARM_NO_COMPASS is no longer used; remove it from your hwdef (use ARMING_SKIPCHK to skip compass checks)

Remove define ALLOW_ARM_NO_COMPASS from hwdef.dat and rebase on master, so CI re-runs against the current tree.

hwdef.dat

• The GPS connector (the one with T7/R7 and DA/CL) is UART7, which is SERIAL7. But SERIAL3 (USART3) also defaults to GPS, and it comes first, so the first GPS is looked for on SERIAL3. SERIAL7 only becomes the second GPS, which is off by default (GPS2_TYPE = 0). As shipped, a GPS plugged into the GPS connector isn't detected. The README already calls SERIAL3 "GPS or general-purpose serial", so set it to None:

define DEFAULT_SERIAL3_PROTOCOL SerialProtocol_None

and change SERIAL3's Default use in the README table to None.

• This board needs DFU for its first firmware load, so it most likely ships running Betaflight. Consider adding define HAL_FRAME_TYPE_DEFAULT 12 (as HGLRC_H743_EVO does) to ease the transition to ArduPilot for Betaflight users of this board (not a blocker).

README.md

• OSD Support: add the protocol-change caveat:

Note: if `SERIAL1_PROTOCOL` is ever changed from MSP DisplayPort, `OSD_TYPE2` must be set to `0`, or a pre-arm failure will result.

Also needs merge conflict resolution now...since you will need to fixup the commit tree again after these changes, use hwdef instead of AP+HAL_ChibiOS...its the new preference for library name

Re-request my review when these changes are made.

@Hwurzburg Done.

[github-actions]

Global Size Summary (Total Flash delta in bytes)

Built from d21731e rebased onto 6743a33

Board	Periph	tracker	blimp	bootloader	copter	heli	iofw	plane	rover	sub
DrotekP3Pro	_	_	_	*	_	_	_	_	_	_
Durandal	_	*	*	_	*	*	_	*	*	*
Hitec-Airspeed	*	_	_	_	_	_	_	_	_	_
KakuteF7	_	*	*	_	*	*	_	*	*	*
MambaH743v4	_	*	*	_	*	*	_	*	*	*
MatekF405-CAN	_	_	_	*	_	_	_	_	_	_
MatekF405	_	*	*	_	*	*	_	*	*	*
MatekH743-bdshot	_	*	*	_	*	*	_	*	*	*
Pixhawk1-1M	_	*	*	_	*	*	_	*	*	*
disco	_	*	*	_	*	*	_	*	*	*
f103-GPS	*	_	_	_	_	_	_	_	_	_

[Hwurzburg]

Thanks, all the previous asks are done. A few remaining items:

README.md

• UART Mapping: UART4 only brings out RX (R4 on the HD VTX connector), and its default protocol is None, so "General-purpose serial" isn't accurate. Change SERIAL4's Default use to None and add a note that R4 on the HD VTX connector can be used for SBUS from an HD air unit by setting SERIAL4_PROTOCOL to 23, after changing SERIAL2_PROTOCOL away from RC input (only one UART can be the RC input). Also, the Features list says only UART5 is RX-only; UART4 is too:

- 7 UARTs, with UART4 and UART5 exposed as RX-only

• The README doesn't say where the addressable LED pad and the buzzer connections are, and I can't read the labels on the 6-pin connector at the bottom edge of the bottom image at this resolution. Name the pads/connector for the LED and buzzer in the PWM Outputs section, and provide a higher-resolution image (or a labeled pinout drawing) if those labels aren't legible.

• Loading Firmware: use the standard wording, which loads bootloader and firmware in one step and says where the file comes from:

To load ArduPilot firmware, hold the `PWR BUT` button (next to the USB-C connector) low while powering up the board. Then use the STM32CubeProgrammer app to load the "***_with_bl.hex" file, available from the `HGLRC_H743_PRO` folder on the [ArduPilot firmware server](https://firmware.ardupilot.org). Subsequently, a ground control station can update firmware using the `*.apj` files.

hwdef.dat

• The UART comments no longer match the defaults, update them:

# USART3 - spare

# UART4 - RX only, on the HD VTX connector (R4)

Re-request my review when these changes are made.

[HGLRC-T]

Thanks, all the previous asks are done. A few remaining items:

README.md

• UART Mapping: UART4 only brings out RX (R4 on the HD VTX connector), and its default protocol is None, so "General-purpose serial" isn't accurate. Change SERIAL4's Default use to None and add a note that R4 on the HD VTX connector can be used for SBUS from an HD air unit by setting SERIAL4_PROTOCOL to 23, after changing SERIAL2_PROTOCOL away from RC input (only one UART can be the RC input). Also, the Features list says only UART5 is RX-only; UART4 is too:

- 7 UARTs, with UART4 and UART5 exposed as RX-only

• The README doesn't say where the addressable LED pad and the buzzer connections are, and I can't read the labels on the 6-pin connector at the bottom edge of the bottom image at this resolution. Name the pads/connector for the LED and buzzer in the PWM Outputs section, and provide a higher-resolution image (or a labeled pinout drawing) if those labels aren't legible.
• Loading Firmware: use the standard wording, which loads bootloader and firmware in one step and says where the file comes from:

To load ArduPilot firmware, hold the `PWR BUT` button (next to the USB-C connector) low while powering up the board. Then use the STM32CubeProgrammer app to load the "***_with_bl.hex" file, available from the `HGLRC_H743_PRO` folder on the [ArduPilot firmware server](https://firmware.ardupilot.org). Subsequently, a ground control station can update firmware using the `*.apj` files.

hwdef.dat

• The UART comments no longer match the defaults, update them:

# USART3 - spare

# UART4 - RX only, on the HD VTX connector (R4)

Re-request my review when these changes are made.

OK.