Skip to content

fix pwm overflow - #2

Open
bugparty wants to merge 2 commits into
ok2cm:fnirsi_hs02_ok2cmfrom
bugparty:fix/pwm-uint16-upstream
Open

fix pwm overflow#2
bugparty wants to merge 2 commits into
ok2cm:fnirsi_hs02_ok2cmfrom
bugparty:fix/pwm-uint16-upstream

Conversation

@bugparty

Copy link
Copy Markdown
  • Please check if the PR fulfills these requirements
  • [ x] The changes have been tested locally
  • [ x] There are no breaking changes
  • What kind of change does this PR introduce?

fixing pwm overflow bug, when you set the max power limit to 100W

  • What is the current behavior?

if you set the max power to 100w, you can actually get 10-60w(depending on the overflowed values)

  • What is the new behavior (if this is a feature change)?
    Nope
  • Other information:

bugparty added 2 commits July 22, 2026 18:28
On the Fnirsi HS-02 the tip PWM period (powerPWM) is 395, but the
watts-to-PWM pipeline was typed uint8_t end to end:

  X10WattsToPWM() -> uint8_t   (clamps to powerPWM=395, then truncates)
  setTipPWM(const uint8_t pulse)

Any demand that scaled the PWM value above 255 wrapped modulo 256, so
the duty cycle collapsed. Concretely a full-power request of 395
truncated to 139, i.e. ~35% duty. This is why a power limit of <=90 W
reached the setpoint from cold but 100 W only delivered ~40-60 W.

Widen the value path to uint16_t (X10WattsToPWM return, setTipPWM pulse
across all BSPs, plus PWMToX10Watts / shouldBeUsingFastPWMMode). The
internally scaled value still fits uint8_t pendingPWM, and every other
device has powerPWM <= 255 so they are unaffected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant