microcontroller timers explination

[drakejest]

hello i am in need of a quick crash course about timers. for intents and purposes i am concerned about the rp2040 timers to create a PWM signal and timer interrupts. I am more concerned about the concepts rather than actual code on how to execute it.

First questions when generating a PWM signals, are the toggling of the pins independent of the processor?  if the processor is running a task, that task will never be interrupted to toggle the PWM, meaning a pheripherral is doinng the toggling after its being set.

I have noticed on that the alt functions it would seem that a timer could have subchannels what does it mean? for example in the rp2040 GPIO 0 is PWM0 'A' and GPIO 1 is PWM0 'B'. what does the letter denotes and what could be the reason why there are subchannels? since they are both tied to the same timer does that mean that if activate the PWM of GPIO0 and GPIO1 they could not have different PWM frequency as they are tied to the same timer. Or that just means they can have different frequency but the clock pulses are synchronous because the source from the same timer. For the RP2040 there seems to be only 2 subchannels for each timer, but for other microconntrollers like the SAMD21 there could be more,

Speaking of SAMD21 they feature TCC or Timer/Counter for Controls ontop of the base T/C or timer/counters. How is TCC different from Tc?

Thank you for answering my questions

[jpanhalt]

Yes, the timers run independent of the MCU.  However, what you do with that fact doesn't.

[drakejest]

Yes, the timers run independent of the MCU.  However, what you do with that fact doesn't.

ahh so that means for every change state of the PWM signal the mcu gets interrupted and will have to flip the bits, is this right?

[Kleinstein]

The PWM runs independent and sets / resets the output pins. The 2 subchannels to a timer can generate 2 PWM signals with different PWM ratio, but the same frequency and usually with a fixed phase.

In addition to the PMW signal one can (but just for PWM no need to do so) also generate an interrupt signal.

[drakejest]

The PWM runs independent and sets / resets the output pins. The 2 subchannels to a timer can generate 2 PWM signals with different PWM ratio, but the same frequency and usually with a fixed phase.

In addition to the PMW signal one can (but just for PWM no need to do so) also generate an interrupt signal.

Is it possible to synchronize timers? for example for some odd reason, i need two pwm signals but im left with pins that are on different timers, so is it possible to spit out a for let say 1000 Hz 50% duty cycle on different timers that are synchronized?

another thing what if i want two PWM signals but the other one is an inverted copy of the first one? should that be done on the same or separate timers?

[jpanhalt]

It would help if you were more specific about what you want to do, not an endless series of "what if's."  There may also be differences between MCU's.  In general, PIC timers are synchronized to the system clock.  If you use an external source for Timer1, then you have a choice.

[westfw]

I am more concerned about the concepts

MCU Timers tend to be very ... specialized, and significantly different on different MCUs.  Most MCUs have several different types of timer.

So, in general (my personal model of "timers"):

• There is a clock source, configurable to a greater or lesser degree.  Sometimes fixed, sometimes a simple prescaler with various "power of 2" taps, sometimes more powerful.  Sometimes the clock can be an external signal.
• There is a counter register of some maximum width.  Sometimes the counter width is configurable.  Could count up, down, or both.
• (optionally) there are "compare" registers that do "something" when the counter reaches particular counts.  Could set/clear/toggle some pin (hardware PWM generation), could cause interrupt, could reset the counter or change the count direction.
• (optionally) there are "capture" registers that copy the counter value into some readable register when "something" happens (usually, a signal from some pin or internal peripheral.)  This gives you the ability to time signals more accurately than you could by examining the pin with a software loop.
• (optionally) a "top" register that signals when the counter should "wrap" to the "bottom" value (usually 0)  If not present, you have to wait for all N bits of the counter to overflow.  Sometimes, one of the 'compare' values is used as "top"
• (optionally) logic to create more complex waveforms and/or relationships between multiple timers.  For example, complementary or three-phase outputs with dead-time between one pin going true and the next pin going true, for driving H-bridges and such.  Also, "chaining" timers to create a 32bit counter from two 16bit counters, etc.
• (optionally) logic to generate interrupts at certain key points.  (wrap, compare match, capture)

Now, for the rp2040 specifically (looking at the datasheet, without having actually used them in any detail):

• There is a SysTick counter as part of each M0 CPU.  This is a 24bit counter that operates at the CPU frequency or a 1MHz clock, with progammable "top" that generates an interrupt at overflow This is usually used to generate a medium-low-frequency (1 kHz) "tick" off which various other events are based (ie for an RTOS.)  You can also use it for high-precision interval timing of relatively short events.
• There is a set of 8 PWM "slices."  Each slice has a 16bit counter, a clock input with fractional divisor, two Compare registers that can modify pins, an additional "top" value, and an interrupt that happens at wrap.  It looks quite nice for generating PWM signals, but it's a bit weak in the interrupt department (all 8 slices share the same interrupt.)  And no "capture" capability.
• There is a "Timer" peripheral that has a 64bit (!) counter driven from a 1MHz clock.  It's got 4 compare values (32bits), which they call "alarms", that generate separate interrupts.  (so, not very configurable.)
• There is an "RTC" timer designed to operate off of a 1 second clock and create interrupts (alarm) at human-scale times (year/month/day/etc)
• Supposedly the PIO can also be used to do timer-like things.  That'd be a whole new subject, though.

So...  No capture feature, no chaining, no "motor control" waveforms (at least, not directly supported.)

[drakejest]

I am more concerned about the concepts

MCU Timers tend to be very ... specialized, and significantly different on different MCUs.  Most MCUs have several different types of timer.

So, in general (my personal model of "timers"):

• There is a clock source, configurable to a greater or lesser degree.  Sometimes fixed, sometimes a simple prescaler with various "power of 2" taps, sometimes more powerful.  Sometimes the clock can be an external signal.
• There is a counter register of some maximum width.  Sometimes the counter width is configurable.  Could count up, down, or both.
• (optionally) there are "compare" registers that do "something" when the counter reaches particular counts.  Could set/clear/toggle some pin (hardware PWM generation), could cause interrupt, could reset the counter or change the count direction.
• (optionally) there are "capture" registers that copy the counter value into some readable register when "something" happens (usually, a signal from some pin or internal peripheral.)  This gives you the ability to time signals more accurately than you could by examining the pin with a software loop.
• (optionally) a "top" register that signals when the counter should "wrap" to the "bottom" value (usually 0)  If not present, you have to wait for all N bits of the counter to overflow.  Sometimes, one of the 'compare' values is used as "top"
• (optionally) logic to create more complex waveforms and/or relationships between multiple timers.  For example, complementary or three-phase outputs with dead-time between one pin going true and the next pin going true, for driving H-bridges and such.  Also, "chaining" timers to create a 32bit counter from two 16bit counters, etc.
• (optionally) logic to generate interrupts at certain key points.  (wrap, compare match, capture)

Now, for the rp2040 specifically (looking at the datasheet, without having actually used them in any detail):

• There is a SysTick counter as part of each M0 CPU.  This is a 24bit counter that operates at the CPU frequency or a 1MHz clock, with progammable "top" that generates an interrupt at overflow This is usually used to generate a medium-low-frequency (1 kHz) "tick" off which various other events are based (ie for an RTOS.)  You can also use it for high-precision interval timing of relatively short events.
• There is a set of 8 PWM "slices."  Each slice has a 16bit counter, a clock input with fractional divisor, two Compare registers that can modify pins, an additional "top" value, and an interrupt that happens at wrap.  It looks quite nice for generating PWM signals, but it's a bit weak in the interrupt department (all 8 slices share the same interrupt.)  And no "capture" capability.
• There is a "Timer" peripheral that has a 64bit (!) counter driven from a 1MHz clock.  It's got 4 compare values (32bits), which they call "alarms", that generate separate interrupts.  (so, not very configurable.)
• There is an "RTC" timer designed to operate off of a 1 second clock and create interrupts (alarm) at human-scale times (year/month/day/etc)
• Supposedly the PIO can also be used to do timer-like things.  That'd be a whole new subject, though.

