mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM Programmgröße


Autor: newbee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag,

ich habe eine Frage zu der Programmgröße. Bislang habe ich nur 8051 
programmiert. Nun möchte ich auf ARM umsteigen/einarbeiten. Beim 8051 
kann ich mitlerweile gut abschätzen wieviel Flash Speicher ist benötige.

Kann man jetzt sagen das ein ARM im ARM-Mode ungefähr 4x mehr Speicher 
benötigt als ein 8051 (4 Byte pro Befehl) oder kann man das garnicht 
abschätzen?

Zunächst möchte ich auf einem grafischen Display (128x64) analoge Werte 
anzeigen und diese über UART verschicken. Was recht einfaches also. 
Dafür würde ich gerne ein LPC2103 nutzen mt 32KB Flash. Das sollte doch 
dicke langen oder? Gibt es irgendwelche Anhaltspunkte zum abschätzen? 
Wie groß sind eure Programme so?

thx

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ARM hat einen Grundballast, der je nach Umgebung und ob ARM oder Thumb 
zwischen 1KB und 20KB Code liegt. Letzterem Wert nähert man sich 
schnell, wenn man die GCC-newlib verwenden, also printf, malloc, ... 
Andere ARM-Umgebungen sind in dieser Frage u.U. deutlich sparsamer als 
WinARM/GnuARM/Yagarto.

Jenseits dieses Grundballasts ist der Code insbesondere im Thumb-Mode 
kaum platzraubender als bei 8bittern. RAM wird allerdings deutlich mehr 
benötigt, Faktor 2-4 bezogen auf Einzelvariablen. Irgendwelche 
Pufferspeicher sind natürlich gleich.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube die Relation zwischen 8051 und einem ARM kannst Du nur
über Deine Erfahrungswerte ermitteln. Auch je nach Programmiersprache.

Beim ARM gibt es 2 Befehlsmodi:

Thumb Befehlssatz

Und der Normale

Sie Unterscheiden sich in Ausführungsgeschwindigkeit, Befehlsumfang,
Datenbreite

Außerdem kann der ARM im Verhältnis zu 8051 versch. Operationen mit 
einem
ganz anderem Befehlsumfang erledigen.
Vergleiche man nur mal mathematische Operationen wie multiplikation oder
division, schiebebefehle etc.

Probiere es einfach aus.

Autor: newbee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke schonmal!

Ich wollte den Keil C nutzen .. klar, ab 16Bit operationen braucht der 
8051 direkt wesentlich mehr Operationen als der ARM.

Was mir jetzt nicht klar ist .. warum braucht der ARM wesentlich mehr 
RAM speicher? Wenn ich doch ein Byte als Variable haben ist die doch 
immer 8Bit groß bei ARM und 8051. Oder hat das damit nichts zu tun?

Unterscheiden sich Thumb und ARM-Mode 'nur' in Codegröße oder auch in 
Geschwindigkeit etc. voneinander ??

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
newbee wrote:

> Kann man jetzt sagen das ein ARM im ARM-Mode ungefähr 4x mehr Speicher
> benötigt als ein 8051 (4 Byte pro Befehl) oder kann man das garnicht
> abschätzen?


So etwa 4..10 mal mehr Flash dürfte hinkommen.

Der ARM ist ein RISC, d.h. alles muß über Register gehen.
Direkte Zugriffe auf SRAM und SFRs, wie beim 8051, kann er nicht.
Hinzu kommt, daß SRAM und SFRs 32Bit Adressen haben (8051: 8 Bit).

Auch wenn 32Bit-Algorithmen vielleicht etwas effizienter sind, wirkt 
sich das kaum auf die gesamte Codegröße aus, da ja Bibliotheksfunktionen 
nur einmal eingebunden werden.

Nur konstante Daten (Strings, Tabellen) sind natürlich gleich groß wie 
beim 8051.


> Dafür würde ich gerne ein LPC2103 nutzen mt 32KB Flash.

Dürfte in etwa nem AT89C51 (4kB Flash) entsprechen.


Peter

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> So etwa 4..10 mal mehr Flash dürfte hinkommen.

1KB 8051 => 10KB ARM glaube ich gern.
40KB 8051 => 160-400KB ARM wohl kaum.

Mal ein kleines Beispiel. Eine vereinfachte printf Implementierung, 
GCC/Keil.

AVR:        778 Bytes
MSP430:     488 Bytes
ARM native: 588 Bytes
ARM thumb:  322 Bytes
Keil C51:   458 Bytes

Hat hier nichts mit Algorithmen zu tun, Konvertierungsfunktionen sowie 
Library sind hier nicht mitgerechnet.

Ist natürlich nur ein Beispiel. Beliebig andere Relationen finden sich 
auch. Hängt stark davon ab, was man macht. Hat man bei den Daten 
ausschliesslich mit Bytes zu tun, bereitet der 8051 keine Probleme. 
Darüber schon.

> Direkte Zugriffe auf SRAM und SFRs, wie beim 8051, kann er nicht.

Was die SFRs angeht spielt das eine umso geringere Rolle, je grösser das 
Programm ist, da weite Teile eines grösseren Programms garnicht in 
Kontakt mit SFRs kommen. Bei RAM ist das sehr wohl ein Thema, hängt aber 
auch von der Programmiertechnik ab - beispielsweise wenn mit dem 8051 im 
Kopf ARM Code schreibt.

Autor: Urlauber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe vor 2 Jahren mal testweise ein Projekt auf verschiedene Compiler 
portiert, nur um die Codegrössen zu vergleichen.

Lief ursprünglich auf einem 51er Derivat.
Die Arm's sind dabei etwas benachteiligt, weil die meisten Parameter und 
Variablen als CHAR definiert wurden.

Bibliotheksroutinen wurden nur wenige eingebunden.

KEIL 51:      CODE      CONSTANT       DATA
--------
Dataflash.c   1447                     8
font.c                  9629
lcd.c         1323      264            390
rf.c          1295      256            18
cc1020.c      420       168
mxx.c         35775     2227           977

WIN AVR:      CODE      CONSTANT       DATA
--------
Dataflash.c   2002
font.c                  9629
lcd.c         1610
rf.c          1578
cc1020.c      594
mxx.c         44092

IAR AVR:      CODE      CONSTANT       DATA
--------
Dataflash.c   1436                     19
font.c                  9629
lcd.c         1140      264            390
rf.c          1302      256+142        25
cc1020.c      388       168
mxx.c         35570     2454+552       763

IAR THUMB:    CODE      CONSTANT       DATA
----------
Dataflash.c   1760                     30
font.c                  9669
lcd.c         1326      264            390
rf.c          1402      256            28
cc1020.c      424       184
mxx.c         38036     2433           957

IAR ARM:      CODE      CONSTANT       DATA
--------
Dataflash.c   2580                     30
font.c                  9669
lcd.c         1764      264            390
rf.c          2184      256            28
cc1020.c      656       184
mxx.c         58956     3554           1164

KEIL THUMB:   CODE      CONSTANT       DATA
-----------
Dataflash.c   2336
font.c                  9669
lcd.c         1732      264
rf.c          2320
cc1020.c      652       184
mxx.c         57812     2280

GCC THUMB:    CODE      CONSTANT       DATA
----------
Dataflash.c   8004
font.c                  9669
lcd.c         1792
rf.c          1936
cc1020.c      2088
mxx.c         51772

ARM THUMB:    CODE      CONSTANT       DATA
----------
Dataflash.c   2080
font.c
lcd.c         1372
rf.c          2400
cc1020.c      640
mxx.c         57976



Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dass ARM Code grösser ist als Thumb Code ist klar. Aber warum Daten?

Autor: Urlauber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dass ARM Code grösser ist als Thumb Code ist klar. Aber warum Daten?

Ich hab leider die Testfiles nicht mehr, aber vielleicht kann der IAR 
Compiler globale Variable im Thumb Modus anders anordnen (alignment).
Oder ich hab mich im Auswerten geirrt ;-(

Der Vergleich ist sowieso mit Vorsicht zu genießen,
da z.B. bei hauptsächlich 32Bit Variable, m.E. der ARM Compiler von ARM 
am Besten optimiert.


Hier noch ein Vergleich IAR 4.20 ARM/THUMB, maximale Optimierung:

 76 024 bytes in segment CODE
      4 bytes in segment DATA_AC
     36 bytes in segment DATA_AN
  3 497 bytes in segment DATA_C
  1 975 bytes in segment DATA_I
  1 975 bytes in segment DATA_ID
    228 bytes in segment DATA_Z
     24 bytes in segment INITTAB

 74 604 bytes of CODE  memory (+ 1 444 bytes shared)
  5 472 bytes of CONST memory (+     4 bytes shared)
  2 203 bytes of DATA  memory (+    36 bytes shared)


 56 270 bytes in segment CODE
      4 bytes in segment DATA_AC
     36 bytes in segment DATA_AN
  3 497 bytes in segment DATA_C
    519 bytes in segment DATA_I
    519 bytes in segment DATA_ID
  1 696 bytes in segment DATA_Z
     24 bytes in segment INITTAB

 54 138 bytes of CODE  memory (+ 2 156 bytes shared)
  4 016 bytes of CONST memory (+     4 bytes shared)
  2 215 bytes of DATA  memory (+    36 bytes shared)

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sieht so aus, als ob IAR bei ARM und Thumb verschiedene Backends 
(Codegeneratoren) verwendet. Bei GCC ist es das gleiche Backend für 
beide Modi.

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.