RE: [avr-gcc-list] Newbie question

[Weddington, Eric]

> -----Original Message-----
> From: David VanHorn [mailto:address@hidden 
> Sent: Wednesday, February 25, 2009 9:41 AM
> To: Weddington, Eric
> Cc: address@hidden
> Subject: Re: [avr-gcc-list] Newbie question
> 
> 
> Right, they are only there so I can actually scope it at the 
> hardware level.
> I've also run it in sim with studio, and it shows the same latency.

So if the simulator corroborates your scope, then take out the debug statements 
and just use the simulator.

  
> I'm less concerned with the time the ISR takes than I am with 
> the time it takes to actually get started.
> The first half is more critical, the last half is pretty much 
> a "don't care", as long as the timer value is caught quickly.
> If the latency to that point is constant, then it's not an 
> issue, and I can factor it out.

Ah, thanks for the clarification.
 
>       If we can keep the ISR from using as many other 
> registers as possible, then it will help in both the ISR 
> prologue and epilogue.
>       
>       
> 
> It irritates me to no end that C pushes registers that aren't 
> even USED... 
> (fume....)

Looking at the prologue, there's the stuff with R1 and R0, about 5 
instructions. The R24, R25, R30, and R31 registers are being used. Even though 
you may not care about the later stuff in the ISR, it affects how that prologue 
and epiloge gets generated. If you truly do not care about how long it takes 
for the later stuff in the ISR, then you may want to pull it out of the ISR all 
together and put it in the mainline code. Keep the ISR extremely short and only 
do what you have to do in it. It's a good rule of thumb for any ISR.

Another trick is to read and write the 16-bit timer using the 16-bit version of 
the register:
TCNT1 = 0;
The compiler should take care of reading and writing the value in the correct 
sequence so you get a coherent value.