AVR Compilerfrage (Platz sparen)

Gast #2976846
Lesenswert?

Hi,

mein Projekt ist nun so groß das es nicht mehr in den AVR passt. Nun 
überlege ich ob ich noch irgendwie Platz sparen kann...

Ich nutze zur Zeit einen Atmega48. Als Optimization ist -0s eingestellt. 
Landen damit auch alle nicht angesprochnen Funktionen mit im Hexfile? 
ALso Funktionen welche es gibt, aber nicht genutzt werden!?

Was ist z.B. mit Funktionen mit einem Warning "Implicit declaration".Ist 
noch in der Entwicklungphase, habe ich noch keinen Prototypen für 
angegeben. Ist kein Problem, sind nur 2, aber es interessiert mich in 
dem Zusammenhang...

JJ
Gast #2976858
Lesenswert?

habe nun mal auf -0s umgestellt, Rebuild all, gab eine Fehlermeldung:

\..\..\avr\bin\ld.exe: region text is full (test.elf section .text)

Keine Ahnung.

@Timmo:

Danke, guter Tip. Dennoch werde ich keine Wissenschaft daraus machen, 
dafür lohnt es nicht... :-)

>>Atmega88/168/328

möchte ich vermeiden, lohnt nicht, habe den 48 noch liegen...

JJ
Gast #2976875
Lesenswert?

>>Zeig halt mal ein bisschen Code,

ich stecke mitten drin, selbst wenn ich wollte wüsste ich nicht wo ich 
anfangen soll. Deswegen wäre ich ganz froh zu wissen was das mit dem elf 
Fiel Error auf sich hat...und vielleicht noch, ob man mit -03 besser weg 
kommt als mit -0s falls man das überhaupt so sagen kann.

Sollte es nicht gehen werde ich für die Entwicklungsphase erstmal 2- 
168iger nehmen...

JJ
#2976885
Lesenswert?

Jens schrieb:
>>>Zeig halt mal ein bisschen Code,
>
> ich stecke mitten drin, selbst wenn ich wollte wüsste ich nicht wo ich
> anfangen soll. Deswegen wäre ich ganz froh zu wissen was das mit dem elf
> Fiel Error auf sich hat...

Dein Programm ist zu groß


Entweder du siehst so mal über den Code drüber, oder du lässt dir ein 
Map-File erzeugen und siehst da mal rein und fahndest nach Funktionen, 
die dir vergleichsweise groß vorkommen (für das was sie machen).

Überall den kleinsten Datentyp nehmen, der möglich ist. Das kommt der 
Ausführungszeit als auch der Codegröße zu gute.
Floating Point Arithmetik braucht viel Platz
sprintf ist ein Codefresser.


Viel Kleinvieh macht eben auch Mist.


> Sollte es nicht gehen werde ich für die Entwicklungsphase erstmal 2-
> 168iger nehmen...

Ich kenn ja dein Programm nicht. Vielleicht ist da ja wirklich nichts 
mehr drinn um die Codegröße runterzubringen. Wenn dem so ist, dann wirds 
wohl darauf hinauslaufen. Ist dem aber nicht so, dann lernst du für die 
Zukunft mehr, wenn wer anderer da mal drüber schaut.
#2976889
Lesenswert?

Jens schrieb:
> @Timmo:
>
> Danke, guter Tip. Dennoch werde ich keine Wissenschaft daraus machen,
> dafür lohnt es nicht... :-)
Musst du auch nicht. Aber mit "avr-nm" kann man schonmal sehr gut 
herausfinden welche Funktionen die größten sind und die könnte man sich 
dann erstmal rauspicken und versuchen zu optimieren.
Es kann schon viel bringen z.B. volatile Variablen die in einer Funktion 
mehrfach angefasst werden erstmal in eine lokale Variable zu kopieren 
und am ende den Wert dann wieder zurückzuschreiben.
Ohne Code wird es für uns natürlich schwierig dir ein paar Tipps zu 
geben wo noch Optimierungspotential ist.
Vielleicht hast du ja auch einen riesen Haufen Strings im Code... da 
würde ich dann erstmal versuchen ein paar Strings zu kürzen.
Funktionen wie (s)printf etc. brauchen z.B. auch sehr viel speicher und 
sind oftmals unnötig. Auch float/double solltest du vermeiden. Aber wir 
wissen ja nicht was du da so hast.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren