ATtiny25 OCR1A = OCR1C, which occurs first, CTC or interrupt?

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using an ATtiny25 timer0 to produce a fast PWM and timer1 to change the PWM OCR0A value at a variable frequency. CTC only uses OCR1C register and interrupts can be on OCR1A and OCR1B. I need OCR1A interrupt to change the OCR0A value and OCR1C to clear timer1. If OCR1A=OCR1C will the interrupt occur before the timer is cleared by CTC? This may be more of a GCC question as it is written in C. TCNT1 could be zeroed in the interrupt but CTC is available. Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If OCR1A=OCR1C will the interrupt occur before the timer is cleared by CTC?

No. The clearing of the timer happens immediately (along with the setting of the interrupt flag). The ISR will be entered at least a few clocks later. 

This may be more of a GCC question as it is written in C.

Nope. This is totally controlled by hardware (with the exception that software could clear the global interrupt flag). 

Regards,
Steve A.

The Board helps those that help themselves.

Last Edited: Mon. May 11, 2015 - 04:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No. The clearing of the timer happens immediately (along with the setting of the interrupt flag). The ISR will be entered at least a few clocks later. 

Isn't this a bit tricky to discuss in words?

 

Unfortunately, the datasheet doesn't seem to have an "expanded" timing diagram as is common in e.g. SPI operations.

 

However, consider this:  An AVR8 timer clocked at /1.  OCR register set to 2.  The TCNT value will go 0, 1, 2, 0, 1, 2, 0, ... on successive system clock ticks.

 

So for one clock, TCNT will indeed be the "TOP" value in the OCR register. [Right?]

 

Now, whether the IF flag gets set as soon as TNCT is 2, or in the middle of that cycle, or at the end of that cycle, or when the TCNT changes to 0, or even a bit later--I have no idea.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

However, consider this:  An AVR8 timer clocked at /1.

...

Now, whether the IF flag gets set as soon as TNCT is 2, or in the middle of that cycle, or at the end of that cycle, or when the TCNT changes to 0, or even a bit later--I have no idea.

That is irrelevant in that circumstance since the OP is concerned about when the ISR happens, not when the flag is set. Where the confusion comes is when the prescaler is set to a higher value. If the flag is set on the first system clock that triggered the timer to change to the value, then there could be as many as 16384 system clocks occurring before the timer is reset to 0. So the question is, when does the compare flag get set relative to the timer clock, not when it is set relative to the system clock. On other timers it explicitly says that the flag is set on the next timer clock. e.g. from the mega168 and family:

This flag is set in the timer clock cycle after the counter (TCNT1) value matches the Output
Compare Register A (OCR1A).

The tiny25 datasheet has no such clear cut statement.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you really want to understand how the timers and interrupts interact on the AVRs, this is a very interesting read and will definitely teach you a few tricks as well:

 

http://wp.josh.com/2015/03/12/avr-timer-based-one-shot-explained/

Cheers,

Tom

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you really want to understand how the timers and interrupts interact on the AVRs, this is a very interesting read and will definitely teach you a few tricks as well:

Thanks much for the link.  "One shot" has repeatedly come up here over the years, and the author is using a methods without races. Hmm--as TCNT is being tweaked it would throw off use of the free-running timer for e.g. 10ms-tick purposes.  In many apps, it might still be "close enough" especially for short pulses. 

 

At least in the linked page (and from there link back to the previous discussion with the sample code) I see nothing about interrupt timing as is discussed above.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Personally,   I would just put the code in the Simulator.    And see for myself !!!

 

There is no point in speculating on things like this.     The current Simulator might be 'slow' but it does mimic the hardware behaviour true to the cycle.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

ATtiny25 OCR1A = OCR1C, which occurs first, CTC or interrupt?

If this is the question CTC will occur first, for any ATTINY and even ATMEGA.

 

Can any of you guys explain me the topic and its question?

Almost every line of this post make me feel nervous.

 

magno_grail wrote:

Using an ATtiny25 timer0 to produce a fast PWM and timer1 to change the PWM OCR0A value at a variable frequency.

OK, possibly better to use TMR1 for PWM generation and TMR0 for period

 