So...  No capture feature, no chaining, no "motor control" waveforms (at least, not directly supported.)

Indeed this is really comprehensive..

Since this is a dual core mCu i do have some questions that might only be doable on a dual core mcu;

So setting a GPIO pwm, will it run independent of the cpu or the cpu will constantly be interrupted every overflock of the programmed "top"? if its the later, that means on for example the GPIO 0 which is connected to PWM 0  have a frequency of  lets say 1KHz but is assigned to core 1 and GPIO 1 which is still connected to PWM 0 but will be assigned to core 2 so i can have a different programmed "top" of lets say 2Khz[/li][/list]

In the datasheet there is this line "The 16 PWM channels (8 2-channel slices) " what is a "channel slice" ?

im also concerned by this statement by this line: If a PWM B pin is used as an input, and is selected on multiple GPIO pins, then the PWM slice will see the logical
OR of those two GPIO inputs. maybe i can understand better what this line means when i understand what is a channel slice  (bot of the lines are on page 545 of the datasheet)

[westfw]

The rp2040 PWM peripheral is indpendent of the cpu(s)
You do not need to enable the wrap interrupt.
You could have one slice interrupt cpu0 and one interrupt cpu1.  I’m not sure what happens if you have the same interrupt enabled on both cpus.
A slice is a clock source, a counter, and two compare registers.  So you could have 16 PWM outputs, but only 8 frequencies.
Using pin b as an input only comes into play when using the pin as a clock input.  Multiple pins can be configured as “PWM bit b”, and if you do so, the actual clock will be the logical or of all of those pins.

[Doctorandus_P]

