-
Notifications
You must be signed in to change notification settings - Fork 1
CPU Consumption
The ATMega microprocessors are 8-bit systems driven at 16MHz so there aren't all that many free CPU cycles to begin with. Since this library uses TIMER1 and software interrupts to perform PWM as well as using an interrupt on TIMER0 for active fading & brightening of the LED it will have an adverse impact on the main sketch.
Most of the time this is not an issue, since often programs are waiting using calls to "delay()" or are cycling in loops and polling. In those cases the overhead for this library will not be noticed. But time-critical sketches are at risk of not working correctly while there are one or more LEDs that are actively doing PWM. The library will switch off the expensive interrupt on TIMER1 if the LEDs are either ON or OFF, since that doesn't require any work.
Setting the hertz() helps quite a bit, but unfortunately low PWM values at low hertz values introduces very noticeable flickering. Hence it makes sense to play with this setting in your application to find the lowest hertz() value where no flickering is visible.
The chart below shows how an active program would be slowed down with active PWM on LEDs. With multiple LEDs the number of them which have PWM values doesn't affect the performance significantly. The slowdown chart percentages are in percent slowdown, so a 100% slowdown means that the program runs double as long.
Hertz | 1 LED% | 2 LEDs% | 3 LEDs% | 4 LEDs% | 5 LEDs% | 6 LEDs% |
---|---|---|---|---|---|---|
off | 0% | 0% | 0% | 0% | 0% | 0% |
20 | 15.7% | 21.0% | 26.7% | 33.0% | 40.0% | 47.8% |
25 | 20.5% | 27.7% | 35.8% | 45.1% | 55.7% | 68.0% |
30 | 25.6% | 35.2% | 46.3% | 59.4% | 75.2% | 94.3% |
35 | 31.3% | 43.7% | 58.6% | 77.1% | 100.5% | 131.0% |
40 | 37.3% | 53.1% | 72.9% | 98.7% | 133.5% | 183.0% |
45 | 44.1% | 64.1% | 90.5% | 127.1% | 181.1% | 268.7% |
50 | 51.6% | 76.8% | 112.0% | 164.9% | 252.7% | 427.8% |
55 | 59.7% | 91.3% | 138.4% | 216.3% | 369.8% | 812.5% |
60 | 69.0% | 108.9% | 173.2% | 295.2% | 613.2% | - |
65 | 79.4% | 129.7% | 219.4% | 424.1% | - | - |
70 | 90.9% | 155.0% | 283.6% | 674.3% | - | - |
75 | 104.3% | 187.0% | 382.1% | - | - | - |
80 | 119.5% | 227.9% | 547.1% | - | - | - |
85 | 136.5% | 279.6% | 861.6% | - | - | - |
90 | 159.0% | 361.7% | - | - | - | - |
95 | 183.7% | 476.0% | - | - | - | - |
100 | 213.2% | 661.7% | - | - | - | - |
Any PWM value where the program slowdown is >1000% (meaning the program is 10x slower or just 1/10 of the time goes to the program and the rest is spent servicing PWM) is deemed unacceptable and isn't shown on the chart. If the program does nothing but waiting in "delay()" or similar loops then this would still work.