Gast
#5223800
'-Os' läßt ja der benötigten Flashspeicher schrumpfen. Welche von den vielen -f... Optionen nimmt man, wenn man noch viel Flashspeicher frei hat, aber das SRAM zur Neige geht?
Gast
#5223817
Ich bezweifle, dass es da entscheidende Unterschiede gibt. Du musst vielmehr dein Programm handoptimieren...
Gast
#5223820
Wenn du noch viel Flash über hast, heißt das ja, dass du nicht viel Code hast, aber sich anscheinend viele Daten in Arrays etc. häufen. Die werden natürlich nicht kleiner. Daten sind Daten. Du musst einfach sinnvoll planen, sofern möglich.
SRAM ist voll schrieb: > '-Os' läßt ja der benötigten Flashspeicher schrumpfen. > > Welche von den vielen -f... Optionen nimmt man, wenn man noch viel > Flashspeicher frei hat, aber das SRAM zur Neige geht? Sind die verwendeten Strings schon im Flash, oder sind die noch im RAM?
1 | |
sieht dank const nicht so aus, aber belegt 11Byte wertvolles RAM http://www.nongnu.org/avr-libc/user-manual/pgmspace.html beschreibt was man dagegen tun kann.
SRAM ist voll schrieb: > '-Os' läßt ja der benötigten Flashspeicher schrumpfen. > > Welche von den vielen -f... Optionen nimmt man, wenn man noch viel > Flashspeicher frei hat, aber das SRAM zur Neige geht? Welche Sprache soll es denn sein? Um RAM zu sparen, sollte / kann man C++ möglichst viel Information in die Datentypen codieren: das hat zur Folge, dass 1) der Compiler viel besser optimieren kann, da er mehr Typinformationen zur Verfügung hat 2) man "gezwungen" ist, sich zu überlegen, welche Informationen man zur Compilezeit ggf. durch Meta-Funktionen schon berechnen kann. Datentypen als solche sind ja im Maschinencode nicht mehr präsent und belegen keine SRAM. Meine Beobachtung bei fremden Code ist, dass die meisten Leute sich viel zu wenig Gedanken um ihr (domänenspezifisches) Typ-System machen. Aber genau das ist das A-und-O. Natürlich kann(!) (nicht muss) extensive Nutzung der Template-Mechanik zur Produktion von mehr Code (im Flash) führen. Allerdings sind teilweise die Optimierungen des Clang / gcc bei template-code geradezu "atemberaubend", und andererseits tun ein paar (k)Byte mehr Flashverbrauch weniger weh als beim SRAM.
Carl D. schrieb: > Sind die verwendeten Strings schon im Flash, oder sind die noch im > RAM?const char string[] = "ein String";sieht dank const nicht so aus, > aber belegt 11Byte wertvolles RAM Nicht unbedingt. Das hängt von der (hier unbekannten) Architektur ab. > http://www.nongnu.org/avr-libc/user-manual/pgmspace.html > beschreibt was man dagegen tun kann. Ja, für den AVR hast du recht.
Rolf M. schrieb: > Carl D. schrieb: >> Sind die verwendeten Strings schon im Flash, oder sind die noch im >> RAM?const char string[] = "ein String";sieht dank const nicht so aus, >> aber belegt 11Byte wertvolles RAM > > Nicht unbedingt. Das hängt von der (hier unbekannten) Architektur ab. > >> http://www.nongnu.org/avr-libc/user-manual/pgmspace.html >> beschreibt was man dagegen tun kann. > > Ja, für den AVR hast du recht. Stimmt, ich hab dieses Forum als AVR-Forum kennengelernt und so was prägt.