GNU C-compiler, Atmega und Array kontrolle

Das sind zwei unterschiedliche Speicherarten, die Du verwendest:
Im ersten Fall wird statisch - also zur Compilezeit - Speicherplatz reserviert. In Deinem Fall müsste das .bss Block Storage Segment, d.h. uninitialisierter Speicher im RAM sein.
Im zweiten Fall wird der Speicher erst bei Aufruf der Funktion auf dem Stack reserviert. Das kann der Linker nur dann prüfen, wenn man ihm vorher sagt, wie groß der Stack maximal ist. Da die Variable ebenfalls nicht initialisert ist reicht es, in Assembler den Stackpointer entsprechend zu verschieben und sich nur die Anfangsadresse des Bereiches auf dem Stack zu merken. Dass das auf der Zielhardware nicht passt, kann der Compiler in dem Fall nicht wissen - und dem Linker sagt's ja niemand.

Egal wie du es drehst: Die 64*128 Bit bekommst du keinesfalls im RAM unter, auch wenn der Compiler nicht meckert! Wenn du 1kByte auf dem Stack allokierst un dein RAM ist 1k groß, dann läuft der SP einfach 1 mal rum. Mehr Platz hat dein RAM deshalb noch lange nicht...

Wie gesagt, manchmal hilft einem Brain 1.0 schneller und effektiver als Compiler x.y ;-)

Zumindest gibt's die Möglichkeit, zur Laufzeit zu reagieren. Wünschenswert wäre aber ein Fehler zur Linkzeit :-(

Code:

---

#include <avr/io.h> // RAMEND
extern char __heap_start; // from linker script

int main ()
{
        if ((uint16_t) & __heap_start > RAMEND)
                panic();
        ...
}

---

Nich das Gelbe vom Ei, aber immerhin...

Das gehl allerdings nur modulo 65535. Wenn du ein
char[65600] machst, landest du nicht in panic().

ÄÄÄHMMM

<-- NIX FRRRRSTÄÄÄN :-)

Aber wenn ichs einfach in der Mainfunktion Initialisiere gehds ja...

Was geht? Es wird compilert oder es läuft wie es soll?

Es wird vielleicht compilert. Aber es sollte nicht lauffähig sein...

Die Größe kann man auch aus dem Mapfile rauslesen lassen:

Code:

---

grep 'PROVIDE.*__heap_start' <MapFile>

---

, wobei für <MapFile> der Name des MapFiles einzutragen ist.

Das sollte dann so aussehen:

Code:

---

        0x0080814d                PROVIDE (__heap_start, .)

---

Die maximale Adresse darf
0x800060+RAMEND sein. Für einen ATmega8 also 0x80045f

Evtl. noch durch sed oder gawk pipen zum Automatisieren.

Er compiliert, und es gehd dann auch...

Aber nur, wenn es innerhalb der main-Funktion steht.

uint8_t BILDSPEICHER[8][128];


Andernseits sind ja FONTS auch als ARRAY speicherbar... das sind auch sehr sehr viele bytes. Die gehen ja auch...


EDIT: ich verwende ATMEGA8535 später dann ATMEGA32 !

Der ATmega8535 hat aber doch nicht mehr als 1k RAM, oder irre ich mich da.. Verrats doch einfach, bevor man sich das wo zusammensuchen muss in Netz oder in PDFs die man nicht hat!

Fonts sollte man nicht in's RAM legen; zumindest nicht, wenn sie nicht verändert werden.

Manno, oben das war ein Beispiel. Das auf deine Umgebung zu übertragen wirst du noch schaffen, oder?

Hier
ist ein Dattenblatt zu Mega 8535, er hat 512 Bytes RAM

Gruß Sebastian

Zitat:

---

grep 'PROVIDE.*__heap_start' <MapFile>

---

Zitat:

---

Evtl. noch durch sed oder gawk pipen

---

Sprinter, eine Frage,
Klappt das jetzt unter Dos ?
Ich dachte immer, daß so mächtige Werkzeuge nur in der Unixwelt existieren
:-k
Klär mich bitte auf :-)

Gruß Sebastian