AVR-Chat

Someone (John Samperi?) asked how long I had waited to see if interrupts 
were happening.  The answer is a very long time. I even went so far as 
to set the program to running, and going off to do other things for 
almost an hour.  I returned to find the program still cycling rapidly 
between rjmp MAIN and sleep, and nothing having happened in any of the 
interrupt routines (I am certain because I had the interrupt routines 
set up to set a flag in a register, and none of the flags were set).

I am totally frustrated and discouraged at this point.   I realize that 
it is something *I* am doing wrong, but for the life of me, I am damned 
if I can determine what or where.  As I said earlier, I set up a very 
simple interrupt ina standalone program, and it worked fine.  the 
details of this one differ, of course, but the form is the same, and it 
does not work, at least net in simulation.

I am planning to obtain some physical processors in about 2 weeks,and 
will be able to check things on a real processor, though I am not very 
hopeful that the problem, will disappear, frankly.

tom

For a timer int:

Global ints must be on.
The specific int must be enabled.
The timer must be in a mode that will actually cause the condition to occur.
The prescaler must be set up to give the timer a clock source that is
running.

That's about it..

Make sure your vector table is correct for the processor, and make sure that
you're using Jmp or rjmp in the table, as appropriate to the processor.


I can certainly solve it for you, but that is what I do for a living.


[Non-text portions of this message have been removed]

It is sometimes sensible to go back to basics.
Start with a simple program that simply toggles a pin on interupt.

If that is not happening then check global interupts are enabled.
Your timer interupt must be enabled too.

Make sure that you reenable the timer int after the interupt so it happens more than once.

http://www.ckp-railways.talktalk.net/pcbcad28.htm




Thomas Keller <tjkeller1@alltel.net> wrote:                                  
 
 Someone (John Samperi?) asked how long I had waited to see if interrupts 
 were happening.  The answer is a very long time. I even went so far as 
 to set the program to running, and going off to do other things for 
 almost an hour.  I returned to find the program still cycling rapidly 
 between rjmp MAIN and sleep, and nothing having happened in any of the 
 interrupt routines (I am certain because I had the interrupt routines 
 set up to set a flag in a register, and none of the flags were set).
 
 I am totally frustrated and discouraged at this point.   I realize that 
 it is something *I* am doing wrong, but for the life of me, I am damned 
 if I can determine what or where.  As I said earlier, I set up a very 
 simple interrupt ina standalone program, and it worked fine.  the 
 details of this one differ, of course, but the form is the same, and it 
 does not work, at least net in simulation.
 
 I am planning to obtain some physical processors in about 2 weeks,and 
 will be able to check things on a real processor, though I am not very 
 hopeful that the problem, will disappear, frankly.
 
 tom
 
 
     
                       

 		
---------------------------------
 New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.

[Non-text portions of this message have been removed]

On 1/17/07, np np <harrabylad@yahoo.co.uk> wrote:
>
> It is sometimes sensible to go back to basics.
> Start with a simple program that simply toggles a pin on interupt.
>
> If that is not happening then check global interupts are enabled.
> Your timer interupt must be enabled too.
>
> Make sure that you reenable the timer int after the interupt so it happens
> more than once.


In the avr, the int is enabled on exit from the isr via RETI.


[Non-text portions of this message have been removed]

Thomas Keller wrote:
> 
> Someone (John Samperi?) asked how long I had waited to see if interrupts 
> were happening.  The answer is a very long time. I even went so far as 
> to set the program to running, and going off to do other things for 
> almost an hour.  I returned to find the program still cycling rapidly 
> between rjmp MAIN and sleep, and nothing having happened in any of the 
> interrupt routines (I am certain because I had the interrupt routines 
> set up to set a flag in a register, and none of the flags were set).
> 
> I am totally frustrated and discouraged at this point.   I realize that 
> it is something *I* am doing wrong, but for the life of me, I am damned 
> if I can determine what or where.  As I said earlier, I set up a very 
> simple interrupt ina standalone program, and it worked fine.  the 
> details of this one differ, of course, but the form is the same, and it 
> does not work, at least net in simulation.
> 
> I am planning to obtain some physical processors in about 2 weeks,and 
> will be able to check things on a real processor, though I am not very 
> hopeful that the problem, will disappear, frankly.
> 
> tom

Tom,

I don't have time right now to go thru your code, but what I recall
seeing you posted a few days ago I noticed you initialized timer 0 but
later in program referenced timer 1.  Are you using both timers?

Don

Don:

   Yes, I am using both timwrs.  one is as a tomer, the other as  PWM.

tom

Don AE5K wrote:

>
>
> Tom,
>
> I don't have time right now to go thru your code, but what I recall
> seeing you posted a few days ago I noticed you initialized timer 0 but
> later in program referenced timer 1. Are you using both timers?
>

Hi Tom - Not all the guys in the group will agree, but i'm still
old-school. I like doing my debugging with a "real" chip and "real"
led. But basically don't lose hope ! EVERY time that something in the
AVR have not done what they were supposed to, it was my software that
was at fault.

As many other have suggested: Make sure global interrupts are enbaled,
make sure the timer interrupt in TIMSK is enabled, make sure the timer
is set to run (usually in TCCR1B etc), make sure an interrupt can
happen (ie. if you using an overflow interrupt, make sure the timer is
not configured for CTC with a value less than the overflow value etc.)
The only other thing I can recommend is actually programming a chip
and getting a scope and some leds out to debug what is happening.

Cheers
Hein
Auckland, New Zealand


--- In AVR-Chat@yahoogroups.com, Thomas Keller <tjkeller1@...> wrote:

>
> Don:
> 
>    Yes, I am using both timwrs.  one is as a tomer, the other as  PWM.
> 
> tom
> 
> Don AE5K wrote:
> >
> >
> > Tom,
> >
> > I don't have time right now to go thru your code, but what I recall
> > seeing you posted a few days ago I noticed you initialized timer 0 but
> > later in program referenced timer 1. Are you using both timers?
> >
>

I agree that using a real chip is better.  Using one with JTAG is even
better because you can fiddle with the bits real-time and see what works.
The AvrDragon is a killer product IMHO.

That said, I developed my original RTOS (www.barello.net/Avrx) completely in
the simulator.  I learned some pretty hard lessons about race conditions
(set break point, hit it 75 times, then single step until I found the
race...) and peripheral set up.  I am very careful reading and parsing the
data sheets now...

So, there is no fundamental reason why the simulator won't do what Mr.
Keller needs done.

Cheers!

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of kernels_nz
Sent: Wednesday, January 17, 2007 5:07 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Re: hrm...

Hi Tom - Not all the guys in the group will agree, but i'm still
old-school. I like doing my debugging with a "real" chip and "real"
led. But basically don't lose hope ! EVERY time that something in the
AVR have not done what they were supposed to, it was my software that
was at fault.

As many other have suggested: Make sure global interrupts are enbaled,
make sure the timer interrupt in TIMSK is enabled, make sure the timer
is set to run (usually in TCCR1B etc), make sure an interrupt can
happen (ie. if you using an overflow interrupt, make sure the timer is
not configured for CTC with a value less than the overflow value etc.)
The only other thing I can recommend is actually programming a chip
and getting a scope and some leds out to debug what is happening.

Cheers
Hein
Auckland, New Zealand


--- In AVR-Chat@yahoogroups.com, Thomas Keller <tjkeller1@...> wrote:
>
> Don:
> 
>    Yes, I am using both timwrs.  one is as a tomer, the other as  PWM.
> 
> tom
> 
> Don AE5K wrote:
> >
> >
> > Tom,
> >
> > I don't have time right now to go thru your code, but what I recall
> > seeing you posted a few days ago I noticed you initialized timer 0 but
> > later in program referenced timer 1. Are you using both timers?
> >
>




 
Yahoo! Groups Links

>
> So, there is no fundamental reason why the simulator won't do what Mr.
> Keller needs done.


None at all..

My first app in the AVR, delivered six weeks after I first saw the 8515's
data sheet, was developed for four weeks in sim only while I waited for
delivery of the first 8515 silicon which I still have, date code "ES"
(Engineering Sample).  It was heavily dependent on interrupts.
There was no difference between simulation and the real chip.


[Non-text portions of this message have been removed]

Agreed, and that's one of the nice things about AVRs over those other 
guys...as well as simplicity of developing the hardware, which isn't 
always so easy to get started with over on the dark side.

Perhaps Tom needs to set his timers to 1, any other associated variables 
to 1, and step it through from there.  As John Samperi stated earlier, a 
delay of a few mSec in hardware at 4 MHz may take a couple of hours in 
the simulator.  I use a separate include file with variables listed.  
When I'm playing with variables I comment out the desired variable 
number and enter a lower value.  That way I know what I've been 
operating on with the fiddle method.

Get it working first, then set your timers where they need to be for the 
application.

Where the heck is Kat?  Is she hiding out again?


REB




Micro Brix wrote:

>>So, there is no fundamental reason why the simulator won't do what Mr.
>>Keller needs done.
>>    
>>
>
>
>None at all..
>
>My first app in the AVR, delivered six weeks after I first saw the 8515's
>data sheet, was developed for four weeks in sim only while I waited for
>delivery of the first 8515 silicon which I still have, date code "ES"
>(Engineering Sample).  It was heavily dependent on interrupts.
>There was no difference between simulation and the real chip.
>


[Non-text portions of this message have been removed]

On 1/18/07, Roy E. Burrage <RBurrage@bellsouth.net> wrote:

> Agreed, and that's one of the nice things about AVRs over those other
> guys...as well as simplicity of developing the hardware, which isn't
> always so easy to get started with over on the dark side.
>
> Perhaps Tom needs to set his timers to 1, any other associated variables
> to 1, and step it through from there.  As John Samperi stated earlier, a
> delay of a few mSec in hardware at 4 MHz may take a couple of hours in
> the simulator.


It's not THAT bad :)   I've simmed a few seconds in reasonable timeframes.
I suspect there's some simple basic problem here.
I would urge the OP to take this as fact:  The sim works, and the chip
works.

