AVRGCC code zu gross...

[MArkus Gross (Gast)]

Hallo,

ich entwickele gerade ein Projekt mit einem ATMEGA48.
ICh wuerde gerne floats verwenden nd diese auf das display ausgeben.
Doch reicht fuer diese "einfache" aufgabe der speicher bereits (oder
fast) nichtmehr aus.
Da ich newbe in uC programmierung in C bin, wollte ich fragen wo mein
Fehler liegt, oder ob das normal ist??

Danke,
Markus

[inoffizieller WM-Rahul (Gast)]

Wenn du eine grössere Menge Standard-Funktionenen (printf etc)
verwendest, schleppst du möglicherweise eine Menge unnötigen Ballast
mit dir rum.

[johnny.m (Gast)]

1.: Compiler-Optimierung eingeschaltet? Wenn nicht, dann ist es normal,
dass der Code sehr groß wird.

2.: Floats lassen sich in vielen Fällen geschickt vermeiden. Wenn der
Speicherplatz wirklich knapp wird, dann versuchen, alle Berechnungen in
Integer durchzuführen. I.d.R. sind floats auch gar nicht sinnvoll. Je
nach Anwendung (Ich weiß ja nicht, wofür Du floats zu brauchen
meinst...) kann man sehr einfach die Berechnungen in int durchführen
(Bsp: Es soll eine Anzeige in Volt ausgegeben werden, mit
Millivolt-Auflösung. In dem Fall nicht in float rechnen, sondern
ganzzahlig direkt in Millivolt (also alle Volt-Werte mit 1000
multiplizieren). Bei der Ausgabe muss dann nur noch das Komma an die
richtige Stelle gesetzt werden, was mit einer "modulo (%) 1000" und
einer "durch (/) 1000"-Operation kein Problem ist).

[johnny.m (Gast)]

Ach ja,
3.: Es gibt hier ein extra GCC-Forum, da sind solche Fragen i.d.R.
besser aufgehoben...

[Markus Gross (Gast)]

Hmm,

Optimierung ist an (-Os) aber ich verwende die fprintf aus der lib ->
ca 40 % belegt.

Ich werde es nun mit ints machen, aber das ist nicht so einfach, da ich
eine genauigkeit von 24 bit benoetige...
also int32_... Dort sind Multiplikationen auch nicht gut, denn dann
bekommt man u.u. 64 bit integer. Wenn ich diese implementiere ist der
speicher auch voll...

Gibt es eine moeglickeit nicht verwendete funtionen (der genannte
ballast) rauszuwerfen ???

Gruss,
Markus

[Wolfram (Gast)]

>Ich werde es nun mit ints machen, aber das ist nicht so einfach, da
ich
>eine genauigkeit von 24 bit benoetige
die wirst du mit einem float sowieso nicht erreichen
1 sign bit, 8 exponent ,23bit mantisse

wenn du fprintf benutzt musst du dich nicht wundern das dein Platz
nicht reicht, so etwas ist eine sehr komplexe Funktion.

[Rolf Magnus (Gast)]

> also int32_... Dort sind Multiplikationen auch nicht gut,

Naja, sie sind jedenfalls viel einfacher, als welche mit
Fließkommazahlen.

> denn dann bekommt man u.u. 64 bit integer.

Nicht in C. Da ist das Ergebnis immer vom selben Typ, wie die
Operanden.

> 1 sign bit, 8 exponent ,23bit mantisse

Ist auch nicht weniger Genauigkeit, als bei einem vorzeichenbehafteten
24-bit-Integer. Ich werde wohl nie verstehen, warum das Vorzeichen hier
so unglücklich abgetrennt wurde.

[Jörg W. (dl8dtl) (Moderator)]

Ich habe den Eindruck, dass du das Pferd von hinten aufgezäumt
hast.  Du hast bestimmte (nicht gerade 08/15-)Forderungen an
die Genauigkeit und sonstige Funktion, dich aber gleich erstmal
auf einen der kleinsten Prozessoren festgelegt, ohne überhaupt
zu wissen, ob dieser die Aufgabe mit vertretbarem Aufwand
erfüllen kann.

Eigentlich wählt man eher den umgekehrten Weg: der Prototyp wird
auf einem hinreichend großen Prozessor grob zusammengenagelt,
also vielleicht auf einem ATmega128.  Der hat nicht nur JTAG,
was das Debuggen vereinfacht, sondern auch genügend Reserven an
RAM und ROM im Vergleich zu deinem Zielprozessor, dass man nicht
bei der Entwicklung sofort anfangen muss, jedes klitzekleine
Eckchen zu optimieren.

Wenn man dann weiß, was man ungefährt braucht, kann man sich an
den Zielprozessor machen.

In deinem Fall hast du zumindest dahin gehend Glück, dass du ohne
sonstige Änderungen einen ATmega168 nehmen kannst für die
Entwicklung.  Ist (bis auf Kleinigkeiten wie den Bootloader)
pin- und funktionskompatibel mit dem ATmega48, bietet aber die
Freiräume für Resourcen, die man während der Projektentwicklung
einfach mal braucht.