magno_grail wrote:

CTC only uses OCR1C register and interrupts can be on OCR1A and OCR1B.

I think in CTC mode overflow interrupt will trigger on OCR1C match, so no need in additional register if you only need period and no phase shift. If overflow interrupt for some reason is not available for this particular chip, you can switch to PWM-mode (without using PWM outputs) to get desired overflow.

 

magno_grail wrote:

If OCR1A=OCR1C will the interrupt occur before the timer is cleared by CTC?

No, interrupt will occur 4..5 system clocks after. Timer is cleared by hardware. Why should you care about what will happen first?

 

magno_grail wrote:

This may be more of a GCC question as it is written in C. TCNT1 could be zeroed in the interrupt but CTC is available.

No comments.

OK, here it is: interrupt will occur 4..5 system clocks after (I mean ISR code will be reached), irrelevant of C or Assembler or even Basic.

 

P.S. Are you aware about double-buffering of PWM registers?

Last Edited: Sat. May 16, 2015 - 01:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mccrtay wrote:
OK, possibly better to use TMR1 for PWM generation and TMR0 for period
Inasmuch as TIMER1 uses the fast peripheral clock and can generate PWM frequencies as high as 250 kHz, I agree.  However the greater number of prescaler options available to TIMER1 allows finer control over its frequency.  Which you choose will depend on the needs of your app.

 

Quote:
I think in CTC mode overflow interrupt will trigger on OCR1C match,
Only if you're using TIMER1 for PWM:

 

 

 

 

Quote:
P.S. Are you aware about double-buffering of PWM registers?
Again, only in PWM modes.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

 

mccrtay wrote:

I think in CTC mode overflow interrupt will trigger on OCR1C match,

Have you read my line to the end? :)

 

joeymorin wrote:

Again, only in PWM modes.

I meant if one can't set period on TMR1, he may be missing that write to TCCR0A will have no effect for some time

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mccrtay wrote:
Have you read my line to the end? :)
Yes, which is why I including the relevant passage from the datasheet, instead of saying 'I think' :)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

Yes, which is why I including the relevant passage from the datasheet, instead of saying 'I think' :)

 

Thanks for direct pointing.

 

