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.
The “Event System” is really good for that too.
The most simple of logic / signaling doesn’t require the CPU anymore. Its truly a system where combinations of pieces leads to a large number of simple designs.
“Modern AVR” is very much about these peripherals. No, you don’t get as much compute as the 32-bitters (Cortex M0+ or whatever). But by being able to do so much dumb logic without waking up, AVR reaches into absurdly low-power design spaces. There’s just so much that can happen while sleeping now, its kind of insane.
Alas, its not very easy to design like this. But that’s what makes it a fun hobby at least! “Simple Logic” but… it ends up touching like 5 different peripherals tied together with the Event system in not the easiest to understand initialization code to write…
I hate to say it but I never really got into the event system properly. It was quicker and easier to implement my solution using a traditional by the book approach with timers/interrupts. No, it wasn’t very power efficient, but it got the job done. Keep in mind I was using AVR in academics and home projects not in industry.
It does look really cool. I feel like high-quality firmware engineering is rarely seen in the field. I’ve pulled a lot of firmware and seen a lot of questionable practice, but the really good developers? It seems like they move into ASIC design or support higher end SoCs. Juicing an AVR for every drop of performance seems like a lost art from my vantage point in the same way that video games rarely use tricks to optimize for memory or storage because it doesn’t make a economic sense to do so.
We have the smart devices everywhere in their firmware is usually garbage.
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.