execution time

[yalect]

Hi;
I would like to ask you that I want to calculate the time to execute each instruction of  simple example bellow that I wrote on miKroC for atmega32 and Device clock of 1.000000MHz, maybe some instruction takes more time than other like while or if ?
Thanks

void main() {
void init();
/* Configure the ports as output */
    DDRB = 0xff;

while(1)
 {

       PORTB =(1<< PINB1);
       Delay_ms(1000);
        PORTB&= ~(1<< PINB1);

        }

}

[ale500]

I'd say that the information you provide insufficient is because:

Version of miKroC
Optimization level

are unknowns or not given.

Second, if you compile to an assembly source (in gcc with the option -S), you can see the produced code and then you can say how many clocks the code needs based on what is written in the ATMega's Datasheet.

if you cannot compile to assembly, then use the debugger and step into the code to see what was produced. Anyways, if the LED/port should toggle with a ~1 s period, a second delay call is needed:

Code: [Select]

       PORTB =(1<< PINB1);
       Delay_ms(1000);
        PORTB&= ~(1<< PINB1);
       Delay_ms(1000);

if not, the port is going to produce a very short negative pulse followed by a > 1 s positive pulse.

[Nusa]

Hi;
I would like to ask you that I want to calculate the time to execute each instruction of  simple example bellow that I wrote on miKroC for atmega32 and Device clock of 1.000000MHz, maybe some instruction takes more time than other like while or if ?
Thanks

void main() {
void init();
/* Configure the ports as output */
    DDRB = 0xff;

while(1)
 {

       PORTB =(1<< PINB1);
       Delay_ms(1000);
        PORTB&= ~(1<< PINB1);

        }

}

What the previous poster said if you really want the exact answer. However, it's going to look something like this:

while(1){ // top of loop, no condition to evaluate so no code: 0 cycles
   PORTB =(1<< PINB1); // simple write port: 1 cycle
   Delay_ms(1000);  // call delay routine: approximately 1,000,000 cycles
   PORTB&= ~(1<< PINB1); // AND to port: 2-3 cycles, depending on how smart the compiler optimization is for changing a single bit.
} // jump to top of loop: 2 cycles

So PINB1 will be ON for ~1000003 cycles, OFF for 3 cycles, ON for ~1000003 cycles, OFF for 3 cycles, etc, giving you a 3 microsecond blip on the port every second. Which could be shorter than the rise/fall time on the output pin, depending on what you've got connected in the way of pull-up resistors and such. You'd need a scope to see it in any case.

[mikerj]

If you run the code in the Atmel Studio simulator, you can use the "Stopwatch" measure clock cycles and execution time.

[yalect]

Hi,
as I mentioned above I have device clock of 1.000000Mhz or internal oscillator for Atmega32 and miKroC compiler, how can I calculate the time of cycle (one cycle), the same thing for external oscillator crystal for example?
Thank you

[Nusa]

Hertz, or Hz is a unit that means cycles per second. 1 MHz is 1 million cycles per second. So a cycle in this case is 1 millionth of a second.

[yalect]

There is no relation with device such Atmega32 or its internal architecture? or it's depend on compiler?

[rstofer]

There is no relation with device such Atmega32 or its internal architecture? or it's depend on compiler?

Of course there is a relationship!  Each machine instruction takes a certain number of clocks to execute.  The figures are here:

https://courses.cs.washington.edu/courses/csep567/10wi/resources/ATmegaInstructionSet.pdf

Now you know exactly how long each machine instruction takes.  The next problem is to figure out how many and which machine instructions were emitted by the compiler.  You need to read the compiler user manual to figure out how to get the assembly code listing.  It is mentioned on page 2 but I didn't follow along.

http://download.mikroe.com/documents/compilers/mikroc/avr/mikroc-avr-manual-v100.pdf

Once you have the assembly code printed, you can write the clock count next to each instruction and then add them up.

[SiliconWizard]

Surely you need to inspect the assembly code, as a higher-level language can be compiled in a number of ways, but on modern, pipelined MCUs, that's still pretty hard to exactly determine the execution time from the assembly code, depending on a number of internal factors.

Quite often, first-timers of PIC32 or ARM MCUs get bitten by this when they are used to simpler MCU architectures.

You'd have to take many things in consideration, including possible wait states (for code memory access), possible internal caching, prefetch, pipeline stall, etc. If you work hard you may be able to define a minimum and maximum execution time... on a small section of code that doesn't get interrupted.

You often have to resort to internal peripherals such as timers to precisely control timings in such MCUs.

[rstofer]

The good news is that the OP is using an AVR and all it does is prefetch.  If a branch is taken, it takes one more clock than if it isn't.  Fortunately, the AVR is not a 5 stage RISC processor or something even more ugly, like a Xeon chip with many cores, gobs of cache and 'out of order execution'.