Offtopic, but can you give any reasonable explanation why this CTC mode only is missing overflow interrupt? I guess here is no feature (:

Overflow IMHO means that given period is expired and TCNT is back to 0...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mccrtay wrote:
Offtopic, but can you give any reasonable explanation why this CTC mode only is missing overflow interrupt?
That's a question for Atmel.

 

In general, 'overflow' means exactly that.  It refers to the moment that a timer naturally rolls over from it's possible maximum value, not from the maximum value for which it is configured.

 

There is a point to be made either way.  In support of this, there are modes to support each argument.  In the t85, overflow means the former for non-pwm modes, and means the latter for pwm modes.

 

The t85 isn't unique in this regard.  The m48 family, for example, has these modes available for TIMER1:

 

Note that modes 4 and 12 will set TOV1 only on a true overflow, while modes 5, 6, 7, 14, and 15 will set it after the timer reaches it's configured TOP value. 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An explanation of the project, I am using a PWM controlled regulated current supply to drive a single group of LEDs of a tail light. Dim for parking and bright for brake to replace an 1157 bulb. Since there are only three wires: park, brake and ground, the ATtiny25 starts up assuming brake light and in the while(1) loop changes to park or brake depending upon the input. The circuit was already designed and the board made assuming the PB0 (OC0A) pin was driving the regulator. The user can program the brightness of the park and brake lights using an accessory board (switch and potentiometer) as well as program in a flash (1 - 4 times) and flash rate before the brake stays steady. State law allows up to 4 flashes in four seconds due to some automaker wanting a fancier brake light. A jumper on the board controls whether the flash function is enabled.

The question was because if the timer clear on compare match occurs before the interrupt and clears the timer before the interrupt flag is set, why would there be an interrupt as the timer was zeroed before the compare actually took place? The compare match and CTC are using different registers (OC1A and OC1C). If written in assembly I presume the code could be written so that does not happen. It may also depend upon whether the timer is running in synchronous mode or not. Page 86: "A compare match will set the compare interrupt flag OCF1A after a synchronization delay following the compare event". As I mentioned, the whole question could be made moot by zeroing the timer in the compare interrupt but the clear timer function already exists, so why not use it? The problem is the CTC does not generate an interrupt in order to change the PWM and the interrupt does not automatically clear the timer.

Yes, I know that OCR0A will not be updated until TOP, this is a problem with timer1. The t25/45/85 does not have all the modes of the m48 family.

About 90% of the code is to allow the user to program the four parameters. It uses timer0 for PWM, timer1 for CTC to change the PWM value for the flashing, A-D to measure the user input and EEPROM to retrieve/store the parameters. If it may be useful I can put the code in the project section as an example. People can rip up my programming style there.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I see the confusion.  We thought you were asking about when the interrupt would be serviced.

 

In CTC mode, so long as OCR1A is less than or equal to OCR1C, then OCF1A will be set the moment that TCNT1 counts to OCR1A.  Even when OCR1A is equal to OCR1C, the flag is still set.

 

I must admin, I'm not sure why it wasn't clear to you from a reading of the datasheet:

 

 

 

 

If you doubt the datasheet, construct a program to test the behaviour yourself.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because the OCF1A flag is not set until the synchronization 3 clock cycles after the match or 2 clock cycles after the timer was cleared. The pending OCF1A flag is stored somewhere until the synchronization is done and a clear timer will not beat it?

For Timer0 it states: "Modifying the counter (TCNT0) while the counter is running, introduces a risk of missing a Compare Match between TCNT0 and the OCR0x Registers." It does not say if the modification is only by software or also includes hardware. Timer1 has no similar statement. An omission or does not happen?

I do doubt the data sheets as they tend to have typographical errors that only sometimes get fixed. Sure everything the data sheet could be tested by a program and run through the simulator but that would take a lot of time since I can only do one simulation before Studio 6.2 has to be shut down and restarted. For some reason in my installation Stop does not mean stop simulating. When exiting Studio it asks if I want to stop simulating. I noticed that atbackend.exe does not close. Reinstalling Studio does not fix the problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

magno_grail wrote:
Because the OCF1A flag is not set until the synchronization 3 clock cycles after the match or 2 clock cycles after the timer was cleared. The pending OCF1A flag is stored somewhere until the synchronization is done and a clear timer will not beat it?
Again, a question for Atmel.  I doubt they will divulge the design particulars of their silicon.

 

Quote:
For Timer0 it states: "Modifying the counter (TCNT0) while the counter is running, introduces a risk of missing a Compare Match between TCNT0 and the OCR0x Registers." It does not say if the modification is only by software or also includes hardware. Timer1 has no similar statement. An omission or does not happen?
'Modify' does not equal 'count'.  The words you are looking for are 'compare match blocking'.  That only happens when TCNTn changes by virtue of a write, not from normal counting.  All(?) AVR timers have a similar feature, and a perusal of other tiny/mega datasheets will show this.

Quote:
I do doubt the data sheets as they tend to have typographical errors that only sometimes get fixed. Sure everything the data sheet could be tested by a program and run through the simulator but that would take a lot of time since I can only do one simulation before Studio 6.2 has to be shut down and restarted. For some reason in my installation Stop does not mean stop simulating. When exiting Studio it asks if I want to stop simulating. I noticed that atbackend.exe does not close. Reinstalling Studio does not fix the problem.
Why on earth would you rely on the simulator for this kind of test?  Such a test will only tell you how the simulator behaves.  Do the test on real hardware.  That's the only place you care about.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. May 17, 2015 - 05:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Let me guess what you want (because I still do not understand).

 

You need to count 1 to 4 flashes in ISR with different duration. For that you start TMR1 in CTC-mode with a given period in OCR1C (and some unexplained value in OCR1A to get to ISR) and when an interrupt triggers you change current TCNT1 value in order to get proper period on next cycle.

 

If so then:

 

1. Do not change TCNT, change period

2. Use PWM mode instead of CTC, because PWM has double-buffering and all that sync problem disappears.

 

Or try to explain your problem again.