Try not to develop too much at one time without testing.




>   I use a separate include file with variables listed.
> When I'm playing with variables I comment out the desired variable
> number and enter a lower value.  That way I know what I've been
> operating on with the fiddle method.
>
> Get it working first, then set your timers where they need to be for the
> application.
>
> Where the heck is Kat?  Is she hiding out again?


She got a new job recently, probably shoveling pretty hard.


[Non-text portions of this message have been removed]

Roy E. Burrage wrote:
> Agreed, and that's one of the nice things about AVRs over those other 
> guys...as well as simplicity of developing the hardware, which isn't 
> always so easy to get started with over on the dark side.
> 
> Perhaps Tom needs to set his timers to 1, any other associated variables 
> to 1, and step it through from there.  As John Samperi stated earlier, a 
> delay of a few mSec in hardware at 4 MHz may take a couple of hours in 
> the simulator.  I use a separate include file with variables listed.  
> When I'm playing with variables I comment out the desired variable 
> number and enter a lower value.  That way I know what I've been 
> operating on with the fiddle method.
> 
> Get it working first, then set your timers where they need to be for the 
> application.
> 
> Where the heck is Kat?  Is she hiding out again?
> 
> 
> REB

I am lurking ;)

I have a full time job now (doing low voltage cabling (Fire / EWIS / PA 
/ Nurse call etc) ) so I am up at 5am to be on-site at 7am :)
-- 
Regards,

Kat.
---------------------------------------------------------------
  K.A.Q. Electronics     Website: www.kaqelectronics.dyndns.org
  IM: Yahoo: PinkyDwaggy MSN: katinka@kaqelectronics.dyndns.org
  For Everything Electronics 		   Phone: 0419 923 731
---------------------------------------------------------------

REB:
> Perhaps Tom needs to set his timers to 1, any other associated variables
> to 1, and step it through from there.  As John Samperi stated earlier, a
> delay of a few mSec in hardware at 4 MHz may take a couple of hours in
> the simulator.
As I said after Tom sent his code last time, it works.  Tom - have you
correctly used the 'Run to Cursor' function with your cursor placed at the
second 'rjmp TIMER0' in your interrupt-vector table yet?  If that doesn't
work, it's either a bug in the version of AVR Studio you're using, or
you've set up the simulation options in AVR Studio incorrectly.


Richard
-- 
Na vratima raja, ja savijam krila...
http://www.van-gogh.co.yu

eeeewwww!  A real job?  That's disgusting!


REB



Kathy Quinlan wrote:

>Roy E. Burrage wrote:
>  
>
>>Agreed, and that's one of the nice things about AVRs over those other 
>>guys...as well as simplicity of developing the hardware, which isn't 
>>always so easy to get started with over on the dark side.
>>
>>Perhaps Tom needs to set his timers to 1, any other associated variables 
>>to 1, and step it through from there.  As John Samperi stated earlier, a 
>>delay of a few mSec in hardware at 4 MHz may take a couple of hours in 
>>the simulator.  I use a separate include file with variables listed.  
>>When I'm playing with variables I comment out the desired variable 
>>number and enter a lower value.  That way I know what I've been 
>>operating on with the fiddle method.
>>
>>Get it working first, then set your timers where they need to be for the 
>>application.
>>
>>Where the heck is Kat?  Is she hiding out again?
>>
>>
>>REB
>>    
>>
>
>I am lurking ;)
>
>I have a full time job now (doing low voltage cabling (Fire / EWIS / PA 
>/ Nurse call etc) ) so I am up at 5am to be on-site at 7am :)
>  
>


[Non-text portions of this message have been removed]

At 06:46 PM 18/01/2007, you wrote:
>I have a full time job now (doing low voltage cabling (Fire / EWIS / PA
>/ Nurse call etc) ) so I am up at 5am to be on-site at 7am :)

  ahhh the good old Emergency Warning and Intercommunication System,
spend 12 year of my life developing the FFE (RIP) brand EWIS, many
of my ideas went into the Australian Standard but no money or glory
for me :-D

Regards

John Samperi

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

Okay, for  information, I'm running AVR Studio V4.12 build 490 here.  My
PC is an Athlon running at 1.4GHz.  Apart from sorting out comments that
had moved to the next line (otherwise it wouldn't assemble), I've just run
it 'as-is' and taken some screen-grabs through the simulation.  They're
mostly large (1280x1024) and live here:
http://www-users.aston.ac.uk/~reevesrp/keller/
The running delay between me clicking 'Run to Cursor' and the interrupt
occuring was a fraction of a second in all cases.


Richard
-- 
Na vratima raja, ja savijam krila...
http://www.van-gogh.co.yu

"Try not to develop too much at one time without testing."

That's probably some of the best advice anyone could ever give.  There's 
a reason we do programs in blocks, brix, and modules.

As for Kat - I can only repeat...a real job, eeeewwww!


REB



Micro Brix wrote:

>On 1/18/07, Roy E. Burrage <RBurrage@bellsouth.net> wrote:
>  
>