fix(dshot): pick bit width per timer clock for accurate rate#27402
Open
dakejahl wants to merge 1 commit into
Open
fix(dshot): pick bit width per timer clock for accurate rate#27402dakejahl wants to merge 1 commit into
dakejahl wants to merge 1 commit into
Conversation
github-actions
Bot
added
the
kind:bug
dakejahl
force-pushed
the
fix-dshot-bit-width-derive-from-clock
branch
2 times, most recently
from
2e652ac to
9881efb
Compare
Auto-selects DSHOT_MOTOR_PWM_BIT_WIDTH per timer clock at compile time
so ARK FPV emits DSHOT at the same bit period as the rest of the fleet.
The hardcoded WIDTH=20 truncates the prescaler on ARK FPV's 160 MHz APB1
(PLL1N=40, floor(160e6/600e3)=266 not divisible by 20), giving a 1.706us
bit period and 66.7%/33.3% duty cycles (vs DSHOT600 spec 75%/37.5%).
The new ladder tries WIDTH in {20, 19, 18} and picks the first that
divides cleanly. ARK FPV lands on W=19, matching the 1.75us bit period
of the 240 MHz boards. Duty cycles improve to 70%/35%. 240/96/108/84 MHz
boards keep W=20 (unchanged). 200 MHz boards (CubeOrange/Orange+,
h7extreme) fall through to W=20 (unchanged, fix needs W=22 with scaled
BIT_1/BIT_0 -- out of scope).
A #pragma message (not #warning, which -Werror=cpp would treat as an
error) flags boards where APB1 and APB2 timer clocks would emit DSHOT
at different rates -- currently only fmu-v4pro (APB1=90, APB2=180 MHz).
The whole block is guarded on STM32_APB2_TIM8_CLKIN so STM32F1 IO
co-processor boards (no TIM8, header still pulled in by io_timer.c)
keep W=20 silently.
Supersedes PX4#27401.
dakejahl
force-pushed
the
fix-dshot-bit-width-derive-from-clock
branch
from
9881efb to
edbb0af
Compare
julianoes
reviewed
May 20, 2026
Contributor
julianoes
left a comment
julianoes
left a comment
There was a problem hiding this comment.
Could we do this properly generically without hard-coding to 20 and the exception added here?
Contributor
Author
Would you mind spending some tokens on it? |
Contributor
|
I can give it a try next week. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Auto-selects
DSHOT_MOTOR_PWM_BIT_WIDTHper timer clock at compile time so ARK FPV emits DSHOT at the same bit period as the rest of the fleet. Supersedes #27401.Problem
io_timer_set_dshot_burst_mode()setsARR = WIDTHandPSC = floor(CLK/DSHOT_FREQ)/WIDTH - 1with hardcodedWIDTH = 20. The actual bit period is(PSC+1) * (ARR+1)timer-clock ticks. ARK FPV's 160 MHz APB1 (PLL1N=40) givesfloor(160e6/600e3) = 266, not divisible by 20 — BIT_1/BIT_0 duty cycles end up at 66.7%/33.3% vs DSHOT600 spec 75%/37.5%.#27401 fixed this with hardcoded
WIDTH = 19, but that breaks every F4/F7 board with an 84/108 MHz timer clock.Solution
Compile-time ladder against
STM32_APB1_TIM5_CLKIN: tryWIDTH ∈ {20, 19, 18}and pick the first wherefloor(CLK/600000) % W == 0. Falls back to 20 otherwise. ARK FPV lands on W=19; every other DSHOT-capable board keeps W=20 unchanged.Scope traces on ARK FPV (160 MHz APB):
ARK FPV's post-fix 1.75 us bit period matches all 240 MHz boards (FMU-v6X/v6S/PI6X, durandal, kakuteh7*, ctrl-zero-h7, etc.). 200 MHz boards (CubeOrange/Orange+, spracing/h7extreme) keep W=20 (unchanged — none of {20, 19, 18} divides 333; fix needs W=22 with scaled BIT_1/BIT_0, out of scope).
A
#warningflags boards where APB1 and APB2 timer clocks would emit DSHOT at different rates (currently onlyfmu-v4pro: APB1=90 MHz, APB2=180 MHz — pre-existing on master, not regressed by this PR).Builds verified on
ark_fpv_default,ark_fmu-v6x_default,ark_cannode_default,cubepilot_cubeorange_default.