www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Speicherrecourcen reduzieren in C-Programm


Autor: Johnny66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe inzwischen ein relativ großes Programm für den Atmega8 geschrieben 
(in C). Und ich bin an der Grenze des Flash Speichers angekommen. Jetzt 
versuche ich den Code zu komprimieren... Gibt es da allgemeine Tricks 
und Tipps... in der Richtung "statt Switch Case eine For Schleife 
verwenden" oder so?

Ich möchte in meinem Programm u.a. Int in Strings konvertieren und 
Strings nach float. Dazu verwende ich itoa und atof... Wenn ich atof 
einsetze belegt mein Programm aber 1kB mehr Speicher! Kann das sein?
Das Problem ist, ich habe eine Zahl in einem String die ich mit einer 
anderen Zahl multiplizieren muss und anschliessend auf einem LCD 
ausgebe.
Gäbe es da noch andere Wege außer atof und dann zurück in einen String?

Johnny

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny66 schrieb:
> float
Wenn du die float-Rechnungen durch Festkommaarithmetik ersetzen kannst 
gewinnst du viel Ressourcen. Die Float-Funktionen brauchen recht viel 
Speicher.
:-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny66 schrieb:
> Ich möchte in meinem Programm u.a. Int in Strings konvertieren und
> Strings nach float. Dazu verwende ich itoa und atof...

Hä ???

Wie wärs einfach mit:
float superkomplizierte_wandlung_int_nach_float( int zahl )
{
  return zahl;
}


Peter

Autor: Johnny66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Floh: ja, das ist eine Idee, danke!

@Peter: da habe ich mich nicht gut ausgedrückt, sorry. Das ist nicht 
eine Zahl, da gehts um zwei "Baustellen"... einmal will ich eine Int in 
einen String konvertieren und an einer anderen Stell möcht ich eine 
float aus einem String lesen.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>und an einer anderen Stell möcht ich eine
>float aus einem String lesen.

Pffffh, auch da lässt sich was mit Festkomma machen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gesetz von Moore praktisch anwenden: Atmega168 nehmen. Der hat doppelt 
so viel Flash.

Autor: Johnny66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja... wenn ich das richtig gesehen habe, dann ist der Atmega168 
identisch wie der Atmega8 aufgebaut... nur mit doppelt so großen Flash 
Speicher. D.h. ich brauche in meiner Schaltung und in meinem Programm 
nichts ändern und kann den µC einfach ersetzen?
Wenn ich das Programm nicht komprimiert bekomme werde ich das 
wahrscheinlich machen müssen...

Trotzdem interessiert es mich, wie man so programmiert dass man wenig 
Speicher belegt.

