ATmega32 Berechnungszeit ermitteln

[Rush .. (rush)]

Hallo Community...

Ich wollte gerade eine simple Gegenüberstellung von einigen AVRs und 
deren Berechnungszeit für eine "einfache" Rechnung aufstellen.

Dafür habe ich einmal

ergebnis  = sqrt(465.983154/4135.964*sqrt(168*1256.942));

und einmal

ergebnis = 1.0+1.0

gerechnet.

Das ganze vorerst im Simulator. Was mich allerdings wundert: Egal was 
ich rechnen lasse, der Cyclecounter zeit immer 1 an und die StopWatch 
60ns.

Kennt zufällig jemand das Problem und kann mir weiterhelfen?
Danke schonmal im Voraus.

--
ATmega32@16Mhz
AVR-Studio 5.1

[Bastler (Gast)]

Einfaches Hilfsmittel:

Pin setzen
Funktion / Berechnung aufrufen
Pin rücksetzen

so kann man einfach die Abarbeitungszeit einer Funktion betrachen.

[Rush .. (rush)]

Das wäre doch nichts anderes als die Berechnung per Knopfdruck zu 
starten. Ich will aber die genau Zeit wissen.

[ucWriter (Gast)]

Da ich aufgrund deiner Beschreibung nichts sagen kann, bleibt nur der 
Hinweise auf das optionale (Dis-)Assembler-Listing .

Mal eine Gegenfrage. Sind denn die AVR so unterschiedlich. Es kann doch 
nur einen Unterschied geben, wenn ein AVR-Typ beispielsweise einen 
Hardware-Multiplizierer besitzt und ein anderer nicht: ATTiny vs ATmega. 
(Die ganz alten lasse jetzt mal weg)

[holger (Gast)]

>ergebnis  = sqrt(465.983154/4135.964*sqrt(168*1256.942));
>
>und einmal
>
>ergebnis = 1.0+1.0

>Das ganze vorerst im Simulator. Was mich allerdings wundert: Egal was
>ich rechnen lasse, der Cyclecounter zeit immer 1 an und die StopWatch
>60ns.

Was machst du mit ergebnis? Nichts, dann optimiert der Compiler
dir den ganzen Kram weg.

Versuch mal volatile float ergebnis.

[Thomas W. (thomas100)]

Hallo Rush,

schau dir mal den Assemblercode an, den der Compiler erzeugt.
Im besten Fall macht der Atmega nämlich nur ne Zuweisung, und der 
Compiler rechnet das vorher schon aus.

aus wird

ergebnis = 1.0+1.0

wird dann

ergebnis = 2.0

und aus

ergebnis  = sqrt(465.983154/4135.964*sqrt(168*1256.942));

wird

ergebnis  = 154.2442536

Was in der Ausführungszeit genau das gleiche ist!

Ich bin mir jetzt nur nicht sicher, ob der Compiler so intelligent ist 
und kann die Funktion sqrt () rechnen. Aber das siehst du im 
Assemblercode.

Und wenn du ergebnis nicht weiter benutzt, dann kann es dir passieren, 
dass der Compiler eh alles wegoptimiert.

VG
Thomas

[Rush .. (rush)]

Ich brauche diese Gegenüberstellung für die Vorlesung -.-
Ich weiss, eigentlich totaler Quatsch aber was solls...

Wollte das ganze auf diesen Typen laufen lassen:

AT90S2313
ATtiny2313
ATmega8 - mega128
ATmega644 und 644P

MSP430

Ich weiss nicht ob sich beispielsweise ein ATmega16 von dem 
Berechnungsalgorithmus von einem mega128 unterscheidet. Schätzungsweise 
nicht, aber muss es eben machen.

[ucWriter (Gast)]

Zu den verschiedenen Controllern gibt von TI ein PDF (inkl. Quellcode) 
im Anhang zu diesem App-Note. Hilft Dir zwar jetzt nicht...

[Rush .. (rush)]

Das hier ist praktisch der Teil für die berechnung und ausgabe:

sei();
a = sqrt(465.983154/4135.964*sqrt(168*1256.942));
cli();

dtostrf(a, 5,8, chr_a);
set_cursor(0,1);
lcd_string(chr_a);
itoa(i, chr_i, 10);
set_cursor(0,2);
lcd_string(chr_i);

// chr_a = ergebnis string
// i = Anzahl der Timerinterrupts
// chr_i = Anzahl der Timerinterrupts als String

Assembler habe ich bis heute erfolgreich meiden können, von daher 
verstehe ich ihn nicht ;-)  Thomas kannst du vielleicht drüber schauen? 
Habe den Assemblercode mal drangehängt.

[spess53 (Gast)]

Hi

