Add bidirectional DShot ESC telemetry

[halfmanbear]

Ports bidirectional DShot (GCR) telemetry from Betaflight, enabling RPM-based gyro filtering without a dedicated ESC telemetry UART.

After each DShot output frame the motor pin is switched to timer input capture mode via per-channel DMA to receive the ESC's GCR-encoded eRPM response. The decoded eRPM feeds the existing RPM filter infrastructure.

New settings:

• dshot_bidir_enabled: enable bidirectional DShot telemetry
• dshot_edt_enabled: enable Extended DShot Telemetry (temperature, voltage, current in addition to eRPM)

Changes:

• drivers/dshot.c/.h: GCR decode, EDT frame parsing, eRPM-to-RPM conversion, motor frequency LPF (ported from Betaflight, GPLv3)
• drivers/pwm_output.c: per-channel DMA direction switching between DShot output and GCR input capture on STM32 (StdPeriph/HAL) and AT32
• sensors/esc_sensor.c/.h: DShot bidir data path into ESC sensor framework (escSensorSetDshotData, escSensorIsActive)
• flight/rpm_filter.c: DShot telemetry as frequency source alongside serial ESC sensor path
• target/common_post.h: USE_RPM_FILTER enabled for any USE_DSHOT target
• fc/fc_init.c: call initDshotTelemetry() at startup; fix RPM filter init condition to accept DShot bidir as a valid source
• blackbox/blackbox.c: fix NULL dereference when escSensorGetData() returns NULL; fix uninitialized blackboxSlowState_t comparison
• telemetry/srxl.c: replace Betaflight-specific USE_DSHOT_TELEMETRY guards with INAV's USE_DSHOT/USE_ESC_SENSOR; use escSensorGetData()

Tested on SPEEDYBEEF405V4 (STM32F405, StdPeriph) with Bluejay ESC firmware. eRPM telemetry confirmed in blackbox;

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[github-actions]

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

• maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

• maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

---

This is an automated suggestion to help route contributions to the appropriate branch.

[Jetrell]

Have you had a chance to look at log data. To compare the latency improvement bdshot dynamic notch has over the matrix filter ? Or even over ESC telemetry RPM, to be sure it's working correctly.

[halfmanbear]

Have you had a chance to look at log data. To compare the latency improvement bdshot dynamic notch has over the matrix filter ? Or even over ESC telemetry RPM, to be sure it's working correctly.

I can't compare with any ESC UART telemetry as my stack doesn't support this (see below). One of the main reasons for implementing bidirectional DSHOT.

[Jetrell]

@halfmanbear INAV is about to enter the 9.1 release phase. Once that is finished I will conduct some testing.

[sensei-hacker]

Thanks for your work in this.
I have a pile of notes about bidirectional DSHOT that I will go through and compare your implementation here.

Getting it to work is one thing, the impact on performance with everything else on a hexcopter running on a less-capable chip another issue.

[course-up]

I can't compare with any ESC UART telemetry as my stack doesn't support this (see below). One of the main reasons for implementing bidirectional DSHOT.

For testing you can flash Bluejay, it is the recommended firmware with all new features for old BLHELI_S
I reflashed all my BLHELI_S ESCs with Bluejay for iNav and Betaflight drones and they are working great.

[sensei-hacker]

Thanks again for all of your work on this. Sorry it took so long for me to review.
There is a lot to look at and consider, even with an AI tool assisting me in reading through the history Betaflight has had with bidirectional Dshot, the data sheets, etc.

Going through your excellent PR, it looks like it mostly matches the plan I had put together but didn't actually implement in full. Since we independently came up with the same design, that might be a hint that it's a good design. :) I could go over various points that look good, but suffice to say - nice work!

It is my understanding that on the H7, the D-cache means DMA-written data isn't automatically visible to the CPU without `SCB_InvalidateDCache_by_Addr() being called, so we may need to call that? F7 has the same D-cache, but it's disabled in INAV.

I currently see the build fails with:
/home/runner/work/inav/inav/src/main/drivers/pwm_output.c:367:17: error: 'dshotDmaStream' defined but not used [-Werror=unused-function]
367 | static uint32_t dshotDmaStream(const pwmOutputPort_t *port)

There may be a need to gate this on #if (MCU_FLASH_SIZE > 512), for F722.

It's my understanding this won't work in CH1N-CH4N, which is probably okay because it looks no targets use that on the first four outputs (quad motors). But we'd need to keep the unidirectional DShot for hexacopters and octocopters.
Similarly for these outputs which need DMAR:

┌───────────────────
│ target_name │ Output number
├───────────────────
│ AXISFLYINGH743PRO │ 12
│ DAKEFPVH743 │ 8
│ DAKEFPVH743 │ 10
│ DAKEFPVH743PRO │ 12
│ DAKEFPVH743_SLIM │ 12
│ HAKRCH743 │ 8
│ HAKRCH743 │ 10

[sensei-hacker]

A note re F722 for future reference: this feature would add 2,972 bytes of flash.
We might be able to find something that size to remove, if we chose to.

[sensei-hacker]

Current build errors:

ggdb3 -DNDEBUG -std=gnu99 -flto=auto -fno-fat-lto-objects -ffunction-sections -fdata-sections -fno-common -mthumb -mcpu=cortex-m4 -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -Wdouble-promotion -Werror -O2 -Wall -Wextra -Wunsafe-loop-optimizations -Wstrict-prototypes -Werror=switch -MD -MT src/main/target/FF_F35_LIGHTNING/CMakeFiles/WINGFC.elf.dir///drivers/pwm_output.c.obj -MF src/main/target/FF_F35_LIGHTNING/CMakeFiles/WINGFC.elf.dir///drivers/pwm_output.c.obj.d -o src/main/target/FF_F35_LIGHTNING/CMakeFiles/WINGFC.elf.dir///drivers/pwm_output.c.obj -c /home/runner/work/inav/inav/src/main/drivers/pwm_output.c
/home/runner/work/inav/inav/src/main/drivers/pwm_output.c:367:17: error: 'dshotDmaStream' defined but not used [-Werror=unused-function]
367 | static uint32_t dshotDmaStream(const pwmOutputPort_t *port)
| ^~~~~~~~~~~~~~
cc1: all warnings being treated as errors
[199/3225] Building C object src/main/target/FF_F35_LIGHTNING/CMakeFiles/WINGFC.elf.dir///drivers/pinio.c.obj
[200/3225] Generating ZEEZF7V2/settings_generated.h, ZEEZF7V2/settings_generated.c

Also:
'Error: "docs/Settings.md" is not up to date, please run "src/utils/update_cli_docs.py"'