Wie groß darf ein kompiliertes Programm maximal sein

Hero_123

Mitglied
17. Sep. 2010
183
3
18
Sprachen
  1. ANSI C
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
 
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"...
 
Zuletzt bearbeitet:
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
 
Hallo LotadaC, hallo oldmax

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

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

mfg

Hero_123
 
Hallo oldmax

Hab's gefunden ;)
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)