SRAM zu voll?

David Gast #2686877
Lesenswert?
• ▲
▼ 
Hallo,

Ich habe nachdem compilieren eines Programmes (LCD Display mit 
lcd_strings als Ausgabe) nach dem Compilieren 99% voll 
.data+.bss,+noint, also SRAM.

Wenn ich das Programm starte, spielt es nach kurzer Zeit <1s verrückt. 
Display zeigt wirres Zeug bzw. schon das was es soll, aber nicht 
vollständig und nicht in der Zeile, wo es soll, das Programm selbst tut 
auch nicht, was es soll (vorwiegend Interrupt gesteuert).

Kann es sein, das der Stack dadurch überläuft und der AVR sich aufhängt? 
Oder kann man beim Compilieren den SRAM wirklich 100% ausnutzen?

Merci.

David
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Peter II Gast #2686880
Lesenswert?
• ▲
▼ 
David schrieb:
> Kann es sein, das der Stack dadurch überläuft
ja, sogar sehr wahrscheinlich

> und der AVR sich aufhängt?
nein, der AVR hat überhaupt keinen Grund sich bei soetwas aufzuhängen. 
Er macht nur nicht das was du erwartest, für ihn selber ist noch alles 
ok.

> Oder kann man beim Compilieren den SRAM wirklich 100% ausnutzen?
nein kann man nicht.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
David Gast #2686885
Lesenswert?
• ▲
▼ 
Ok, dann habe ich wohl die Ursache gefunden.
Ich wurde schon verrückt, bin stundenlang das Programm durchgegangen.
Gibt es irgendwo eine Grenze, wo man sagt, hierüber darf man nicht (% 
Auslastung).
Vermutlich nicht, weil es ja programmabhänging sein wird, wie 
verschachtelt dieses ist. Aber so eine Sicherheitsgrenze aus dem 
Bauch/Erfahrung?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
c-ler Gast #2686903
Lesenswert?
• ▲
▼ 
Was dir beim Kompilieren an SRAM Verbrauch angezeigt wird ist nur der 
Teil des SRAMs, der SICHER belegt ist.
Also zum Beispiel globale oder statische Variablen. Alles, was später 
malauf dem Stack landet, gehört da nicht dazu.
Aber nicht nur lokale Variablen, die nur innerhalb ihrer Funktion 
existieren liegen auf dem Stack. Jeder Funktionsaufruf kostet dich 
Stackspeicher für die übergebenen Argumente, die Rücksprungaddresse und 
evtl. noch für den Rückgabewert.
Wenn du Funktionen rekursiv aufrufst kann sich der Stackverbrauch enorm 
Aufschaukeln.

Wann du lieber aufhören solltest, statischen Speicher zu verbrauchen 
kann man also Pauschal nicht sagen. Kommt immer drauf an wie intensiv du 
deine Funktionen ineinander verschachtelst.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Achim M. #2686905
Lesenswert?
• ▲
▼ 
David schrieb:
> hierüber darf man nicht (%
> Auslastung).

Wie weit ist der SRAM durch static- und global-Variablen schon 
ausgelastet?
Dazu kommt die maximale Verschachtelungstiefe deiner Funktionen(welche 
Register müssen nach dem call gerettet werden).

Manchmal brauchen Funktionen auch selbst noch RAM, z.B. wenn du 
innerhalb einer Funktion ein uint8_t-Array mit einer Zahl am Members 
größer als die gerade freien Register definierst.

Man kann das also pauschal nicht sagen. Schau dazu am besten das 
generierte Assemblerlisting nach STS usw durch. Konstante Strings wie 
Namen von Menüpunkten o.Ä. speichert man am besten mit PROGMEM in den 
Flash. Dann werden die Strings nicht erst in den RAM kopiert und von da 
aus auf dem LCD ausgegeben.

mfg mf
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Nachtaktiver Gast #2687179
Lesenswert?
• ▲
▼ 
David schrieb:
> Danke für das Angebot. Ich versuche mal die LCD_strings in den SRAM
> auszulagern und dann versuche ich es nochmal. Sollte es nicht klappen,
> melde ich mich.

Du meinst in den Flash - Im SRAM sind die bereit.

Ich kann dir das Tutorial zu den einzelnen Speicherarten hier im µc.net 
sehr gut empfehlen!

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl H. #2687187
Lesenswert?
• ▲
▼ 
Nachtaktiver schrieb:
> David schrieb:
>> Danke für das Angebot. Ich versuche mal die LCD_strings in den SRAM
>> auszulagern und dann versuche ich es nochmal. Sollte es nicht klappen,
>> melde ich mich.
>
> Du meinst in den Flash - Im SRAM sind die bereit.

Nitpicking:
... und im Flash auch. (wie kämen sie sonst beim Hochfahren ins SRAM)

D.h. das ist eigentlich gar kein Auslagern, sondern das Verhindern einer 
unnützen Kopie, die nur SRAM belegt und sonst zu nichts gut ist (solange 
die Strings nicht verändert werden müssen)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren