Speicher richtig nutzen

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

Entferne in finalen Versionen Deine Testroutinen.

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.

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.

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.

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

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

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 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.

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.

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.

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.

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.

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.