You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: