-
Notifications
You must be signed in to change notification settings - Fork 223
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
Accurate PWM #44
Comments
|
Not sure what you mean? We'll use the prescaler either way, the question is how it is initialized. Either we have an algorithm which takes a frequency and selects a fitting prescaler, or we leave it up to the user to decide manually. Actually, while thinking about it: Why not both? We could provide two separate constructors for 'automatic' and 'manual' configuration ...
In terms of precision, the two solutions don't differ too much. It's always a bit up to luck whether the integer values cleanly divide the timer steps. But we could, again, build a solution where all possibilities are accounted for and provide multiple methods for setting the duty-cycle based on exact timer counts, based on duration, or based on percentage.
Yes, definitely. PWM is a cheap way to create power output that scales linearly and for those usecases you mostly care about a percentage of the maximum power (= 100% duty cycle).
No, this belongs into the HAL only. |
I do like I can see no issue with using Fast PWM to control servo motors which have it's own controller. IMHO phase/frequency correct modes are needed if you are going to control coils directly. Biggest problem with servo is that you have to ensure no full cycles when you moving OCR value. Maybe it deserves separate method |
The existing PWM implementation is fixed to 1kHz and uses the Fast PWM mode which isn't phase- nor frequency-correct. This is rather useless for applications like controlling a Servo where an exact frequency and duty-cycle are needed.
So, in addition to the Fast PWM implementation a seconds "correct" PWM implementation should be added which allows specifying the frequency + duty cycle exactly. Ideally, this should be based on the rate and duration primitives from
embedded-time
.Open Questions:
Duty
type be a percentage or a duration?OCR0A
is either used for PWM onOC0A
, or as the timer period). How do we properly model this?The text was updated successfully, but these errors were encountered: