www.mikrocontroller.net

Forum: Compiler & IDEs double-Gebrauch verpfuscht RAM?


Autor: Zotteljedi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe hier gerade ein merkwürdiges Problem mit einem ATmega8. Es geht 
um PWM und die Ausgabe von Sinus-Schwingungen. Ich weiß, daß man die 
Werte "offline" ausrechnen und im Flash versenken kann, aber ich will im 
Moment das Problem verstehen.

Ich habe ca. 450 Byte RAM mit globalen Variablen voll ('n dickes Array, 
int8_t[435], und etwas Kleinzeug). Nun scheint der Gebrauch von 
double-Variablen und der sin-Funktion einen Teil des Arrays zu 
überschreiben, jedenfalls steht da gegen Ende kranker Kram drin, den ich 
nicht reingeschrieben habe. Wenn ich das Array kleiner mache, geht's. 
Wenn ich den double-Kram rausnehme, geht's.

Ich habe mir nix dazu ergoogeln können, wie der avr-gcc das mit den 
Doubles auf dem AVR hinbekommt. Daß da ein fetter Batzen Code dranhängt 
sehe ich (das Programm hat 4 KB, ohne double-Kram was um 400 Byte). Aber 
braucht der auch RAM von der Größenordnung eines halben Ks? Und wieso 
(falls das der Grund ist) zerballert er dabei meine Variablen? Das ist 
nicht nett! ;-)

Code kann ich im Moment nicht liefern, der sieht noch etwas chaotisch 
aus, aber ich habe etliche Stunden mit dem Vieh verbracht, und bin mir 
ziemlich sicher, daß in dem verbliebenen Code nix mehr begraben liegt 
(zeilenweise mit #ifdef durchgekaut...), kann ihn aber in den nächsten 
Tagen nachliefern, falls nötig.

Nur um nochmal sicher zu gehen: von dem 1 KB SRAM des Mega8 steht mir 
doch auch 1 KB zu, abzüglich Stack latürnich, oder?

Gruß, Felix

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was du da beschreibst, klingt stark nach einem Stack-Overflow.

Autor: Skasko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aloha,

hier gibts eine kleine Routine, mit der Du das prüfen kannst:

http://www.roboternetz.de/wissen/index.php/Speiche...

Autor: Zotteljedi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Routine mal ausprobiert, in einem frischen Projekt. Und 
siehe da, von 1 KB SRAM lässt sich nur die Hälfte verwenden. Das erklärt 
natürlich alles.

Allerdings frage ich mich, warum das so ist. Hier die Ausgabe:

$ avr-size -x -A mem_demo.elf
mem_demo.elf  :
section     size       addr
.text      0x10e        0x0
.data        0x0   0x800060
.bss         0x1   0x800060
.noinit      0x0   0x800061
.eeprom      0x0   0x810000
.stab      0x36c        0x0
.stabstr    0x54        0x0
Total      0x4cf

und in meinem Programm steht

--------------------------------
    free = get_mem_unused();

    if (free < 500)
        zappel();
--------------------------------

wobei zappel() mit PB0 wackelt, was ich am Oszi sehen kann. Wenn ich 
jetzt noch ein paar Variablen definiere, schlägt's zu. Wenn man also 
großzügig auf die nächste 2er-Potenz aufrundet, ergibt sich daß nur 512 
Byte RAM nutzbar sind, obwohl 1024 Byte vorhanden wären. Wozu ist das 
gut?

Gruß, Felix

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja.
Der Stack braucht ein paar Bytes.
Und für dynamische Speicherallokierung (malloc, free)
muss auch noch etwas reserviert werden.

Insgesamt hast du ja im SRAM 3 Bereiche

   +------------+---------------+--------+
   | statische  | dynamische    | Stack  |
   | Variablen  | Allokierungen |        |
   +------------+---------------+--------+

Irgendwann krachts da halt.

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

Bewertung
0 lesenswert
nicht lesenswert
Wobei 500 Byte Stackverbrauch schon auf eine, sagen wir mal
großzügige Nutzung lokaler Variablen hin deuten.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zotteljedi wrote:

> großzügig auf die nächste 2er-Potenz aufrundet, ergibt sich daß nur 512
> Byte RAM nutzbar sind, obwohl 1024 Byte vorhanden wären. Wozu ist das
> gut?

Riecht verdächtig stark nach dem bekannten "Konstanten sind per default 
im SRAM"-Problem.


Der AVR-GCC will leider für Konstanten ne extra Syntax haben, damit sie 
im Flash und nicht im SRAM landen.
Das macht auch konstante Strukturen besonders haarig (d.h. geht 
garnicht).

Bei kleineren Prohjekten lasse ich ihm daher seinen Willen und versuche 
nicht zu überschwenglich lange Texte zu schreiben.


Peter

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

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Riecht verdächtig stark nach dem bekannten "Konstanten sind per default
> im SRAM"-Problem.

Nein.  Guck dir mal die Ausgabe von avr-size an: .data ist leer.

Autor: Zotteljedi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg: beim ursprünglichen Programm liegt in der Tat viel auf dem Stack, 
aber bei dem, zu dem die avr-size-Ausgabe gehört, liegt quasi nichts 
drauf, trotzdem habe ich nur ca. 500 Byte Platz.

Quellen hängen an. In dem Zustand wird zappel() aufgerufen, wenn ich 
eine Variable wegnehme nicht mehr, das ist genau die Grenze, also ca. 
500 Byte modulo etwas Kleinkram durch die Funktionen. Von 1 KB kann da 
nicht die Rede sein...

@Karl Heinz: ich weiß, aber wenn kein malloc stattfindet, und der Stack 
"frisch" ist, können Variablen im Wert von 10 Byte auf Stack und Heap 
nicht alles bis auf 500 Byte aufmampfen. Ich fände es auch leicht 
beknackt, wenn Platz für mallocs reserviert werden würde, wenn im ganzen 
Programm kein malloc drin ist, und der Compiler das ja auch weiß.


Es ist ja nicht so, daß ich nicht einsehen wollte, daß man mit RAM 
sparsam umgehen sollte (inzwischen kommt das Zeug eh alles offline 
berechnet ins Flash rein). Nur wundere ich mich, daß ich an die Hälfte 
des ohnehin knappen RAMs nicht dran darf.

Gruß, Felix

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

Bewertung
0 lesenswert
nicht lesenswert
Umm, der war wirklich fies!  Das kostet 'n Bier, Felix.

Ich wollte das Ganze debuggen und hab's daher auf einem Controller
ausführen wollen, der debugWire kann.  Da ich gerade nur einen
ATmega48 (keinen 88) hatte, OK, dafür genügt der ja auch.  Irgendwie
wollte aber das AVaRICE bzw. der AVR Dragon nicht recht glücklich
werden.  Alles funktionierte normal bis zu diesem Hack, der da den RAM
zumüllen soll.  Danach wollte der Dragon irgendwie mit dem AVaRICE
nicht mehr reden.

Da habe ich mir das __init8_mem() mal angeguckt, auf Anhieb auch
nichts gefunden, bis ich dann irgendwie über die RAM-Adressen gestutzt
habe.  Der Stackpointer wurde auf 0x25f initialisiert, aber der RAM
bis < 0x300 beschrieben...  Ja, der ATmega48 hat wirklich seinen RAM
von 0x100 bis 0x2ff, aber warum dann 0x25f?

Da ging mir der Seifensieder auf: du hast das -mmcu beim Linken
weggelassen!

Schade, sonst habe ich sowas nicht erst nach 'ner Stunde Arbeit
gemerkt wie hier.

Übrigens gibt's keinen Grund für diesen schrägen inline-asm-Hack,
das geht in C genauso gut:
void __attribute__ ((naked, section (".init8")))
__init8_mem (void)
{
   uint8_t *cp = &__heap_start;
   do
     {
       *cp++ = MASK;
     }
   while (cp < (uint8_t *)RAMEND);
}

Der resultierende Code ist ähnlich kompakt wie das unverständliche
inline-Kauderwelsch. ;-)

p.s.: Es sind natürlich nur 3 Byte RAM in Benutzung: eins für die
Variable a am unteren Ende und zwei für die eine Ebene an
Rückkehradressen am oberen Ende des RAMs.

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.