-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add STM32 HAL FAST_PWM feature #20025
Merged
thinkyhead
merged 3 commits into
MarlinFirmware:bugfix-2.0.x
from
victorrar:stm32-fast-pwm
Nov 4, 2020
Merged
Add STM32 HAL FAST_PWM feature #20025
thinkyhead
merged 3 commits into
MarlinFirmware:bugfix-2.0.x
from
victorrar:stm32-fast-pwm
Nov 4, 2020
+76
−4
Conversation
This file contains 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
(cherry picked from commit de2e86c)
I just tested this on a BigTreeTech BTT002 (aftermarket 32-bit Prusa MK3S board) which is an Just to make sure it wasn't a stuck mosfet, I re-flashed with Edit: Issue opened #20028 |
FhlostonParadise
pushed a commit
to FhlostonParadise/Marlin
that referenced
this pull request
Nov 21, 2020
vgadreau
pushed a commit
to vgadreau/Marlin
that referenced
this pull request
Dec 9, 2020
tharts
pushed a commit
to tharts/Marlin
that referenced
this pull request
Jan 6, 2021
dpreed
pushed a commit
to dpreed/Marlin_2.0.x
that referenced
this pull request
Feb 5, 2021
kpishere
pushed a commit
to kpishere/Marlin
that referenced
this pull request
Feb 19, 2021
W4tel-BiDi
pushed a commit
to W4tel-BiDi/Marlin
that referenced
this pull request
Apr 5, 2021
chrisjenda
pushed a commit
to chrisjenda/Marlin
that referenced
this pull request
Apr 5, 2021
thinkyhead
pushed a commit
to thinkyhead/Marlin
that referenced
this pull request
Apr 28, 2021
thinkyhead
pushed a commit
to thinkyhead/Marlin
that referenced
this pull request
Apr 29, 2021
thinkyhead
pushed a commit
that referenced
this pull request
Apr 30, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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.
Description
Add a fast_pwm feature to the STM32 HAL. Ported from STM32F1
Benefits
Fast_pwm for generic STM32
Configurations
Any with FAST_PWM enabled
Related PR
#19952
P.S.
Seems like the currently active task is timers organization. I've found, that
TimerConfig timerConfig[NUM_HARDWARE_TIMERS];
is currently storing only "used" timers: stepper and temperature and#define NUM_HARDWARE_TIMERS 2
. So, maybe better to reserve space for all available hardware timers and don't define extra timer's indexes#ifndef STEP_TIMER_NUM
#define STEP_TIMER_NUM 0 // Timer Index for Stepper
#ifndef STEP_TIMER
#define STEP_TIMER MCU_STEP_TIMER
#define MCU_STEP_TIMER 4
(suggest to replace STEP_TIMER_NUM by STEP_TIMER)
P.S.S
Firstly, I wanted to create that array for tracking timers but was found the
pwm_start
function, that uses the framework's implicit array for that purpose. But for maintaining the highest level of abstraction and usage that function inset_pwm_duty
we need to somewhere store desired frequencies. So. I have a dilemma: duplicate data (save another explicit HardwareTimer objects or have an array of frequencies) or duplicate the framework functionality (start_pwm function almost perfectly fits inset_pwm_frequency
function with its timer storage and checks.