Speicher richtig nutzen

[D a v i d K. (oekel)]

Hi,
ich muss zur später Stunde noch eine dumme Frage loswerden :)

AVR Memory Usage
----------------
Device: atmega16
Program:   15716 bytes (95.9% Full)
(.text + .data + .bootloader)
Data:        327 bytes (31.9% Full)
(.data + .bss + .noinit)
EEPROM:        6 bytes (1.2% Full)
(.eeprom)

Abgesehen davon, dass ich
-  20% Testroutinen mit zusätzlichem Display drin habe
-  einige Strings auf den Eprom auslagern kann.
-  sehr bald auf einen atmega32 oder 664 umsteingen werde.

Was ist noch anständige Programmiertechnik, um den Flash weniger und 
dafür das Eprom mehr zu nutzen?



Grüße Oekel

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Angesichts der geringen Größe des EEPROMs? Nichts.

Entferne in finalen Versionen Deine Testroutinen.

[Rolf M. (rmagnus)]

Ben B. schrieb:
> Angesichts der geringen Größe des EEPROMs? Nichts.

Außerdem ist das EEPROM langsam, und man kann keinen Code dort 
ausführen. Es ist nur dazu gedacht, um sich über Aus-/Ainschaltzyklen 
hinweg ein paar Werte merken zu können.
Prinzipiell könnte man sich aber Initialwerte von Variablen darin 
merken. Man muss die Werte dann allerdings alle selbst in die Variablen 
schreiben, was wieder zusätzlichen Code produziert, der den Vorteil 
wieder verschlingt.

[Wolfgang (Gast)]

D a v i d K. schrieb:
> Was ist noch anständige Programmiertechnik, um den Flash weniger und
> dafür das Eprom mehr zu nutzen?

Das hängt von deinem Programm ab. Was hast du an evtl. unnötig 
luxoriösen Blbliotheksroutinen verwendet (Float, formatierte Ausgaben), 
was kann von den Daten ins EEPROM verlagert werden, ...
Nur du kennst dein Programm.

[Peter D. (peda)]

D a v i d K. schrieb:
> Was ist noch anständige Programmiertechnik, um den Flash weniger und
> dafür das Eprom mehr zu nutzen?

Für weniger Flash:
Copy&Paste Monster durch Schleifen, Tabellen und Unterfunktionen 
ersetzen.

Ich finde es immer wieder nervend, wenn man haufenweise Codesequenzen 
lesen muß, die zu 90% identisch sind. Ich komme mir dabei vor, wie bei 
Sport1: Finden sie die 4 Unterschiede.

[Peter D. (peda)]

Wolfgang schrieb:
> Was hast du an evtl. unnötig
> luxoriösen Blbliotheksroutinen verwendet (Float, formatierte Ausgaben)

Bibliotheken kosten immer nur beim ersten Aufruf was. Sie machen selten 
den Hauptteil des Flashverbrauchs aus.

[Purzel H. (hacky)]

> Device: atmega16
Program:   15716 bytes (95.9% Full)

Raus mit dem unnoetigen Muell. zB weg mit
- printf()
- floating point
- stringlibraries
- andere libraries

[Rolf M. (rmagnus)]

Peter D. schrieb:
> Wolfgang schrieb:
>> Was hast du an evtl. unnötig
>> luxoriösen Blbliotheksroutinen verwendet (Float, formatierte Ausgaben)
>
> Bibliotheken kosten immer nur beim ersten Aufruf was.

Dann aber ggf. recht viel. Anders ausgedrückt: Es reicht nicht, einen 
einzelnen Aufruf einer großen Bibliotheksfunktion zu entfernen, sondern 
es müssen schon alle sein.

> Sie machen selten den Hauptteil des Flashverbrauchs aus.

Ja, wenn man weiß, welche zu vermeiden sind.

[DPA (Gast)]

Auf jeden fall mit "-Os -ffunction-sections -fdata-sections 
-Wl,-gc-sections" kompilieren & linken.

[Carl D. (jcw2)]

DPA schrieb:
> Auf jeden fall mit "-Os -ffunction-sections -fdata-sections
> -Wl,-gc-sections" kompilieren & linken.

Es gibt auch die AVR-spezifische Option

-mcall-prologues

mit der Push/Pop-Sequenzen am Anfang und Ende von Funktionen trickreich 
verkleinert werden. Bei "vielen Funktionen" kann das helfen.

[Boris O. (bohnsorg)]

D a v i d K. schrieb:
>
> Was ist noch anständige Programmiertechnik, um den Flash weniger und
> dafür das Eprom mehr zu nutzen?
>
Welches Problem willst du lösen? Wenn ich einen 4k-Mikrocontroller zu 
90% fülle, habe ich die richtige Flash-Größe verbaut. Wenn ein 
8k-Mikrocontroller zu teuer ist, der Code aber 4,1k Größe hätte, würde 
ich in Hektik ausbrechen und etwas ändern.