Wenn in deinem Code vor sei(); ein timerinit(); steht, dann fehlt der 
Assemblercode für a = sqrt(465.983154/4135.964*sqrt(168*1256.942));

MfG Spess

[Rush .. (rush)]

der dazugehörige c-code sieht so aus:

/*
 * ATmega32_Berechnungsdauer.c
 *
 * Created: 22.03.2012 16:59:56
 *  Author: Rush
 */ 

#include <avr/io.h>
#include <avr/interrupt.h>
#include "lcd-routines.h"
#include <math.h>

extern void lcd_data(unsigned char temp1);
extern void lcd_command(unsigned char temp1);
extern void lcd_enable(void);
extern void lcd_init(void);
extern void lcd_home(void);
extern void lcd_clear(void);
extern void set_cursor(uint8_t x, uint8_t y);
extern void lcd_string(char *data);


volatile unsigned int i = 0;
volatile unsigned char chr_i[10];

volatile double d = 123.43684;
volatile unsigned char chr_d[10];



ISR(TIMER0_COMP_vect)
{
  
  i++;
  
}

void timerinit(void)
{
  //TCCR0 = (1<<WGM01) | (1<<CS00);        //prescaler none; CTC-Mode
  //TCCR0 = (1<<WGM01) | (1<<CS01);        //prescaler 8; CTC-Mode
  //TCCR0 = (1<<WGM01) | (1<<CS01) | (1<<CS00);  //prescaler 64; CTC-Mode
  //TCCR0 = (1<<WGM01) | (1<<CS02);        //prescaler 256; CTC-Mode
  TCCR0 = (1<<WGM01) | (1<<CS02) | (1<<CS00);  //prescaler 1024; CTC-Mode
  
  OCR0 = 15;                  // ((1000000/8)/1000) = 125 für 1ms
  TIMSK = (1<<OCIE0);              // enable interrupts on compare match

  //Berechnung
  // 0,001sec / ((1/16000000)*Prescaler)
}

int main(void)
{
  timerinit();
  
  double a = 0;
  char chr_a[100];
  
    sei();
    a = sqrt(465.983154/4135.964*sqrt(168*1256.942));
    cli();
    dtostrf(a, 5,8, chr_a);
    set_cursor(0,1);
    lcd_string(chr_a);
    itoa(i, chr_i, 10);
    set_cursor(0,2);
    lcd_string(chr_i);
    
    
    while(1)
    {
  
    }
}

dann frage ich mich ehrlich gesagt wo meine Berechnung hin ist.
denn im Assenblercode folgt nach dem sei() direkt das cli().

Und was hat denn mein timerinit() mit dem Berechnungsteil zu tun? 
Eigentlich doch nichts.

[Peter II (Gast)]

Rush ... schrieb:
> dann frage ich mich ehrlich gesagt wo meine Berechnung hin ist.

wegoptimiert, der compiler hat es einfach ausgerechnet.

[Rush .. (rush)]

Hast recht. Habe jetzt die Optimierung ausgeschaltet. Jetzt kommt raus:

ergebnis = 1.0 + 1.0

Cyclen: 13
StopWatch: 0,81 us

bei
ergebnis = sqrt(465.983154/4135.964*sqrt(168*1256.942))
kommen wieder die selben werte drin.

und diesmal steht die berechnung im assemblercode auch drin.

Kann doch wirklich nicht sein dass beide Berechnungen die selben Zeiten 
bringen...

[Peter II (Gast)]

Rush ... schrieb:
> Hast recht. Habe jetzt die Optimierung ausgeschaltet. Jetzt kommt raus:

jetzt hast du aber auch keine sinnvollen ergebnisse mehr. Denn kein 
sinnvolles Programm wird ohne optimierung eingesetzt.

du must also den compiler dazu bringen, mit optimierung zu rechnen.

[Rush .. (rush)]

na das ergebnis stimmt schonmal.

du hast ja recht was die optimierung angeht. mir gehts einfach nur darum 
dass ich mit ein und denselben einstellungen das selbe programm auf 
mehreren controllern laufen lasse. einfach nur um die vergleichbarkeit 
zu schaffen. sicher, normalerweise gehört dort die optimierung mit rein.
naja, mit wenn ich meine ergebnisvariable als volatile deklariere dann 
wird sie auch nicht wegoptimiert.

[Peter II (Gast)]

Rush ... schrieb:
> naja, mit wenn ich meine ergebnisvariable als volatile deklariere dann
> wird sie auch nicht wegoptimiert.
die variabel nicht, aber die berechnung kann dann genso weg optimiert 
werden. Es bleibt nur noch das ergebniss stehen.

[Rush .. (rush)]

sorry, hab mich falsch ausgedrückt. also die berechnung steht komplett 
im assemblercode drin