Optimierung des neuen AVR Studios schlechter

[Manuel (Gast)]

Hallo!

ich habe ein Projekt von Dezember 2010 auf einer Festplatte, das 
komische daran ist, spiele ich die darin enthaltene, damals kompilierte 
.hex ein, funktioniert alles.

Versuche ich aber nun vorher zu kompilieren, dann habe ich 112% des µC 
belegt.

Die Frage ist also wie das sein kann ? Es ist die höchste Optimierung 
eingestellt und alle Dateien befinden sich im Projektordner, damals 
wurde auch AVR Studio verwendet, und es kamen 97% ca. heraus.

Hat dafür jemand eine Erklärung?

Danke

mfG
Manuel

[Michael U. (amiga)]

Hallo,

AVR-Studio optimiert nichts.
Das hat nur einen (eigentlich 2) Assembler und die übersetzen genau das, 
was im Source steht.

Womit compilierst Du also? GCC (WinAVR)? Gleiche Version wie damals?
WinAVR ist nicht Bestandteil des AVR-Studio.

Gruß aus Berlin
Michael

[Manuel (Gast)]

Hallo!

Danke für die Berichtigung.

Ja ich verwende AVR-GCC.
Ich kann es leider nicht sagen, ob ich die selbe Version habe. deshalb 
habe ich hier nachfragen wollen woran dies liegen kann. Es ist hald auch 
ein Problem, da ich das Programm weiter schreiben muss, aber wenn es nun 
so schon nichtmehr in den µC geht, dann brauche ich garnicht erst 
anzufangen.

MfG
Manuel

[holger (Gast)]

>Es ist hald auch
>ein Problem, da ich das Programm weiter schreiben muss, aber wenn es nun
>so schon nichtmehr in den µC geht, dann brauche ich garnicht erst
>anzufangen.

Selbst wenn du auf 97% kommst, was willst du da noch groß
weiterschreiben? Nimm einen größeren AVR.

[Karl H. (kbuchegg)]

Nicht gleich schwarz sehen.
Es kann natürlich schon sein, dass der Optimizer einige Stellen 
schlechter übersetzt. Das hängt zum Teil aber auch vom C-Programm selber 
ab.
Was ich tun würde
* in Betracht ziehen, eine ältere Compilerversion zu probieren.
  Aber nicht, wie du jetzt denkst um damit weiterzumachen, sondern
  um zu vergleichen.
  Von beiden Compilerversionen eine Map anfertigen lassen und dort die
  Teile heraussuchen, die sich signifikant in der Größe unterscheiden.
  Diese C-Funktion dann etwas genauer ansehen. Assembler Output in
  beiden Versionen vergleichen um zu sehen, was da genau größer
  geworden ist und das dann im C Code wiederfinden.

* Alle Funktionen kritisch durchleuchten. Insbesondere auf zu große
  Datentypen. 16 Bit Arithmetik ist nun mal aufwändiger als 8 Bit.
  Wenn ich nur 8 Bit brauche, da aber 16 Bit Arithmetik drinnen habe,
  dann hab ich Platz verschwendet.
  Selbiges für 32 Bit Arithmetik.

* inline Funktionen
  können zwar für Speed sorgen aber auch dazu, dass (durch das inlinen)
  der Code insgesamt größer wird

* den Code durchsehen nach Dingen, die man vereinfachen kann.
  Meistens findet sich noch so einiges.

* es gibt sicherlich noch mehrere Dinge die man machen kann, die mir
  jetzt aber auf die Schnelle nicht einfallen :-)

[Valentin B. (nitnelav)]

Hast du überhaupt unter Projekt die Optimierung angeschaltet?
Das hat bei mir dann auch erstmal für Erstaunen gesorgt...

Mit freundlichen Grüßen,
Valentin Buck

[Manuel (Gast)]

Hallo!

Ok das Problem ist gelöst, mit der neusten Version geht es wieder. Gibts 
noch nicht so lange, dass ich sie hier drauf habe.

:) Danke euch!

Eine kleine Frage hätte ich bei der Gelegenheit noch.
Ich verwende Peter Daneggers 124Bus.

Undzwar, brauche ich dazu nur COM0A0 und COM0A1 um den PIN bein überlauf 
zu setzen. Wenn ich jetzt allerdings alles von COM0A0 auf COM0B0 ändere, 
und das selbe mit COM0A1 auf COM0B1, und die definition meines "DATA" 
auf PB1 statt PB0 einstelle, sollte doch alles passen oder?

Interessanterweise tut es dass nicht ( Ich verwende einen Attiny13 )

Gibt es einen besonderen Grund beim Attiny13, dass ich hierbei nur den 
OC0A verwenden kann und nicht den OC0B ?

Danke
Lg
Manuel