I don't believe this is a major issue, but it is worth noting this limitation in PortCE.
If PortCE_update_timers() is called too quickly, then it is possible that not enough time has passed to advance the clock/timers. This caused issues where the timer never advanced leading to infinite loops. The fix I employed was to not update the timers if the last update request was less than one time interval to guarantee forward progression.
if (delta_32K == 0 || delta_CPU == 0) {
// Prevents infinite loops if not enough time passes between updates
return;
}(The CPU clock can be set to other values, but lets assume it is set to 8MHz here)
Both the 32KHz clock and the 8MHz clock need to progress for the clocks/timers to be updated. This means that the 8MHz clock won't progress until the slower 32KHz clock has progressed too, meaning that the that while the 8MHz clock is precise to 1/8000000 seconds, it won't return an internal that is less than 1/32768 seconds.
I don't believe this is a major issue, but it is worth noting this limitation in PortCE.
If
PortCE_update_timers()is called too quickly, then it is possible that not enough time has passed to advance the clock/timers. This caused issues where the timer never advanced leading to infinite loops. The fix I employed was to not update the timers if the last update request was less than one time interval to guarantee forward progression.(The CPU clock can be set to other values, but lets assume it is set to 8MHz here)
Both the 32KHz clock and the 8MHz clock need to progress for the clocks/timers to be updated. This means that the 8MHz clock won't progress until the slower 32KHz clock has progressed too, meaning that the that while the 8MHz clock is precise to 1/8000000 seconds, it won't return an internal that is less than 1/32768 seconds.