mikrocontroller.net

Forum: Compiler & IDEs ATMega128 - Ram wird eng.


Autor: Der Albi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.
Ich schreibe zur Zeit an einem guten Stück Software für meinen
ATMega128, der ja bekanntlich 4kb Ram hat.
Ich brauche 3 mal einen 512-Byte-Buffer und habe noch einige globale
Variablen. AVR-Studio mit ggc-Plugin sagt:

Program:   42284 bytes (32.3% Full)
(.text + .data + .bootloader)
Data:       1943 bytes (47.4% Full)
(.data + .bss + .noinit)

Threoretisch müsste ich ja jetzt noch ungefähr die Hälfte des Rams frei
haben.

Wenn ich mir ein paar Adressen von globalen Variablen ausgeben lasse,
liegen die alle so bei ~1600.
Lokale Variablen z.B. ein paar 64-Byte Arrays liegen bei ~4300.
Die Prozedurverschachtelung ist nicht sehr hoch, weshalb ich
ausschließen kann, dass der Stack mit Rücksprungaddressen vollgemüllt
ist. Aber mir stellt sich die Frage: mit was dann?
Wie sieht es z.B. mit Strings aus? Werden die in den Ram geladen, wenn
das Programm startet? Als weiteres ist mir aufgefallen, dass sich die
Funktionalität meines Programms verbessert, wenn ich die globalen
Variablen als extern deklariere. Warum?

Gibt es eigentlich eine Möglichkeit lokale Variablen (und Arrays) vor
dem return zu vernichten (also sofort nachdem ich die Variable nicht
mehr brauche)? Oder müsste ich dann auf malloc und free
zurückgreifen....
Ich vermute nämlich das dieses Vorgehen auch ein wenig helfen würde.
Dann würden nicht alle kleinen Arrays noch leben, wenn ich schon in
einer ganz anderen Unterprozedur gelandet bin und des Datenbereich eh
nicht mehr brauche...
Auf geschwindigkeits kommts bei mir nicht wirklich an.

Falls sonst noch jemand Tips hat, wie man den Speicher leerer bekommt -
ich bin für alles offen.

MFG

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strings werden vom Flash ins RAM geladen. Also ins Flash packen (PSTR
Macro, pgmspace.h). Erschwert deren Verwendung zwar ungemein, macht
aber den Platz frei.

Finale Lösung: externes RAM.

Autor: Der Albi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Finale Lösung: externes RAM.
Das steht leider nicht zur Verfügung...
Wie sieht es eigentlich mit der Adresse der lokalen Variable aus?
ist 4300 OK, oder nicht? Der Stack wird ja von der höchsten Adresse aus
adressiert.... ist das irgendwas auffällig?
(ich weiß, das 4300 über 4096 liegt - aber ich meine gelesen zu haben,
dass der ram noch etwas weiter geht)
MFG

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der RAM des ATmega128 beginnt bei 0x100 (= 256) und geht daher
bis 0x1100 (= 4352).  Damit ist 4300 eine normale auf dem Stack
liegende Adresse, mithin sinnvoll für eine lokale Variable.

Letzter Ausweg: Upgrade auf ATmega1281.

Autor: Der Albi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also so wies aussieht, zählen die Strings mit in die Speicher-Angabe des
AVRStudios mit hinein. Also ist der Ram im Bereich von 0-2Kb mit
globlaen Variablen/Array belegt.

Eine Ausgabe des Stackpointers (SP) erbrachte NIE kleinere Zahlen als
4000. D.h. auf dem Stack liegt maximal weniger als ein halbes KB.

Wenn sich Heap und Stack nicht in die Quere kommen und sich nicht
gegenseitig überschreiben: an was liegt es dann?

Ich bin mir recht sicher, dass ich nicht über ArrayGrenzen hinaus
schreibe. (Das war ja der Grund, warum ich vermutete, dass der Ram voll
ist - die Arrays sind alle überdimmensioniert)

Also: Was ist es dann?

Autor: Der Albi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dreck.
Ich hasse solche Leute, die von ihren eigenen Fehlern ablenken und sie
auf den Compiler oder die Hardware schieben. Und nun bin ich selbst so
ein unmensch. grrrr.

Das Problem war, dass aufgrund von Programmierfehlern diverse Variablen
sinnlosen inhalt hatten. Nunja. Da ich ziemlich viel gesucht hatte und
das Problem nicht eingrenzen konnte, habe ich darauf geschworen, dass
es an Speichermangel liegt. Ich habe daraufhin diverse Arrays
verkleinert und weiterprobiert. Und genau diese Arrays wurden mir nun
zum Verhängnis und haben mir den Stack zerschossen.
Ich hab die Array jetzt wieder vergrößert - diesmal mit viel Vertrauen,
da ich noch 1.5kb ram frei habe (wie ich jetzt weiß) ;)
Das Problem an dem es vorher lag war auch ein unterdimmensioniertes
Array. Warum - kann ich nicht sagen. Eigentlich hätte es min. 1,5mal
für den Inhalt reichen sollen - Naja - jetzt reichts 2mal :)
Also nicht dass das so klingt, als wäre ich der komplette
Chaosprogrammierer: Die Inhalte der Arrays sind recht "dynamisch" und
unterschiedlich lang - deswegen die größeren Arrays - als Puffer für
Extremfall-Stabilität.

MFG und sorry für die verschwendete Zeit derer, die hier geantwortet
haben.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

was Jörg dir noch mitteilen wollte: Lokale Variablen liegen (sofern sie
nicht static sind) immer auf dem Stack. Deshalb auch die hohen Adressen
für deine Variablen.

Matthias

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.