www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Was passiert wenn das RAM nicht ausreicht?


Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was passiert dann theoretisch und praktisch?

Mir ist aufgefallen, dass Compiler und Debuger (IAR) noch problemlos 
arbeiten, aber der MC (MSP430) nicht mehr arbeitet; die Hello World - 
LED blinkt nicht mehr.Ist das normal?
Bleibt da nichts außer trial and error und man hat dann einfach Pech, 
wenn nach einem Jahr plötzlich das RAM nicht mehr reicht?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was meinst du mit "wenn nach einem Jahr plötzlich das RAM nicht mehr 
reicht"? Wenn das RAM mit der Zeit immer voller wird dann hat man einen 
Fehler im Programm, normal ist das nicht.

Autor: Schmittchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Compiler und Debugger laufen natürlich problemlos, sie sind ja auch 
nicht vom RAM des µC abhängig. Wenn deine Software im µC läuft, dann 
kann sie wg. eines Programmfehlers (z.B. Stack läuft voll) abstürzen. 
Ich vermute aber du meinst, daß du nicht weisst wieviel RAM du für deine 
Applikation benötigst bzw. der Compiler verbraucht. Wie man das mit dem 
IAR-Compiler feststellt kann ich dir nicht sagen. GCC/make gibt mit 
"make size" oder "avr-size" Auskunft über den verwendeten Speicherplatz 
RAM/ROM.

Schmittchen "mehr konnte ich aus deiner vagen Fragestellung nicht 
herauslesen".

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, kann der gcc denn das maximal belegte RAM bestimmen?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist warscheinlich die schwierigste Frage bei der Softwareentwicklung 
überhaupt.
Wie sonst sind die vielen Blue-Screens und Exceptions bei kommerziellen 
Programmen und Betriebssystemen zu erklären.

Es hängt sehr stark von der Architektur und dem Compiler ab.

Beim 8051 und dem Keil ist das z.B. sehr einfach, da dort direkte 
Zugriffe auf den RAM am komfortabelsten sind.
D.h. der Kompiler stellt eine Calling-Tree auf und weist dann jeder 
Funktion direkt Speicher zu.
Im *.map-File kann man dann schön sehen, wieviel Speicher insgesamt 
belegt wird und wieviel noch frei ist. Man erkennt auch sofort die 
Kandidaten, die am meisten RAM verschlingen, d.h. wo eine Optimierung am 
meisten bringen würde.
Falls der Linker es nicht schafft, alle Variablen unterzubringen, 
meckert er sofort.
Der Stack dient fast nur zum Speichern der Returnadressen, bzw. der 
Register in Interrupts. Je nach Programmgröße reichen etwa 16 Byte für 
den Stack aus.


Bei Architekturen, die dagegen wenig Register haben und fast alles auf 
dem Stack machen müssen, ist das wesentlich schwieriger, da der Stack ja 
erst zur Laufzeit benutzt wird.
Nur static und globale Variablen sind sichtbar.

Da hilft eigentlich nur, den Stack zur Laufzeit z.B. in einem 
Timerinterrupt permanent zu überwachen und eine Alarmmeldung auszugeben, 
wenn eine kritische Größe unterschritten wird.


Peter

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Funktioniert das denn auch immer richtig?

Mit sowas wie einer rekursiven Funktion oder malloc kann man ja schnell 
die Limits erreichen.
Welche Einschränkungen brauchen gcc und Keil denn?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Malloc und Rekursionen sind Teufelszeug und haben auf einem µC nichts zu 
suchen, wenn man auf Stabilität und Zuverlässigkeit Wert legt !


Malloc braucht man nicht, da ja auf einem µC fest steht, welche 
Funktionen laufen müssen und wieviel Speicher sie benötigen.
Und nur dann, wenn man die Variablen schon zur Compilezeit in der 
richtigen Größe angibt, ist der Linker auch in der Lage, den benötigten 
Speicher zu berechnen und zu meckern, falls es nicht reicht.
Natürlich sollte man zur effektiven Speicherverwaltung auch 
Variablenfelder lokal zu einer Funktion anlegen, wenn sie nur benötigt 
werden, solange diese Funktion auch ausgeführt wird.


Rekursionen sind nur ein Programmierstil um Funktionen möglichst 
unlesbar zu gestalten.
Oftmals braucht es lange, um die Abbruchbedingung zu erkennen. Auch beim 
Debuggen sind Rekursionen nur schwer zu handhaben, da man dann von 
sämtlichen Variablen mehrere verschiedene Instanzen hat und der Debugger 
aber immer nur die letzte Instanz anzeigt.

Die Hauptgefahr, besteht jedoch darin, daß Rekursionen dazu verleiten, 
eine Notabbruchbedingung zu vergessen !

D.h. wenn durch ungünstige Eingangswerte die geplante Abbruchbedingung 
nie erreicht wird, spielt es keine Rolle, ob ich 128 Byte oder 128MByte 
RAM habe. Es dauert nur unterschiedlich lange, bis die Endlosrekursion 
den Speicher aufgebraucht hat und die CPU sich ins Nirwana 
verabschiedet.

Beliebte Absturzbeispiele sind float Vergleich auf 0 oder 
Reihenentwicklung mit ständig schwankendem Endergebnis.


Bei einer besser lesbaren Schleifenprogramierung bietet sich der 
Schleifenzähler quasi von selbst an, bei Überschreitung eine 
Fehlerbehandlung durchzuführen, ohne daß die CPU komplett abschmiert.
Der Debugger kann durch den Schleifenindex auch bequem die 
Zwischenergebnisse jedes Durchlaufs darstellen, da ja alle Variablen 
während des gesamten Durchlaufs sichtbar sind.

Auch sind Schleifen wesentlich effektiver im Speicherverbrauch und auch 
schneller, da unnötige CALLs und RETURNs entfallen.
Rekursionen müssen für jede Variable bei jedem Durchlauf umständlich 
Duplikate auf dem Stack anlegen.
Schleifen können dagegen Variablen die nur einmal benötigt werden auch 
nur einmal anlegen bzw. alle Variablenfelder auf einen Ruck anlegen.


Es gibt ja immer mal Konteste, wer den unleserlichsten C-Code schreiben 
kann, Rekursionen sind da immer mit dabei.


Peter

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, den obfuscated C code contest kenne ich: http://www.ioccc.org/

Mir geht es aber darum zu erfahren unter welchen Bedingungen man 
zumindest verifizieren kann, dass das RAM immer ausreicht.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt, ich kenne nur den Keil C51 und da reicht ein Blick ins 
*.map-File um zu sehen obs klemmt und wenn ja, wo.

Vorausgesetzt, man macht nicht diese Schweinereien (malloc, recursiv).


Peter

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.