Grundsätzlich kannst du den EEPROM auf zwei Arten verwenden:
1. Kalibrierung bei der Programmierung
2. Zustandsgröße(n) über Ausschaltung retten.

Den 1. Fall hast du, wenn du den ADC verwendest und irgendwie 
kompensieren musst (Stichwort Gain-Error, Offset, Linearität). Du legst 
dort einmal für jeden Controller spezifische Werte ab. Während der 
gesamten Lebenszeit ändern sich die Daten nicht. Der Vorteil: das 
Programm bleibt dasselbe, nur der EEPROM-Teil muss je Controller 
geändert werden.

Im 2. Fall wird es komplizierter, da es mit der Anzahl der Schreibzyklen 
weitere Einschränkungen gibt, der EEPROM ist nicht unbegrenzt oft 
schreibbar. Es fällt Zusatzaufwand wie ein Ringspeicher an, den EEPROM 
gleichmäßig zu nutzen. Dabei wird ein deutlich kleinerer Datensatz im 
EEPROM fortlaufend verteilt und ein Adressring im EEPROM zeigt die 
aktuelle Adresse an. Das verkleinert den Speicher weiter.

[Wolfgang (Gast)]

Peter D. schrieb:
> Bibliotheken kosten immer nur beim ersten Aufruf was. Sie machen selten
> den Hauptteil des Flashverbrauchs aus.

Das kommt auf das Programm an.
Bei einem simplen 'printf("Hello World %.3f",3.14/pi()'-Programm kann 
das anteilig schnell ausarten und das Programm vom TO kennt nur er 
selber.

Er könnte natürlich mal in seinen LST-File gucken, um zu ergründen, wo 
der Speicher bleibt.

[Einer K. (Gast)]

Wolfgang schrieb:
> 'printf("Hello World %.3f",3.14/pi()'
sprintf und sscanf mit float Unterstützung kosten auf einem AVR schnell 
mal eben 3,5k Flash

Das sind bald 25% dieses µC

--------
> Was ist noch anständige Programmiertechnik,
Ohne den Code zu sehen ist das alles nur stochern im Nebel.

Wie soll man vergleichen und entscheiden können, wenn man nichts sieht?

[D a v i d K. (oekel)]

Jetzt ist G. schrieb:
>> Device: atmega16
> Program:   15716 bytes (95.9% Full)
>
> Raus mit dem unnoetigen Muell. zB weg mit
> - printf()
> - floating point
> - stringlibraries
> - andere libraries

Hab ich alles erst gar nicht drin...

Arduino Fanboy D. schrieb:
> Ohne den Code zu sehen ist das alles nur stochern im Nebel.

Ging mir auch nur um grundlegende Dinge.

DPA schrieb:
> Auf jeden fall mit "-Os -ffunction-sections -fdata-sections
> -Wl,-gc-sections" kompilieren & linken.

Hat tatsächlich noch 2% gebraucht! Danke

Wolfgang schrieb:
> Er könnte natürlich mal in seinen LST-File gucken, um zu ergründen, wo
> der Speicher bleibt.

Kannst du da evtl. genauer drauf eingehen. Klingt nach einer weiteren 
Wissenslücke bei mir.

[Carl D. (jcw2)]

D a v i d K. schrieb:
> DPA schrieb:
>> Auf jeden fall mit "-Os -ffunction-sections -fdata-sections
>> -Wl,-gc-sections" kompilieren & linken.
>
> Hat tatsächlich noch 2% gebraucht! Danke

Probier mal zusätzlich (wie schon weiter oben geschrieben)
  -mcall-prologues
einfach um mal zu sehen wieviel % noch drin sind.

[Peter D. (peda)]

D a v i d K. schrieb:
> Ging mir auch nur um grundlegende Dinge.

Wie schon gesagt, der Hauptfeind sind riesige Copy&Paste Sequenzen.
Das Weglassen von Libs oder Compilerschalter bringen nur homöopathische 
Einsparungen.

[JAWA (Gast)]

D a v i d K. schrieb:
> Wolfgang schrieb:
>> Er könnte natürlich mal in seinen LST-File gucken, um zu ergründen, wo
>> der Speicher bleibt.
>
> Kannst du da evtl. genauer drauf eingehen. Klingt nach einer weiteren
> Wissenslücke bei mir.

Das hört sich danach an das readelf, nm, size und objdump nicht wirklich 
bekannt sind?

[Frank M. (ukw) (Moderator)]

D a v i d K. schrieb:
> DPA schrieb:
>> Auf jeden fall mit "-Os -ffunction-sections -fdata-sections
>> -Wl,-gc-sections" kompilieren & linken.
>
> Hat tatsächlich noch 2% gebraucht! Danke

LTO bringt meist auch noch etwas.

Also:

  -flto

beim Compilieren & Linken einbauen.