Skip to content
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

PWM duty cycle is not kept when frequency is changed #68

Open
niziak opened this issue Jan 2, 2024 · 1 comment
Open

PWM duty cycle is not kept when frequency is changed #68

niziak opened this issue Jan 2, 2024 · 1 comment

Comments

@niziak
Copy link

niziak commented Jan 2, 2024

As a user I assume that once set duty cycle to 50% (value 0.5) is kept when frequency is changed.
Currently it is not possible to raise frequency over twice of initial value without zeroing duty cycle and setting it again to 0.5.

Exact issue was already described here: google-coral/edgetpu#153

It will be nice to have interface which keeps duty cycle at initial percent level for any frequency without zeroing it and setting again every time.

@vsergeev
Copy link
Owner

vsergeev commented Jan 13, 2024

There isn't an immediately obvious solution here because changes to both duty cycle and period / frequency can't be atomic. While it's true that python-periphery could preemptively update duty_cycle before changing period, this would also briefly drive the wrong duty cycle at the previous frequency until the period is updated. I don't think that's a good side effect for the library to have.

The most guidance we have from the sysfs documentation (https://docs.kernel.org/driver-api/pwm.html) is that the duty cycle "must be less than or equal to the period."

Perhaps one approach for frequency/period changes in the library would be to first disable PWM (through enable), update both duty cycle and period, and then re-enable PWM. Given that the most PWM applications are conveying information through the duty cycle, and frequency changes are atypical, this would probably address your concern and most use cases. However, it would be at the expense of a temporarily disabled output for frequency changes.

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

No branches or pull requests

2 participants