arduino timer OCR question

Projects Programming
1

This question will be for the arduino timer guru/experts here.

You know the output compare registers, like OCRA and OCRB?

I'm trying to establish accurate details about events involving these output compare registers.

For example --- if we have a 8 bit timer, which starts counting from index 0 upwards, and if OCRA were set to a value of 45, then (if everything is configured properly to set a flag upon a 'compare match' event), then does the timer start count from index 0, then index 1, then index 2, then 3, up to index 45 ..... such that the flag that signals a 'compare match' will become '1' as soon as the count reaches 45?

I assume that if the timer is configured to be 'cleared' whenever a 'compare match' occurs, then it seems (at the moment) that a 'compare match' event will occur first. The timer value will then become 'cleared' (ie. zeroed) on the following count, after the 'compare match' event, right?

So, if an interrupt service routine is configured and triggered at the instance of a 'compare match' event, then the service routine (based on this example) will execute after exactly 45 time slots (relative to the first zero index), right? Or will the service routine execute after exactly 46 time slots?

Also ----- even though it is probably not done..... nobody ever sets a value of ZERO for the OCR value right? So setting "OCRA = 0" isn't useful, right?

A bit wordy here, so I decided to include a diagram as well. I didn't include labels like OCR2A (linked to timer numbers), just to keep things simple --- so just used labels like OCRA.

One more small question..... when the timer is set up to be cleared on a 'compare match', then the timer will be cleared on the next count. Will that clearing of the timer be the same as an overflow? Will that be the equivalent of a timer overflow condition (a TOV)?

Thanks for any replies in advance!

OCR.jpg
OCR.jpg1152×648 27.1 KB

OCR.jpg
OCR.jpg1152×648 27.1 KB

2

For example --- if we have a 8 bit timer, which starts counting from index 0 upwards, and if OCRA were set to a value of 45, then (if everything is configured properly to set a flag upon a 'compare match' event), then does the timer start count from index 0, then index 1, then index 2, then 3, up to index 45 ..... such that the flag that signal a 'compare match' will become '1' as soon as the count reaches 45?

Yes, but the flag is set one tick later

I assume that if the timer is configured to be 'cleared' whenever a 'compare match' occurs, then it seems (at the moment) that a 'compare match' event will occur first. The timer value will then become 'cleared' (ie. zeroed) on the following count, after the 'compare match' event, right?

No, if correctly configured the counter will be set to 0 when the match occurs.

So, if an interrupt service routine is configured and triggered at the instance of a 'compare match' event, then the service routine (based on this example) will execute after exactly 45 time slots (relative to the first zero index), right? Or will the service routine execute after exactly 46 time slots?

After 46 time slots the routine is triggered. The execution may be a bit delayed as the interrupt controller needs some time too.
Keep in mind this only the case if you set the counter explicitly. If you use the counter to generate a clock signal, it will repeat after 45 time slots.

Also ----- even though it is probably not done..... nobody ever sets a value of ZERO for the OCR value right? So setting "OCRA = 0" isn't useful, right?

It depends on the configuration, in your configuration (as you described above) it it's mostly not useful.

One more small question..... when the timer is set up to be cleared on a 'compare match', then the timer will be cleared on the next count.

Yes and no, as already explained above.

Will that clearing of the timer be the same as an overflow? Will that be the equivalent of a timer overflow condition (a TOV)?

No, if configured to be reset on a match a overflow condition will never happen.

3

Thanks very much for your time and help pylon. For going right out of your way with answering my questions like that. That was massively helpful. I'm thinking that documents for amateurs (like myself) need to have exactly what you wrote/mentioned above. As that helps an incredible lot. Really genuinely appreciated. Thanks again for your time pylon! Those details are golden.

4

pylon:
No, if correctly configured the counter will be set to 0 when the match occurs.

Pylon ...... for an 8 bit timer, and if OCR were set to 1, ie. OCR = 1.

Then is the following true? The counter index (ie. TCNT) starts at index 0 (assuming) to begin with. And then the next tick makes the counter index become 1.

At this point, the counter index indeed 'matches' OCR, which is 1. So I assume that the 'matched' condition is at this exact moment.

Now, since TCNT is equal to 1 at this particular time, then it's not possible to alter the value of TCNT until the next tick (ie. 1 tick later).

So, 1 tick later, the compare-match flag becomes set, and the timer TCNT index becomes cleared (made zero) at the same time as the setting of the compare-match flag, right?

Is it true that the definition of 'matched' could be a source of my confusion? That is --- when the TCNT value becomes equal to the OCR value, that is indeed a 'match' ....... but from the perspective of the timer system (and definitions) ...... the 'matched' condition actually occurs 1 tick AFTER an 'actual' match, which is the time that the flag becomes set, right?

I had wrongly (intuitively) assumed that when a actual 'match' occurs (at that very instance), the flag would be immediately set ----- at that same instance of the raw match. But you helped me be showing me that the flag actually comes up (becomes set) exactly 1 tick AFTER an actual raw match ....... which really beats intuition.

5

the 'matched' condition actually occurs 1 tick AFTER an 'actual' match, which is the time that the flag becomes set?

Each timer tick is really a tick-tock with a high and low phase. With no prescaler it is a square wave. What you call one period is really a rising edge, a flat high, a falling edge, and a flat low. The tick after the 'actual' match, is also the end of the tock for the period where the match occurs.

In the data sheet there are some timer counter timing diagrams which illustrate this.

6

cattledog:
Each timer tick is really a tick-tock with a high and low phase. With no prescaler it is a square wave. What you call one period is really a rising edge, a flat high, a falling edge, and a flat low. The tick after the 'actual' match, is also the end of the tock for the period where the match occurs.

In the data sheet there are some timer counter timing diagrams which illustrate this.

Thanks very much cattledog!

What got me real good in the past was the terms/terminology of 'compare match'.

Now I realise that when an 'actual' match occurs, the flags that pop up (the response) actually occurs 1 tick after the actual match. So it's kind of like a mosquito biting ...... it takes a bite (or puts the mouthpart in), and then it is only after a while when the sensation has actually registered - a bit of a delay. So the actual bite (or actual match) occurs ....... and the signal/flag for it comes up a little while later.

So when the term 'CTC' (clear timer on a 'compare match' event) is used, I think it really means --- an actual match will eventually occur, but they (we) only 'officially' pretend that the match occurs 1 tick after the 'actual' occurrence of the match. And so the timer index actually gets cleared (or made zero) after an 'actual' match...... 1 tick after.