A shorter answer (compared to westfw's) is that the timer is a physical piece of hardware somewhere on the chip. You tell it what to do by writing some bytes to configuration registers (Described in the datasheet) and after that it just keeps on doing what it is configured to do. It can count the CPU cycles (with or without a prescaler) or it can count external events on an I/O pin. Timers have options to generate interrupts when certain events happen (overflow, capture / compare, etc) but those are optional, an usually have to be enabled explicitly. For an interrupt to function properly, you have to write code for it, and you have to enable the interrupt in the configuration register for that peripheral (A global interrpt en/dis -able bit is also common, and more details...)

The same mechanism is also behind all other microcontroller peripherals, such as UsART's, SPI and I2C, I/O registers, etc.
You first configure a UsART (baudrate, number of bits, which interrupts to generate) and after that as soon as you write a byte to it's data register  it starts doing it's thing: It sends a start bit to an output pin, then shifts out the data bits and also adds a stop bit, and it does this all in hardware. It can also generate interrupts, but those are also optional.

Such concepts maybe easier to grasp if you have a look at old computers such as the Z80. (which is still popular in the "retro computing" communities) In such old systems the processor and it's peripherals are all different things in separate IC's and connected to each other with many wires in a bus system.

On microcontrollers this bus system is also present, but it is not accessible from the outside world. probably there is a block schematic near the beginning of your microcontroller with a block schematic. Each block is a separate piece of hardware, and the bus system that connects all these pieces is also drawn on it.

[emece67]

.

[SiliconWizard]

IMHO, the RP2040 architecture shows some quirks/oddities that turn it into a bad 1st chip for a beginner. Maybe another, single core, M0/M0+ from another manufacturer (say any stm32f0xx) can be a better choice to learn.

Well, if you use it as a real "beginner", thus with the provided Micropython, things are probably going to be pretty easy. But obviously limited.
Now if you want to use the C SDK and get closer to the metal, I agree with you.

[bson]

There is a SysTick counter as part of each M0 CPU.  This is a 24bit counter that operates at the CPU frequency or a 1MHz clock, with progammable "top" that generates an interrupt at overflow This is usually used to generate a medium-low-frequency (1 kHz) "tick" off which various other events are based (ie for an RTOS.)  You can also use it for high-precision interval timing of relatively short events.

SysTick is a standard ARM core peripheral that can always be counted on to be present (in the entire architecture family).

However, it's still possible to screw this up.  SysTick is prescaled by a "calibration" value, which can be problematic.  In the case of STM32F4x for example it's hard-wired to a specific value to produce a 1ms timer tick off a specific core clock.  So while SysTick is present, it can be badly hobbled in implementations.  It's also a very simple timer that can run at the core clock rather than the much slower APB bus clocks, so when available it's usually a good choice for scheduling (if you have a modern design that does high-resolution timekeeping, in e.g. 64-bit nanoseconds or core cycles or such).  A 1ms timer on the other, not terribly useful - other than for old legacy systems of course that used a fixed heartbeat, which also couldn't do scheduling at finer granularity.

Edit: thankfully, I misread the ST documentation on this!  I checked the ARM references again, and the calibration value is purely a constant that can be used in the reload register!  It's not a prescaler value at all.  So I totally have to retract some of the above.  How embarrassing.  Clearly my reading comprehension is rather lacking...

[westfw]

In the case of STM32F4x for example it's hard-wired ...

Several processors have a choice of clock for the systick.  For example, I believe the rp2040 defaults to the 1MHz clock rather than the CPU clock.
I'm pretty sure that using the CPU clock remains an option that can be configured, though, on every chip I've looked at.

(Thanks for the explicit correction.  I think the "calibration" value is a standard part of the Cortex spec.  The ARM v6m ARM says (B.3.31):   

• [size=0pt]SysTick operation [/size][/font]
  The timer consists of four registers...

• A calibration value register. This indicates the preload value required for a 10ms system clock.

I've never quite figured out how that's useful, since most chips have a wide variety of possible CPU clocks...
   

[drakejest]

Using pin b as an input only comes into play when using the pin as a clock input.  Multiple pins can be configured as “PWM bit b”, and if you do so, the actual clock will be the logical or of all of those pins.

This is good im starting to get a better grasp of things. A few more questions as i dont quite get this statement, So are you saying if i set GPIO 1,3,5 which is the PWM B of PWM 0, 1, 2 repsectively to INPUT mode and at the same time enable the multiplexer to the PWM, i would read the logical OR of the 3 PWM timers? on all the 3 GPIO pins? So if lets say the 3 pwm timers have different frequency and at a single tick PWM0 = 0 , PWM1 = 0, and PWM2 = 1, gpio 1,3,and 5 will see a 1 since that is the logical or of the PWM bits?

Is that right?

[westfw]

are you saying if i set GPIO 1,3,5 which is the PWM B of PWM 0, 1, 2 repsectively to INPUT mode and at the same time enable the multiplexer to the PWM, i would read the logical OR of the 3 PWM timers? on all the 3 GPIO pins?

No?

I think it means that if you set the "Function Select" for GPIO0 and GPIO17 both to "PWM0 B" (F4 - see section 2.19.2) AND you've configured the PWM slice that uses that pin to use it as an input, then whatever the slice does with that input (looks like: gate clock, count rising edges, count trailing edges) will be done with the OR of the two pins.  (I don't see any place where that's likely to be useful?  It seems to be a general feature of the GPIO pins and the function select logic, rather than something specific to the PWM peripheral.)

[jeremy0]

Is it possible to synchronize timers? for example for some odd reason, i need two pwm signals but im left with pins that are on different timers, so is it possible to spit out a for let say 1000 Hz 50% duty cycle on different timers that are synchronized?

The RP2040's PWM EN register (exposing all 8 slices' EN bits) is specifically for this purpose.

another thing what if i want two PWM signals but the other one is an inverted copy of the first one? should that be done on the same or separate timers?

You can use a single PWM slice.  Pins A and B share the TOP value (hence both necessarily have the same frequency), and have distinct compare (CC) values, and so can have different duty cycles if required - and the control register contains A_INV and B_INV bits to invert each output.