AVR-Chat

As you may have seen from other posts, I am trying to write (and 
then simulate) timer functions.

Currently I have 2 timers running.  Timer 1 runs at a prescale of 1 
and trivvers an output compare avery 16,000 counts (1 millisecond).  
When this runs as the only timer process, it works fine.

I have also set up timer 0 as a slower timer.  Prescale is 1024 and 
it triggers at close to 61hz. I have set up the overflow interrupt 
for this one and it works properly when it, too,  triggers properly.

When the 2 timers are running simultaneously then I get the timer 1 
output compare triggering the timer2 overflow function (I can't tell 
if the code is jumped to, or if there was an interrupt to get there).

It may be a problem with avrstudio and stepping thru a program, or 
maybe with the avr-libc that I am using for the timer128.c routines.

Any suggestions?

-Tony

--- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> wrote:
>  
> When the 2 timers are running simultaneously then I get the timer 1 
> output compare triggering the timer2 overflow function (I can't 
tell 
> if the code is jumped to, or if there was an interrupt to get 
there).
> 
Tony,

It isn't possible for a timer1 OC to trigger a timer2 interrupt 
service routine.  When an interrupt occurs (and it's interrupt flag 
is enabled) and interrupts are also globally enabled, the AVR vectors 
to an address reserved for that interrupt.  At that address, another 
address will be found which is placed there by your compiler.  This 
is the memory address at which the compiled interrupt service routine 
has been placed.  Guessing that your code is written as standard 
interrupt service routines are, the only "normal" way to get there 
would be through an actual interrupt (not a "jump" or "goto" 
unrelated to an interrupt).

What chip are you working with (this will help with register 
identification) and does it have JTAG?  Perhaps this 
is just a simulation issue (as you suggest) and not a real world 
issue.

I am sorry if I mis-typed.  It is TC1A triggering a TC0 interrupt.

I have not tested this on the ATmega128, because I just got it 
today, and I am waiting for my ICE-cube which will arrive in a day 
or 2.

It has got to be a simulator issue.  I agree that only one interrupt 
will get triggered for an individual timer function.  It is just 
that I can clearly see the TC0 overflow interrupt get set as the 
TC1A OC interrupt is cleared.  

I tried to use TC1B, and that will not even get the TC1 counter 
counting when I enable TC1B.  If I only change to code to enable 
TC1A, then the counter runs perfectly!

I have not seen any posts about timer simulation problems in the 
newest version of AVRStudio, but there have been issues for various 
ATmega device timer simulations in the past.  I suppose these have 
yet to be resolved.

oh well.

I will get my ATmega programmed asap.  I am using the MAvric-IIb 
board.

-Tony

--- In AVR-Chat@yahoogroups.com, "airmaledfw" <airmaledfw@h...> 
wrote:
> 
> --- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> 
wrote:
> >  
> > When the 2 timers are running simultaneously then I get the 
timer 1 
> > output compare triggering the timer2 overflow function (I can't 
> tell 
> > if the code is jumped to, or if there was an interrupt to get 
> there).
> > 
> Tony,
> 
> It isn't possible for a timer1 OC to trigger a timer2 interrupt 
> service routine.  When an interrupt occurs (and it's interrupt 
flag 
> is enabled) and interrupts are also globally enabled, the AVR 
vectors 
> to an address reserved for that interrupt.  At that address, 
another 
> address will be found which is placed there by your compiler.  
This 
> is the memory address at which the compiled interrupt service 
routine 

> has been placed.  Guessing that your code is written as standard 
> interrupt service routines are, the only "normal" way to get there 
> would be through an actual interrupt (not a "jump" or "goto" 
> unrelated to an interrupt).
> 
> What chip are you working with (this will help with register 
> identification) and does it have JTAG?  Perhaps this 
> is just a simulation issue (as you suggest) and not a real world 
> issue.

I just tried to set AVR studio to emulate the AVR103  It WORKED JUST 
FINE.  Clearly there are issues with the emulation of the timer 
functions in the 128 simulation.

I am very relieved.  It was SUPPOSED to work right. Because I had 
thought long and hard about the code.  That is supposed to make 
perfect code, right?!

At least I know I am not insane.  The timer _do_ work the way they 
are supposed.  This weekend I will get the real 128 working!  I will 
get it to flash little LEDs at certain rates!

-Tony

--- In AVR-Chat@yahoogroups.com, "airmaledfw" <airmaledfw@h...> 
wrote:
> 
> --- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> 
wrote:
> >  
> > When the 2 timers are running simultaneously then I get the 
timer 1 
> > output compare triggering the timer2 overflow function (I can't 
> tell 
> > if the code is jumped to, or if there was an interrupt to get 
> there).
> > 
> Tony,
> 
> It isn't possible for a timer1 OC to trigger a timer2 interrupt 
> service routine.  When an interrupt occurs (and it's interrupt 
flag 
> is enabled) and interrupts are also globally enabled, the AVR 
vectors 
> to an address reserved for that interrupt.  At that address, 
another 
> address will be found which is placed there by your compiler.  
This 
> is the memory address at which the compiled interrupt service 
routine 

> has been placed.  Guessing that your code is written as standard 
> interrupt service routines are, the only "normal" way to get there 
> would be through an actual interrupt (not a "jump" or "goto" 
> unrelated to an interrupt).
> 
> What chip are you working with (this will help with register 
> identification) and does it have JTAG?  Perhaps this 
> is just a simulation issue (as you suggest) and not a real world 
> issue.

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> 
> I don't follow what you are saying.
> 

It doesn't really matter.  It seemed as if you thought that I expected 
interupts to cascade automatically across timers and functions.   I 
did not.

Were you getting weird timer performance in simulation or in real life?

-Tony

On Apr 20, 2005, at 6:34 PM, arhodes19044 wrote:

> It has got to be a simulator issue.  I agree that only one interrupt
> will get triggered for an individual timer function.

I don't follow what you are saying.

> It is just that I can clearly see the TC0 overflow interrupt get set
> as the TC1A OC interrupt is cleared.

Something I found earlier this week with timer 3 was that it would fire 
as expected on input capture but my output compare event would never 
trip. Not until I wrote to TCNT3 in my input capture routine, which 
happens to be where I enable the output compare.

Doesn't appear that TCNT3 ever runs until its written, and that it 
stops when an IC3 or OC3 event occurs. I'm using mode 4, CTC, OCR3B for 
compares.

Thats a heck of a note because if I wanted to let TCNT3 free run and 
generate overflow interrupts, my use of OC3 prevents it from 
overflowing. The easiest way to write TCNT3 is to zero it, then OCR3B's 
value is constant. On other architectures in the IC IRQ I write the sum 
of a timer plus an offset to a compare register to indicate when I wish 
the OC IRQ. Didn't seem to work with my 128.

Specifically have AC zero crossing detector connected to IC3, am 
driving a triac gate from the service routine, then using OC3B to tell 
me when to turn it off.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

On Thu, Apr 21, 2005 at 03:49:50AM -0000, arhodes19044 wrote:
> 
> Were you getting weird timer performance in simulation or in real life?

ICE-Cube on a Mavric-II. Also without the ICE-Cube.

I won't say its "weird", just different than expected. Can't find where
Atmel says the output compare IRQ is blocked until TCNTn is tickled but
page 11 of appnote AVR130 writes a 0 to TCNT1 in the input capture IRQ.

A wise man once taught me, "If its documented its not a bug, its a
feature." The only thing odd about this timer behavior is that I haven't
found it documented.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

One slightly unexpected (to me) aspect of the interrupt flag 
register function is that a zero menas that the flag is not set.  
When triggered by the CPU it goes to one.


Then when the interrupt is serviced it is cleared by the CPU back to 
zero.  BTW, the docs do not say precisely WHEN during the interrupt 
service routine....  Anyway,  the docs say repeatedly that the flag 
can be cleared by the user BY WRITING A 1 TO THE FLAG REGISTER.  I 
have not tried this in real life, but I would have expected that the 
SW should write a zero to the register.  But apparently writing a 1 
to the register that already has a 1 will reset the 1.....



-Tony

A man once said: "Documented bugs are features only when you want to 
make lemonade."  

I doubt he was wise, because that man was me, just now.


--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> Atmel says the output compare IRQ is blocked until TCNTn is 
tickled but
> page 11 of appnote AVR130 writes a 0 to TCNT1 in the input capture 
IRQ.
> 
> A wise man once taught me, "If its documented its not a bug, its a
> feature." The only thing odd about this timer behavior is that I 
haven't

> found it documented.
> 
> -- 
> David Kelly N4HHE, dkelly@H...

Hi David,

> Then when the interrupt is serviced it is cleared by the CPU back to
> zero.  BTW, the docs do not say precisely WHEN during the interrupt
> service routine....  Anyway,  the docs say repeatedly that the flag
> can be cleared by the user BY WRITING A 1 TO THE FLAG REGISTER.  I
> have not tried this in real life, but I would have expected that the
> SW should write a zero to the register.  But apparently writing a 1
> to the register that already has a 1 will reset the 1.....

The reason that writing a 1 to it clears it is because if you write a
1 to some other bit in the same register, you're writing a zero to all
of the other bits.

-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

On Thu, Apr 21, 2005 at 05:35:04PM -0000, arhodes19044 wrote:
> 
> A man once said: "Documented bugs are features only when you want to 
> make lemonade."  
> 
> I doubt he was wise, because that man was me, just now.
> 
> 
> --- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> > 
> > A wise man once taught me, "If its documented its not a bug, its a
> > feature."

You missed the point of wisdom. The point being that if its documented
then one does not have an excuse for being tripped by what has been
previously declared to be one of the operating conditions.

Its well documented that if one sticks a finger in an AC outlet that one
gets shocked. That is a feature, not a bug. If that feature bites then
its your own fault because its a defined property of the system.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

At 03:35 AM 22/04/2005, you wrote:
>But apparently writing a 1
>to the register that already has a 1 will reset the 1.....

Yep, quite standard procedure with other brands of micros too,
well at Least I know Motorola does the same way.

Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

On Thu, Apr 21, 2005 at 12:49:10PM -0700, Dave Hylands wrote:
> 
> Hi David,
> 
> > Then when the interrupt is serviced it is cleared by the CPU back to
> > zero.  BTW, the docs do not say precisely WHEN during the interrupt
> > service routine....  Anyway,  the docs say repeatedly that the flag
> > can be cleared by the user BY WRITING A 1 TO THE FLAG REGISTER.  I
> > have not tried this in real life, but I would have expected that the
> > SW should write a zero to the register.  But apparently writing a 1
> > to the register that already has a 1 will reset the 1.....
> 
> The reason that writing a 1 to it clears it is because if you write a
> 1 to some other bit in the same register, you're writing a zero to all
> of the other bits.

Believe it was Tony who wrote the >> quoted section above.

As for myself we're talking too much in generalities and no enough
specifics. So here is real code:

SIGNAL( SIG_INPUT_CAPTURE3 )
{
	//  Toggle edge sensitivity in preparation for next IRQ.
	//  Manual states this should be done early in this routine.
	//  Note toggling it here inverts the meaning of relay_dir.
	TCCR3B ^= (1<<ICES3);
	
	if( relay_cnt && ((TCCR3B & (1<<ICES3)) == relay_dir) ) {
		RELAY_DRIVE_P |= RELAY_DRIVE_B;	//  drive triac gate
		ETIFR  |= (1<<OCF3B);	//  clear pending, just in case
		ETIMSK |= (1<<OCIE3B);	//  enable OC3B
		TCNT3 = 0;		//  unstick timer
		relay_cnt--;
	} else {
		RELAY_DRIVE_P &= ~RELAY_DRIVE_B; //  make sure its off
		ETIMSK &= ~(1<<OCIE3B);
	}
}

SIGNAL( SIG_OUTPUT_COMPARE3B )
{
	RELAY_DRIVE_P &= ~RELAY_DRIVE_B;	//  clear triac gate
	ETIMSK &= ~(1<<OCIE3B);		//  disable myself (OC3B)
}

void
t3_init(void)
{
	RELAY_DRIVE_DDR |= RELAY_DRIVE_B;	//  enable output
	TCCR3A = 0;				//  no OC's connected
	
	//  mode 4, div by 64
	TCCR3B = (1<<WGM32) | (1<<CS31) | (1<<CS30);

	OCR3B = XTAL/64/1000;		//  1/1000th of 1 second
	ETIFR  |= (1<<ICF3);		//  clear any pending IRQ
	ETIMSK |= (1<<TICIE3);		//  enable input capture IRQ
	AC_XC_UTIL_DDR &= ~AC_XC_UTIL_B; //  make sure its an input
}

void
engage_relay(uint8_t onoff)
{
	//  relay direction must be set first, else lockout IRQ when setting
	if( onoff ) {
		relay_dir = 0;			//  rising edge ???
		ac_relay_state = 0;		//  need to verify value
	} else {
		relay_dir = (1<<ICES3);		//  falling edge ???
		ac_relay_state = 1;		//  need to verify value
	}
	relay_cnt = 3;		//  60 Hz, 3 cycles = 50 mS
}

The above isn't complete enough to compile, some external references and
defines are missing. But I think its complete enough to read. If the
"unstick timer" line is removed then SIG_OUTPUT_COMPARE3B is never
called. I don't know how to let TCNT3 free run. Its apparently stopped
in SIG_INPUT_CAPTURE3 as its contents are zero. But writing a zero
starts it counting so that SIG_OUTPUT_COMPARE3B is called when TCNT3
equals OCR3B. Notice I'm writing to a counter, not a control register.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

> From: Dave Hylands
> 
> ....
> The reason that writing a 1 to it clears it is because if you write a
> 1 to some other bit in the same register, you're writing a zero to all
> of the other bits.

?????

I assume when one writes a 1 to a register bit position one is ORing it into the
register such as:

reg |= 0x20;

and, clearing a bit ...

reg &= ~0x20;

so I don't understand your statement that "if you write a 1 to some other bit in
the same register, you're writing a zero to all of the other bits".  I assume
you're saying something like:

reg = 0x02;

to clear the 0x20 bit (bit position 5) but I wouldn't think that that would be
normal practice ...

... but, hey, I'm new here so I could be wrong :-)

Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck

Of course you are right.  The problem with that is one of 
expectations.  

Why should TC3 operate so differently from the others?  I would 
expect it to work the same!  I suppose it could be a "feature", and 
would be so if documented, I suppose.  

But, if the designers had not intended the timer to work this way, 
it is still a bug even when documented, and even when one can take 
advantage of that bug.
Aanyway, enough of this.....  

-Tony

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> On Thu, Apr 21, 2005 at 05:35:04PM -0000, arhodes19044 wrote:
> > 
> > A man once said: "Documented bugs are features only when you 
want to 
> > make lemonade."  
> > 
> > I doubt he was wise, because that man was me, just now.
> > 
> > 
> > --- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> > > 
> > > A wise man once taught me, "If its documented its not a bug, 
its a
> > > feature."
> 
> You missed the point of wisdom. The point being that if its 
documented
> then one does not have an excuse for being tripped by what has been
> previously declared to be one of the operating conditions.
> 
> Its well documented that if one sticks a finger in an AC outlet 
that one
> gets shocked. That is a feature, not a bug. If that feature bites 
then
> its your own fault because its a defined property of the system.
> 
> -- 
> David Kelly N4HHE, dkelly@H...
> 
=====================================================================
===
> Whom computers would destroy, they must first drive mad.

--- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> wrote:

> Of course you are right.

No, he isn't. To call a bug a feature just because it is documented 
is to destroy the distinction between functionality that is useful to 
the user and functionality that is detrimental.

For example, the defect in Microsoft Word whereby the "space before" 
of a paragraph is not supressed at the top of a page after a manual 
page break must be approaching its tenth birthday. It has been 
documented for a long time. But, nobody wants Word to work that way.  
Calling it a feature is just playing with words. It is a defect, or, 
if you have to use the word, a bug. You could usefully call it 
a "known bug" to distinguish it from defects introduced recently that 
are not yet accepted as just another mine in the minefield.

There are also "bad design decisions". Maybe that's what we have 
here. One could wish for things to be otherwise, but, pragmatically, 
having the thing documented is the best you can hope for.

Graham.