Wie groß darf ein kompiliertes Programm maximal sein

[Hero_123]

Hallo!

Ich habe da mal eine Frage - wie groß darf /sollte ein kompiliertes Programm maximal sein?

Größe meines Programm (Prozessor ATMega8 mit 3.684 MHz) kompiliert mit AVRStudio 4.18 und avr-gcc version 4.3.3 (WinAVR 20100110):

Program: 5822 bytes (71.1% full) (.text + .data + .bootloader)
Data: 349 bytes (34.1% Full) (.data + .noinit )

Ein Bootloader ist nicht implementiert.

Es kommen noch ein paar weitere Funktionen bzw Variable hinzu, so dass die Größe mein Programmes (kompiliert) wahrscheinlich beträgt
Programm: 6550 bytes (80% Full)
Data: 512 bytes (50% Full)

Kann bzw werde ich Probleme bei der Ausführung bekommen, wenn ich die 80% bzw 50% überschreite? Was ist mit dem heap und dem stack?
Oder sollte ich schon jetzt auf einen ATMega168 bzw 328 umsteigen?
Kann man messen /ermitteln, wann die Größe eines Programmes dazu führen kann, dass es Probleme bei der Ausführung gibt (nicht die "Try & Error Methode" - "lass mal laufen und guck, wann der Prozessor abschmiert")?

Vielen Dank!

mfg

Hero_123

 

[LotadaC]

Die AVR sind in Harvard-Architektur aufgebaut, d.h. der Programmspeicher ist getrennt vom "Arbeitsspeicher".

Der Program Flash des ATmega8 hat 8kB (4 kWords).
Im Flash können neben dem reinen Programmcode auch Konstanten abgelegt sein, die sich (normalerweise (*)) zur Laufzeit nicht mehr ändern, und in den oben angegebenen 5822bytes 71.1% bereits enthalten sind.

Was Du mit Heap meinst, ist mir nicht klar - der (Hardware-)Stack wird üblicherweise am Ende des SRAM (beim Mega8 1kByte) angelegt. Im SRAM werden normalerweise alle Variablen und der Stack (und ggf weitere Verwaltungs-stacks der verwendeten Hochsprache) abgelegt. Da diese der Dynamik des Programmes zur Laufzeit unterliegen, kann die IDE beim kompilieren nicht wirklich abschätzen, inwiefern der SRAM "überlastet" wird.

Zumindest bei Bascom kann man beim Simulieren einsehen, welche SRAM-Bereiche durch welche Variablen belegt werden, außerdem kann man den SRAM mit festgelegten Werten Initialisieren lassen - dann sieht man während des simulierten Durchlaufes, wo der SRAM überschrieben wird, und wo's ggf eng werden könnte. Leider läßt sich komplexere Hardware oft nicht simulieren...

Inwiefern sowas mit "C" auch geht, weiß ich nicht - zumindest den Stackpointer kannst Du überwachen. Auch das initialisieren des SRAM mit definierten Werten kannst Du selbst erledigen - der Simulation sind natürlich ähnliche Grenzen gesetzt.

(*) streng genommen kannst Du natürlich ähnlich einem Bootloader auch Pages im Flash zur Laufzeit neu schreiben lassen - SPM (Store Program Memory) ist ja nicht zwingend an einen Bootloader gebunden, aber sowas wäre schon "speziell"...

 

[oldmax]

Hi
Nun, ein Programm in einem Controller darf den vollen Speicherbereich vom CSeg in Anspruch nehmen. Da verändert sich zur Laufzeit sowieso nix mehr. Wär auch schlimm, denn im CSeg befindet sich ein Speicher, der sich mit jedem Schreibzugriff etwas zerstört. Rd. 10 000 Mal wird es aber garantiert, bevor Speicherzellendefekte aufweisen können. Allerdings sind in einem mit mindestens 1MHz Takt befeuerten Controller 10 000 Schreibzyklen u.U. in ein paar Sekunden erledigt.

Anders m DSeg, Das ist der flüchtge Speicher mit unbegrenzten Schreibzyklen.Da wird ein Teil vom Stack beansprucht und das ist abhängig u.a. von der Programmiersprache und auch von der Programmstruktur. Das im Einzelnen aufzudröseln ist aber sehr aufwändig. Auch wenn es in meinem Buch hier in der Rubrik FAQ nicht um deine Programmiersprache geht, solltest du Mal hinein lesen. Da hab ich auch etwas zu Laufzeiten, bzw. Zykluszeiten geschrieben und das ist für einen ordentlichen Ablauf im Programm nicht unerheblich.
Gruß oldmax

 

[Hero_123]

Hallo LotadaC, hallo oldmax

@LotadaC - Ich komme erst jetzt dazu, mich für Deine Antwort zu bedanken, da mein Internet erst jetzt wieder funktioniert

@oldmax - vielen Dank für Deine Antwort - wo finde ich Dein Buch?

mfg

Hero_123

 

[Hero_123]

Hallo oldmax

Hab's gefunden