Problem mit While Schleife und Codegröße Mega8

Gast #942630
Hallo an alle,

ich habe ein Problem welches ich weder verstehen noch lösen kann. Ich 
habe schon viel im Forum gesucht aber leider keine Lösung gefunden.

Ich habe folgende Funktion:
1
char * test_func(char * buf, int val )
2
{
3
  while(val > 2)
4
  {
5
    val = val - 2;
6
  }
7
  return buf;
8
}

Das Programm mit dieser Funktion benötigt Flash speicher: 3172 Bytes.

wenn ich in der while Bedingung (val = 2) schreibe braucht das Programm 
nur 150 Bytes.

Ob ich val als volatile deklariere bringt keinen Unterschied!?

Achso, der Code wird für einen Mega8 Compiliert.

Ich hoffe auf Hilfe und bedanke mich im Voraus.
Gast #942751
... und da die Schleife dann nie verlassen wird, lässt der Compiler
auch gleich den Code, der nach dem Aufruf von test_func kommt, weg. Du
rufst dort sicher fette Bibliotheksfunktionen auf, die jetzt nicht
mehr benötigt werden.

PS: Warum überkommt mich nur dieses bange Gefühl, dass eine dieser
aufgerufenen Funktionen _delay_ms oder _delay_us heißt?  ;-)
Sollte ich Recht haben, musst du noch die Optimierungsstufe des
Compilers hochsetzen.
#942775
Ist mir auch schon aufgefallen mit _delay_ms oder _delay_us..
Falls die eingebunden werden ist der Code viel grösser. Warum 
eigentlich?
Ist ja nicht viel Code für diese Funktionalität.

Einer ne Ahnung?

Cheers,
Felix
#943012
@ Felix Bonjour (e-b)

>Jetzt ist alles klar.

Nicht wirklich.

> Wenn FP ins Spiel kommt wird's halt gross auf den Megas.

Ja, aber die delay Funktionen sind nur sinnvoll, wenn sie mit

- Konstanten und
- aktivierter Optimierung

genutzt werden. Und dann braucht es auch keine Floatingpoint Mathematik. 
Und dann stimmts auch wieder mit der Codegrösse und Verzögerungszeit.

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29

MFG
Falk
#943035
@ Falk

ist doch klar.. Ich hab nicht gesagt das ich solche Routinen so benutze. 
Seit mehr als 20 Jahren schiebe ich nun Bits und Bytes. In dieser Zeit 
hatte ich noch nie einen Gedanken bzw. Bedürfnis an FP in Makros oder 
Lowlevel Funktionen. Bei mir erledigen das immer IRQ's etc.

Desshalb auch meine Frage und die entsprechende Antowrt.

Cheers,
Felix
Gast #943117
vielen dank für die zahlreichen Antworten. Bin gerade nach Hause 
gekommen und ich denke mein Problem beruht auf einer Mischung der von 
euch angesprochenen Problemen.

Grundsätzlich meinte ich natürlich == und nicht = in der der while 
Bedingung. Wobei sogar beides den gleichen Effekt hatte :D.

Nachdem ich jetzt nochmal über den Code geschaut habe muss ich wohl zu 
dem Schluss kommen, das es tatsächlich die FP Operationen waren, welche 
die eigentliche Codegröße verursachen und wie von yalu angemerkt, in 
Abhängigkeit von der meiner schleife wohl "wegoptimiert" wurden.

So ganz klar mir mir das zwar noch nicht, weil ich eigentlich nicht 
glaube, das meine Schleifen die ich getestet hab, endlos sind. Bin etwas 
verwirrt.

Aber ich werde mir Morgen den Code nochmal in aller anschauen und mich 
gegebenenfalls nochmal melden.

Vielen Danke!
Gruß Crispy

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 18 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.