Frage zur Code-Optimierung

Danke Randy für den Hinweis. Im Makefile benutze ich z.Zt. die folgenden 
Einstellungen:

CC             = avr-gcc

CFLAGS        = -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) $(DEFS)
LDFLAGS       = -Wl,-Map,$(PRG).map

Ich bin mir aber nicht sicher, ob das schon das Maximum an 
Codeoptimierung ist.


Gruß
Werner

Sorry, hinter dem OPTIMIZE verbirgt sich die -Os Option. Ich werde das 
mit den verschiedenen Compiler-Optionen mal ausprobieren.

Danke.

Gruß
Werner

Schreib das ganze doch mal wie folgt, dann sparst du eine Division und 
eine Multiplikation:


#define COUNTER_INCS_PER_MILLISECOND_T1  461
#define TIME_TO_RPM_CONST                (60000L * 
COUNTER_INCS_PER_MILLISECOND_T1) // (600000 * 
COUNTER_INCS_PER_MILLISECOND_T1) / 10

ISR(INT0_vect)
{
   ...

   ulAktuelleDrehzahlG = TIME_TO_RPM_CONST / ulAktuelleUmlaufzeitG;

   ...

   unsigned int uiTableIndex = ulAktuelleDrehzahlG / 50;

   ...
}


Wenn der Wert für ulAktuelleDrehzahlG etwas ungenauer sein darf, kann 
man noch eine Division sparen und schreiben:

#define COUNTER_INCS_PER_MILLISECOND_T1  461
#define TIME_TO_RPM_CONST                (1200 * 
COUNTER_INCS_PER_MILLISECOND_T1) // (600000 * 
COUNTER_INCS_PER_MILLISECOND_T1) / ( 10 * 50)

ISR(INT0_vect)
{
   ...

   unsigned int uiTableIndex = TIME_TO_RPM_CONST / 
ulAktuelleUmlaufzeitG;

   ...

   ulAktuelleDrehzahlG = 50 * uiTableIndex;     // da zuerst die 
Division ausgeführt wird, treten hier Rundungsfehler auf!!!!!

   ...

}

Wenn Dein Compiler nicht expilizit eine Division kann, dann ist die 
Division sehr sehr sehr teuer. Darin denke ich, liegt der Grund für 
Deine langen Zeiten.

Also: Nicht durch 50 teilen, sondern die Division durch eine 
Multiplikation und anschließende  Teilung durch eine Zweierpotenz 
(shiften) ersetzen. Wieso multiplizierst Du mit 60000 und teilst dann 
durch 50 (also nur mit 1200 multiplizieren)? Macht der Compiler wirklich 
eine Division zur Laufzeit daraus (schau mal ins LST-File)?

An der Division würde ich den Optimierungshebel ansetzen.

Wie wäre es mit einer intelligenteren Optimierung?
Wenn ich das richtig sehe möchtest du die Drehzahl ermitteln, 
wahrscheinlich
per Interrupt indem du die Ticks pro Zeiteinheit zählst. Die Berechnung 
ist also NUR NÖTIG wenn du die Drehzahl wirklich abfragst. Zähle in der 
Interruptroutine nur die Ticks und dort wo du die Drehzahl brauchst(im 
Hauptprogramm) berechnest du sie. Damit dürfte die Interruptzeit von 
500us (wirklich so viel?) auf 2us fallen und du sparst dir zusätzlich 
noch eine ganze Menge unnötige Berechnungen.

Hallo zusammen,

vielen Dank für zahlreichen hervorragenden Tipps, die ich gleich heute 
Abend umsetzen werde. Bin schon wirklich gespannt, um wieviel sich die 
ursprüngliche Zeit zusammenkürzen läßt.

@I_H.:
>Warum hast du die beiden globalen Variablen denn als volatile
>deklariert?

Die beiden globalen Variablen benutze ich sowohl in Interruptroutinen 
als auch im Hauptprogramm. Gesetzt werden sie allerdings nur in der 
Interruptroutine und bei der globalen Initialisierung. Ich war mir 
ehrlich gesagt nicht ganz sicher, ob ich hierfür das "volatile" nun 
zwingend angeben muß oder nicht.

@Peter Danneger:
>Erklär dochmal, was Dich an den 500µs stört.
>Warum brauchst Du die Ergebnisse schneller als 500µs?
>
>Wie groß ist die Tabelle, die Du damit adressierst?
>Eventuell reicht ja eine Berechnung mit 8Bit aus.

Na ja, das Ganze ist eine variable Zündsteuerung für einen 
Zweitakt-Motor. Der erste Geber-Impuls (PickUp) wird 72° Grad vor OT 
ausgelöst und aktiviert den Interrupt, der die aktuelle Drehzahl 
berechnet und dann davon abhängig einen Timer-Wert (Delay) aus einer 
Tabelle ausliest. Nach Ablauf des Timers wird dann der eigentliche 
Zündimpuls ausgelöst. Bei Drehzahlen > 10.000 U/Min wird bei 500us 
Berechnungszeit für den Timer die Luft für den Einstellungsspielraum 
schon ziemlich dünn.

Die Tabelle enthält 256 Werte und ich werde Deinen Tipp beherzigen und 
auf eine 8Bit-Berechnung umstellen.

Ich denke, dass sich alle Tipps gut umsetzen lassen. Nochmals Danke an 
Alle.

Gruß
Werner

Hallo  Werner,

wieso benutzt Du nicht einfach einen 7,373 bzw 14,746 MHz Quarz?