Avr studio cycle counter wrong??

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

Hey hello everybody,

currently im working with a digital filter assignment, and everything looked real good when I simulated it in avr studio.

the filter routine only needed roughly 35uSec per call.

The whole while loop from reading adc to filter procedure to output port was merely few microseconds extra.

But when I download the code into my atmega32, it has a sample time of 140-ish microseconds. Ive removed the ADC code to elliminate the possibility of having the adc bog me down.

AVR studio reporting wrong cpu cycle counts?

Can anyone verify this? kinda lost here :?

unsigned char RLC_output(unsigned char buffer)
{
	static float rlc_Yk1;
	static float rlc_Yk2;
	static float rlc_Xk1;
	static float rlc_Xk2;
	float Out;
	
	Out = 0.1053*rlc_Xk1 + 0.1016*rlc_Xk2 + 1.692*rlc_Yk1 - 0.8989*rlc_Yk2;

        rlc_Xk2 = rlc_Xk1;
        rlc_Xk1 = buffer;
        rlc_Yk2 = rlc_Yk1;
        rlc_Yk1 = Out;


 return (unsigned char)Out;
}

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

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

Well, I think you need to go back to first principles here.

Write a simple loop, check it out using Studio and then check the count by hand. Then run it and see what happens.

I have to admit that we have never relied on the tools to time critical loops, we do the cycle count by hand on the assembler code and then optimise by hand if need be. It may not be the easiest method, but some of my contracotrs and I have been doing it this way for 30 years since the 8080 came out!

John

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

Just one thing you talk about cycle counts but then compare us timings - in my experinece the simulator gives the right cycle counts (let's face it it'd be pretty difficult for it to get that wrong!) but "timing" as shown by "Stop watch" in Studio is another thing as it's dependent on what value you have told Studio the CPU runs at. I think it defaults to 4MHz. If your real target is 1MHz then this would explain the 35us to 140us difference cos that's X4 too.

Cliff

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

Hey guys,

im using a 16mhz oscillator (vcc/gnd/output)
And ive tested that the chip runs at 16MHz by creating a saw-tooth signal like this:
while (1)
{
PORTC++;
}

That gave me 12.5 kHz, which is correct.

but when i replace the PORTC++ with
PORTC = RLC_output(ADCH);

it goes 4x slower then it should.
Yes im sure its not the ADC because its running in free running mode far faster then the execution time of the RLC_output function.

cool eh :)

want to get it sorted asap :p

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
PORTC = RLC_output(ADCH);

I'll just observe that watching PORTC here doesn't tell you how often the
function is running, but rather how often its result is changing. At first glance,
it looks as though the function, given a sequence of identical (ADCH) readings,
will produce a sequence of identical results (apx 1.9*X-0.9*X). You may want
to double-check your ADC prescaler, and moreover convince yourself that the
ADC is really (still) free-running. What do you see from "PORTC = ADCH;"?

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

Maybe also replace the ADCH parm in RLC_output(ADCH) with RLC_output(my_char_var++) to rule out the ADC thing for the time being?

Cliff

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

Hey,

I saw in your code that you are using float point calculations, I recoment you to use fixed-point calculations. they are faster... any way, that recomendation won't fix your problem...

---
ARod

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

Hey guys,

PORTC = ADCH;

results in a much higher sample rate (more tiny steps on the output per time) then it does with the RLC filter.

does anyone have an stk board laying around where he/she could drop in that routine and measue the execution time of it by either toggling a led on/off . ofcourse you'd need a scope then.

The idea that i execute the RLC function more often then the ADCH is updated is falso also, because the RLC function is a FILTER! so even a few the same input samples would give a new sample output value!

Still not solved whats causing the 4x performance bog down compared to AVR Studio....

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

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

Quote:
the filter routine only needed roughly 35uSec per call

I built this with WinAVR (-Os) and the Simulator, after the first 3 iterations,
shows cycle counts consistently above 2500 clocks (156us @ 16MHz).
I got similar results with -O3. I was calling it with (i++).

I also timed in parallel using timer0, which matched with these results.
This may not be too surprizing, but it does suggest there's nothing
odd specifically with the cycle counter.

There is some variation (~3us) between calls, indicating that parts of the
floating point support are data-dependent (also not too surprizing), and
the first 3 iterations were quicker -- but none less than about 1500 clocks
(94us @ 16MHz).

Maybe it's worth running through the Simulator exercise again?

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

hmmm

If i call the rlc routine 10 times its still 4x faster then real time measurements!

Anyone tested the code i posted earlier on an stk?

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL