-
Notifications
You must be signed in to change notification settings - Fork 46
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
160 MHz CPU frequency #15
Comments
Hi, I had to change all timing values to achieve at least nearly the pulse width, which I intended. Firstly, the transformation from absolute to relative timing: the number of ticks is decremented by 1, which appeared to me being not logic. I deleted that line. With these values I'm getting mire accurate pulse widths. I planned to redo the sorting and combining of duty cycles without phase shifting or at least a minimal phase shifting for short pulses, but this is not yet ready. The max phase shift for pulses will be 32 ticks multiplied by the number of channels. Shorter pulses will be shifted less. Since I'm using gamma correction, longer pulses are likely to be not affected by phase shifting. |
160mHz from post: StefanBruens#15
@LeisureLadi, thanks for chiming in. The numbers you have arrived at look very similar to mine. There's some difference due to me using the library on esp-open-rtos which has a different interrupt overhead. By the way, has anyone noticed gcc optimizing away the busy-waiting loop in the interrupt handler? I noticed that compiling with -O2, I had to rewrite the busy-wait loop in inline assembly to prevent it from being optimized away. |
Hi,
First of all, thanks for this awesome library! I've been using it a lot.
Second, I began wondering if the timing works correctly when the CPU frequency is set to 160 MHz. As far as I can tell from the documentation, the bus frequency doesn't change if CPU frequency is changed, so neither should the timer base clock.
Then there's the question of interrupt overhead. Do you think the interrupt overhead is memory-induced and thus wouldn't be affected by the CPU frequency?
The busy wait loop at https://github.com/StefanBruens/ESP8266_new_pwm/blob/master/pwm.c#L132 at least needs changing - instead of multiplying by 4, we should probably multiply by 8 when CPU frequency is doubled.
I'm willing to do some experiments, but it would be nice to hear what you know about this.
The text was updated successfully, but these errors were encountered: