Auto detect PWM_MAX_INPUT_US so it's not hardcoded to a single frequency#1
Auto detect PWM_MAX_INPUT_US so it's not hardcoded to a single frequency#1jacobalberty wants to merge 6 commits intoAllted:masterfrom
Conversation
|
So after digging around using 0 to indicate PWM_MAX_INPUT_US means that if you do have a board that sends DC for a 100% duty cycle pwm then it will crash with divide by zero, I believe the other versions would result in a 0 duty cycle if they received DC for a 100% duty cycle. We could replicate this behavior by having PWM_INPUT_MAX default to -1 and then change line 135 to |
Use -1 as start value for MAX_PWM_INPUT_US this solves a potential divide by zero isse Clear MAX_PWM_INPUT_US and prev_value when spindle disabled
…it multiple times
|
Ok, last commit I promise. I cleaned up the behavior if it gets a DC 100% duty cycle so it will just behave like the original code instead of a divide by zero error by using -1 as the default value for MAX_PWM_INPUT_US. I also made it volatile which I forgot to do in the first place, and I'm storing micros() in a local variable and reusing instead of calling multiple times when doing the pulse width math. I'm also resetting MAX_PWM_INPUT_US and prev_value when the spindle is shut down to force re-detection of the pulse width. |
PWM_MAX_INPUT_US only works with ~490Hz as is. This pull request determines the correct PWM_PAX_INPUT_US and it has now been tested to work with my board running at ~50Hz
My only concern is I dont know is how map would behave with fromlow and fromhigh both being 0, but if it gives you the tohigh value then it should provide good behavior all around. In practice though on my board (A skr 1.3) at least it does not send true 100% duty cycle, there's still pulses so it's not an issue.