160 MHz CPU frequency

[flannelhead]

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.

[LeisureLadi]

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.
Secondly, the short duty cycle loop in the interrupt routine required multiplication by 10 instead of 4 and an additional decrement by 8 to take into consideration the interrupt overhead.
Thirdly, the decrement of 9 ticks in the long duty cycle interrupt routine had to be reduced to 2.

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.

[flannelhead]

@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.