Modern AVR has a wide variety of Timers (TCA, TCB most commonly, but TCD, TCE, and TCF are uncommon and specific to particular AVR chips).
This can make choosing a AVR DD vs AVR EA vs AVR EB vs AVR DA a difficult choice, especially if you’re trying to use timers to their greatest extent possible.
This blogpost covers a basic idea of what the different timers offer.
The blogpost is short enough. I feel like what I can add is to highlight the difference between:
-
Timers – A background count++, a comparator of count vs some pre-configured values, and then likely an output pin that changes based off of these configurations. Consider this an MCU output. Almost everything listed can be used as a timer.
-
Counters – Counter functionality is an MCU input. Many protocols, such as Servos, PWM, pulse-train decoding requires a variety of pulse-frequency-modulation, pulse-counting, or wide variety of other kinds of common tasks. “TCB” may be called a “Timer”, but its really more of a counter-focused device which can more easily measure frequencies (for pulse-frequency-modulation). TCA and a few others can do some basic counting tasks, but usually not as well as TCB.
The other discussions in the blog are easy enough to understand IMO. This is all AVR specific, but some of the best material online are highly specialized articles like this, so I still feel like sharing.
Note: I’m a hobbyist as well. Still, I think these tools are clearly well designed to solve real problems (even if I haven’t attempted all these project ideas yet… I can see why Timers / EVSYS / CCL exists).
I 100% agree with the crux of your statement: the #1 goal of any programmer is to get something, anything working. You only keep working on it if its not sufficient to specs. Alas, the real world demands performance that even raw clocks cannot deliver.
Let me walk you through my thoughts on a simple MPPT tracker concept. Solar Panels can deliver varying amounts of power depending on cloud coverage, but also based on the amount of current drawn by a circuit. Using a boost (or buck) converter to change the current drawn (and assuming you have a Lead-acid “sink” that can absorb any extra power being generated) can lead to far more energy captured by the solar panels.
The first element you need to build is a boost converter. A high-efficiency boost converter consists of inductors + nmos + pmos. (The textbook bang-bang nmos + diode arrangement loses efficiency. Replacing the diode with a pmos is possible with a computer: just turn on the pmos whenever the diode “should” have turned on and you’re good).
This naturally leads to TCD
Lets say you’re building a 2MHz boost converter. The timings in the above waveform must be very well calibrated and consistent for the boost converter to function well. If the dead-time slips, you either lose efficiency of the boost converter, or you accidentally turn both the nmos + pmos on at the same time, leading you to accidentally short Vcc to Ground. Every part of the waveform is in fact realtime and MUST have exact timings matched at all times to function correctly.
A 2MHz boost converter with even a 200MHz processor gives you only 100 clock ticks per boost-converter cycle. And remember that within this 100-clock tick loop you need to handle a real-time dead-time / nmos-on / dead-time / pmos-on sequence of signals. Now add in all the logic for everything else you need to do (like MPPT) and I think it becomes clear that you don’t have enough CPU time even at 200MHz. Doesn’t matter if you use a simple loop or an interrupt, the number of clock cycles available here is actually quite low.
On an AVR DD however? Just set the clock to 16MHz and PLL to x3 (TimerD runs at 48MHz), and TimerD can handle all the dead-time/nmos-on/dead-time/pmos-on logic by itself, with more than enough processing power to spare for other tasks.
EVSYS does interact with timers by the way. Its not that EVSYS is ‘useful’ by itself, far from it. Its that timers are the powerful element at play here (allowing AVR to punch far above its weight class in practice). EVSYS’s main benefit is extending the applicability of timers.
From the perspective of “realtime” problems, where timing-specific on/off bitbanging is of utter huge importance… that’s where EVSYS / Timers / all these complex peripherals really shine. Finding the right situations (ex: MPPT controller) where it all lines up seems to be the key however.
You don’t want to add all this complexity to a “normal” project. You only add it because the project already was complex (which realtime-requirements always add gross amounts of complexity).
I just realized I wrote a wall of text saying that bit banging is less efficient lol and didn’t even cover EVSYS much. Ah well, hopefully it’s still good discussion for ya.