There are practical limits to how many software timers that can be realistically supported. One has to look at the MCU instruction cycle rate and then look at how many cycles it takes to check for a timer being zero and decrementing it if not zero. The absolute maximum number of software timers is limited to the number of cycles per timer interrupt minus the fixed interrupt overhead minus the (number of cycles per timer test/decrement times the number of timers).

After this consideration you have to decide how much time you are willing to allocate to the timer interrupt thread as a total percentage of the full processor real time bandwidth. As a worst case if you program a number of timers that approaches the maximum outlined above you can spend up to 100% of the MCU time in the timer interrupt routine and not allow any work in the main line code to get done.

In my applications I always try to design my systems so that the time spent in the timer interrupt is less than about 2% of the processor bandwidth. I may have to make this even less if I am making an application that has other high bandwidth I/O or SFR activity that would break if occasional blips of 2% latency causes problems.

These software timers really shine on the more modern MCUs that have single cycle instruction timing equal to the oscillator frequency. On the older "12 clocker" types the number of cycles per timer in the interrupt routine is fairly expensive performance wise. Of course if the MCU is performing some trivial task and only using a single software timer or two then the performance is not a big deal. On the other hand if you have the time budget of the MCU packed full this 12clocker can be a non-starter.

Michael Karas