Autor: Oliver Ju. (skriptkiddy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny66 schrieb:
> Achja... wenn ich das richtig gesehen habe, dann ist der Atmega168
> identisch wie der Atmega8 aufgebaut... nur mit doppelt so großen Flash
> Speicher. D.h. ich brauche in meiner Schaltung und in meinem Programm
> nichts ändern und kann den µC einfach ersetzen?
So einfach ist es leider nicht. Der Atmega8 und der Atmega168 sind nur 
pinkompatibel. Das heißt du kannst deine Schaltung schonmal behalten. 
Allerdings sind sie nicht binärkompatibel. Das heißt du wirst Codeteile 
portieren müssen. Welche das sind, siehst du in der Appnote AVR094 [1].
Das ist zwar die Portierung von Mega8 auf Mega88, aber der Mega168 ist 
zum Mega88 binärkompatibel. Praktisch heißt das Portieren zum Schluss 
meist nicht mehr als ein paar Registernamen/Bitnamen und 
Interruptvektoren im Quelltext anpassen.

[1] http://www.atmel.com/dyn/resources/prod_documents/...


Gruß Skriptkiddy

Autor: Seltsam (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Trotzdem interessiert es mich, wie man so programmiert dass man wenig
> Speicher belegt.

Schlaumeierantwort: In dem man aufgeblasenen Code durch schlankeren Code 
ersetzt.

S.o. Floatingpoint statt Fixkomma.

Weniger oder kürzere Textmeldungen benutzen. Texte splitten und 
Recyclen.

Funktionen zu inlinen statt statisch definieren, wenn Funktionen 
vorhanden sind, die sich dafür eignen. Aufruftiefe eher flach halten.

Schlankere Datentypen verwenden. Lokale Variablen bevorzugen.

Externe Libraries unter die Lupe nehmen und granularer machen, damit der 
Linker unbenutzte Funktionen weglassen kann.

Wertetabellen durch Näherungsfunktionen ersetzen. Oder Funktionen durch 
Tabellen ersetzen. Geforderte Genauigkeit überdenken und 
Tabellen/Formeln anpassen.

Softwarefunktionen durch Hardwarefunktionen ersetzen.

PAP überarbeiten und verschlanken. Features weglassen.

Autor: Johnny66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!

@Seltsam: wenn ich externe Dateien mit Funktionen einbinde, dann werden 
doch nur die Funktionen eingebunden, die ich wirklich brauche oder?
Und die Variablem werden doch im RAM abgelegt oder? Bringt das was für 
den Flash, wenn ich z.B. statt long int, short int verwende?

Autor: Seltsam (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WinAVR-Toolchain:

Der Linker arbeitet auf der Ebene der Objektdateien. Wenn du in einer 
Objektdatei die Funktionen foo() und bar() hast, aber nur foo() benutzt, 
kann bar() als toter Code in deinem Programm landen. Und Libraries (*.a) 
Dateien sind Archive von Objektdateien. Diese Situation kannst du mit 
dem MAP und dem LSS File einfach feststellen.

Die Initialwerte von globalen und statischen Variablen müssen auch im 
Flash vorhanden sein. Der Startupcode initialisiert die Variablen mit 
den Werten aus dem Flash. Ob das beim Defaultwert (0) ebenso ist, weiss 
ich nicht aus dem Stegreif. Ich vermute, dass nur die Werte ungleich 
Defaultwert iM Flash gespeichert sind und es für den Defaultwert eine 
Ausnullschleife im Startup gibt.

Abhängig von deinem Programm solltest du wo möglich short int statt long 
int benutzen. Noch besser wäre es, wenn du auf 8-Bit gehen kannst wo 
möglich. Du sparst Platz bei den Initialwerten und beim Code. Um 
16-Bit zu verarbeiten sind deutlich mehr Register (=> PUSH/POP) und 
Verarbeitungscode erforderlich als für 8-Bit Werte. Aufpassen: Bei der 
Umstellung Programm peinlich genau aut Integerüberläufe prüfen!

Autor: uitrg789 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Zeit, die du damit verbringst, Deinen Code zu "komprimieren", kostet 
Dich viel mehr, als den µC mit größerem Flash zu kaufen.

Es sei denn, Du willst den µC verkaufen und musst die Software da
irgendwie reinquetschen.

Andersrum geht beim "Komprimieren" häufig die Uberschaubarkeit und 
Struktur des Codes soweit kaputt, dass man den Code danach sowieso nicht 
mehr warten kann.

Daher meine Empfehlung: Sauber Programmieren und wenn's nicht reicht, 
den nächstgrößeren µC einsetzen.

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uitrg789 schrieb:
> Andersrum geht beim "Komprimieren" häufig die Uberschaubarkeit und
> Struktur des Codes soweit kaputt, dass man den Code danach sowieso nicht
> mehr warten kann.

Na ja, auf der anderen Seite führt so aufräumen manchmal dazu daß der 
Code entrümpelt und "gewachsene" Geflechte besser strukturiert neu 
gemacht werden. Dann erreicht man damit gerade eine bessere 
Überschaubarkeit.

Autor: uitrg789 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin davon ausgegangen, dass der Code vor dem "Komprimieren" noch 
sauber war. Inklusive Überschaubarkeit und Struktur.

Und nicht ein schrottiger Happy-Coding-Code.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uitrg789 schrieb:
> Ich bin davon ausgegangen, dass der Code vor dem "Komprimieren" noch
> sauber war. Inklusive Überschaubarkeit und Struktur.
>
> Und nicht ein schrottiger Happy-Coding-Code.

In den meisten Fällen ist er aber genau letzteres :-)

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uitrg789 schrieb:
> Die Zeit, die du damit verbringst, Deinen Code zu "komprimieren", kostet
> Dich viel mehr, als den µC mit größerem Flash zu kaufen.
>
> Es sei denn, Du willst den µC verkaufen und musst die Software da
> irgendwie reinquetschen.
>
> Andersrum geht beim "Komprimieren" häufig die Uberschaubarkeit und
> Struktur des Codes soweit kaputt, dass man den Code danach sowieso nicht
> mehr warten kann.
>
> Daher meine Empfehlung: Sauber Programmieren und wenn's nicht reicht,
> den nächstgrößeren µC einsetzen.

Unsinn. Wenn man jedes mal doppelt so viel Flash braucht spart man mehr 
als wenn man effizient programmieren kann.

Autor: Johnny66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Leute für die Tips!

Habe vorhin auch noch das Tutorial zur AVR-GCC-Codeoptimierung 
entdeckt... das Tool avr-nm ist ja auch recht hilfreich um festzustellen 
welche Funktion besonders viel Speicher belegt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.