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
Besides the same values, there is also the other bug, that the duration is about 3 µs too long for odd values and about 2 µs for even values.
About short enough durations I would like to discuss, because I am working about shared timers for pwm and tone at the same time. Currently I can manage 72 µs from end of the isr until the next beginning of the isr. But also the code in the isr consumes time.
Whith whom may I discuss the interface? For pwm I implemented an own loop for allowing also small values:
while(true) {
((void (*)()) (ptr->callback))(); // otherwise call it without parameter
int32_t pwm_ccount = expire_counts[TIMER_SHARED_PWM];
if(!pwm_ccount) {
timer_index = TIMER_NOT_KNOWN; // set flag for searching the next timer to expire
--shared_timer_count;
break;
}
if(pwm_ccount - asm_ccount() >= PWM_MIN_STEP)
break;
delay_ticks_inline(pwm_ccount - asm_ccount() - ISR_PWR_LOOP_LIMIT);
}
If the user isr callback would return the expire time, instead of calling a write function and if it's sure, that the isr will not be disabled within the isr itself, then this could save about 40 ticks (30 ticks would then be possible from end of the isr until to the next start) and would allow also the adjustment for the execution time of the pwm isr for the smallest value analogWrite(1)
The text was updated successfully, but these errors were encountered:
#4640 redid the whole PWM model to support tone/analogWrite/Servo/others. I believe we pulled out the logic analyzer and measured repeated PWM values much tighter than the older code. Closing this, but if you have something specific you can open a new issue (and PR to fix it would be nice).
I measured analogWrite for small and also other values.
There is this big bug in the algorithm, that always for two consecutive values the duration is equal.
This I measured:
The measurement was done in the pwm_timer_isr itself, by adding some lines of code:
And resetting for new analogWrite in __analogWrite:
And for testing I used this sketch:
Besides the same values, there is also the other bug, that the duration is about 3 µs too long for odd values and about 2 µs for even values.
About short enough durations I would like to discuss, because I am working about shared timers for pwm and tone at the same time. Currently I can manage 72 µs from end of the isr until the next beginning of the isr. But also the code in the isr consumes time.
Whith whom may I discuss the interface? For pwm I implemented an own loop for allowing also small values:
If the user isr callback would return the expire time, instead of calling a write function and if it's sure, that the isr will not be disabled within the isr itself, then this could save about 40 ticks (30 ticks would then be possible from end of the isr until to the next start) and would allow also the adjustment for the execution time of the pwm isr for the smallest value analogWrite(1)
The text was updated successfully, but these errors were encountered: