mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR vs. ARM


Autor: Tobi A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich hatte momentan mal mit dem Gedanken gespielt von den AVRs weg zu
was schnellerem zu wechseln.
Die ARMs schenen mit da eine nette alternative zu sein. Wenn ich mir so
ARM7 oder so anschaue können die bis 60 MHz (wenn ich das recht im
Hinterkopf habe).
Wie siehts denn so mit MIPS aus? Ich meine im mittel verglichen mit nem
AVR? Is klar das das von der rechenoperation abhängt aber trotzem, wenn
ihr mal so ne Hausnummer werden müsstet, wieviel würdet Ihr sagen ist
der ARM schneller als der AVR.

Grüsse

  Tobi

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo hapert es denn an den AVRs ?

Für Steuerungsaufgaben sind die doch weit mehr als schnell genug.

Meistens wird CPU-Zeit durch eine schlechte Programmablaufplanung
vernichtet. D.h. ein besserer Programmablauf kann oftmals mehr
beschleunigen, als eine 10-mal schnellere CPU.


Die ARMs spielen in einer völlig anderen Liga. Die haben erst dann
Vorteile, wenn man rechnet wie blöd, z.B. Grafikanimationen, schnelle
Verschlüsselungsalgorithmen, FFT usw.
Oder wenn man Multitaskingsysteme drauf installieren will, die ja
haufenweise CPU-Zeit für den Taskwechsel verbrauchen.
Oder wenn man sehr viel SRAM schnell ansprechen will (>64kB).

Aber bezogen auf IO-Operationen ist ein ARM kaum schneller als ein
AVR.


Peter

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo's bei den AVRs hapert? Na z.B. an Verarbeitungsleistung wenn man
etwas mehr haben moechte, wie erwaehnt von Tobi.
Ich geb Peter vollstaendig recht, die ARMs spielen in einer voellig
anderen Liga, allerdings sind vergleichbare Speichergroessen auch
aehnlich im Preis. Von daher, wenn ich einen Baustein aus einer voellig
anderen Liga zum selben Preis erhalte, warum nicht?
Den LPC2131 gibt es bereits ab 1 Stueck bei Digikey Deutschland fuer
4.9, ein ATMEGA 32 ist dort soweit ich gesehen habe fuer Einzelstueck
ueber 6 Euro.

In Kuerze gibt es noch den LPC2103, der schon bei Digikey gelistet ist
fuer 3.79 Einzelstueck, 2.36 bei 10 Stk.
Der hat 32k Flash, 8K SRAM, laueft 70MHz from Flash...  was will man
mehr in Punkto Leistung.

Also wenn ich ein vielfaches an Leistung fuer denselben oder gar
niedrigeren Preis bekomme, warum sollte ich dann um alles in der Welt
immer noch am AVR festhalten.

Sollte das Preis / Leistungsverhaeltnis von AVR natuerlich deutlich
verbessert werden, z.B. indem der Preis halbiert wuerde, dann waere die
Diskussion offen, solange es allerdings ARMs fuer weniger gibt als
vergleichbare AVRs kann ich nur annehmen, dass die AVRs ueberteuert
sind.

Im uebrigen halte ich den AVR fuer eine sehr gute 8-bit architektur,
doch das reicht einfach nicht mehr aus in vielen Dingen, wenn ich einen
32-bit Rechner bekommen kann (sogar von mehreren Anbietern).

Robert, von Philips aber auch sonst ein ueberzeugter ARM-ist ;-)

Autor: mkmk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine kleine Zwischenfrage:
32kB Flash beim AVR entsprechen ca. 16.000 Instruktionen.
Der ARM ist ein 32bit'er. D.h. 8.000 Instruktionen? Ist das richtig
so?

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grundsätzlich schon richtig, dieses Speichergrösse/AnzahlInstruktionen
Verhältnis sagt aber nicht viel aus. Die Befehle beim 32 Bit ARM
Befehlssatz sind einiges leistungsfähiger. Z.B. haben die meisten von
ihnen 3 Operanden (2 Quelloperanden, 1 Zieloperand), wodurch reine
Transferoperationen eher selten benötigt werden.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kommt eben immer darauf an, welche Aufgabe man lösen muss.

Wenn man mit einem AVR z.B. mit 16-Bit- oder 32-Bit-Zahlen rechnen
muss, das schluckt richtig Codegröße.

Beim ARM hingegen kann man Codegröße gegen Ausführungsgeschwindigkeit
tauschen. D.h. man kann ihn auch im Thumb-Mode betreiben, dann ist
jeder Op-Code nur 16 Bits breit, dafür hat man einen kleineren
Befehlssatz und braucht eben ab und zu mehr Anweisungen weil man nicht
mehr ganz so flexibel ist.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibts für ARM auch n Basic Compiler?

Autor: Marillion (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wichtige  Frage: Wie sieht eine prof. Entwicklungsumgebung für ARM aus?
Ist Keil die einzigste Alternative?
Gibt es kostengünstige JTAG-Emulatoren?

Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da gibts noch die iar embedded workbench for arm. auf www.iar.com
kannste dir ne 30-tage-demoversion downloaden. und mit den eval-boards
(z.zt. bei spoerle für nur 209 öre zu haben) wird eine
kickstart-version mitgeliefert (begrenzt auf 32k c-code).

Autor: Tobi A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich hatte vor so Spaesse wie eventuell bisschen Bildverarbeitung oder
so was drauf laufen zu lassen. Da war mir der AVR ETWAS zu langsam.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
www.rowley.co.uk stellt mit Crossworks for ARM die AFAIK einzige
Entwicklungsumgebung zur Verfügung, die unter den ernstgemeinten
Windows-Versionen auch anständig mit dem billigsten aller
JTAG-Interfaces, dem "Wiggler", zurecht kommt.
Leider kostet CWARM etwa 500 UKP (750 EUR).

Unter den Frickelbastel-Windows-Versionen scheint auch OCD Remote/OCD
Commander zu funktionieren, so daß da auch IAR EWARM und natürlich
gnuarm mit gdb zusammen mit einem "Wiggler" eingesetzt werden
können.

Alternativ besorgt man sich einen USB-JTAG-Adapter, dann ist man das
eine oder andere Problem los.

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also wenn ich ein vielfaches an Leistung fuer denselben oder gar
>niedrigeren Preis bekomme, warum sollte ich dann um alles in der Welt
>immer noch am AVR festhalten.

Wie sieht es denn beim Stromverbrauch aus?

Ist die alte 5V Technologie (0.35µ oder groesser) der AVR's den
neueren Technologien der ARM's (z.B. 1.8V d.h. mind. 180nm)
unterlegen?

Kennt jemand Zahlen?

Autor: SeppKnallhirsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie sieht es denn beim Stromverbrauch aus?

>Kennt jemand Zahlen?

Ja, zumindest für den AT91SAM7s:

Alles aktiv: ca. 30mA
Low Power:   ca  4µA

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mal Tests mit realen Berechnungen (ca. 50 Zeilen in C) gemacht,
alles floating Point (Wurzeln, Divisionen), dabei war der ARM  Faktor 8
 schneller (LPC2106).
Bei floating-Point Divisionen ist er Faktor 20 schneller.

I/O ist er langsamer als ein AVR.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<< dabei war der ARM  Faktor 8 schneller (LPC2106).

Das bedeutet, der ARM macht eine float-mul in ca. 3-4 µs ?

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Division.

Autor: Tobi A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso bei I/O langsamer?
Braucht man so viele operationen bis man mal ein bloedes
ausgangsregister gesetzt hat?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fritz

Gut, Divisionen. Faktor 8 oder Faktor 20 ? Oder freie Auswahl ?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wieso bei I/O langsamer?"

Weil, wie gelegentlich schon erwähnt wurde, manche LPC2000 Varianten
einen eher langsamen Peripheriebus haben.

Autor: André Freitag (ratatatata)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kennt einer einen guten online-shop der aus der eu versendet (kein zoll/
relativ geringe versandkosten) und der ein großes angebot an arms hat?

wollte mir die arms nur mal anschauen und da sind mir 18€ von digikey
für einen controller ein bisschen zu hoch, 6x so hoch wie der
eigentliche artikel ^^

andré

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@andre
nimm lieber ein Board von www.embeddedartists.com anstelle von einem
Chip.

@FritzG
mit der Division hast Du den absolut langsamsten Teil fuer einen ARM
erwischt, teste mal die Float Mul ;-)
Ausserdem wird der Unterschied noch viel grasser falls hoehere
Aufloesung fuer die Floating Point gewuenscht wird.

Der LPC2106 braucht tatsaechlich 16 CPU Takte um einen Pin hin und her
zu schalten, d.h. die max. Ausgangsfrequenz ist 3.75 MHz.
Die neuesten Varianten, LPC214x uns LPC2101/2102/2103 koennen jetzt die
Pins alle 2 takte umschalten, d.h. es braucht 4 Takte um einmal hin- und
herzuschalten.
Soweit ich weiss kann der AVR mit einem Befehlstakt den Pin umschalten,
also kann ein 16 MHz AVR einen 8 MHz Takt erzeigen. Die effizienz beim
AVR ist immer noch besser aber der absolute Takt ist jetzt beim ARM
auch schneller.
Diese Aenderung wird nachtraeglich auch in die aelteren LPCs, z.B.
LPC2106 eingebaut, die Teile sollte es im 2. Quartal geben.

@Superuser
Stromwerte fuer die meisten LPC2000;
Code vom internen Flash bei 60 MHz im ARM mode ca. 30-35 mAs (das ist
effectiv um ca. 40% schneller als die 55 MHz im Thumb mode, die andere
Hersteller bieten).
Bei 10 MHz ohne PLL ca 8 mAs,
bei 1 MHz ca 850 uAs aber bei 1 MHz funktioniert die PLL nicht mehr.
Also koennte man den Chip z.B. mit 12 MHz takten, waere dann bei
Berechnungen immer noch schneller mit Algorithmen als ein AVR und falls
noetig die PLL zuschalten und einen Faktor 5 erhalten.

Autor: Kai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Marillion:

Die 32k Kickstart Version der Embedded Workbench für ARM
gibts auch kostenlos bei IAR zum download. Allerdings muss
man sich vorher registrieren lassen.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich finde manche Argumente etwas schwacht.
Z.B. besserer Programmablauf kann oftmals mehr beschleunigen, als eine
10-mal schnellere CPU.
Natürlich ist das richtig, aber warum soll man nicht trotzdem mehr
Reserven im Hintergrund haben, noch dazu wenn dass Produkt vom Preis
her gleich oder billiger ist?

Wenn man ein Auto kauft und man würde einen Mercedes einer höheren
Klasse um dasselbe Geld oder billiger kaufen können als einen billigen
Wagen einer unteren Klasse, was würdet ihr nehmen, wenn man die höheren
Erhaltungskosten des Mercedes mal beiseite nimmt?
Hier würde man auch nicht sagen: "Oh, ich nehme lieber den Billigeren,
denn in der Stadt darf ich sowieso nicht schneller als 50 fahren oder
auch auf der Autobahn reicht der Billige loker aus." Darum verstehe
ich hier die Denkweise nicht. Ich habe immer das Gefühl, dass viele
Leute den Umstieg scheuen und wenn dann solche Argumente kommen wie -
Der Prozessor spielt in einer anderen Liega, dann glauben viele, dass
der Prozessor ungleich komplizierter sein muss, was meiner Meinung nach
nicht der Fall ist. Ich finde dass der ARM nicht komplizierter ist als
der AVR. Der ARM hat zwar mehr Einheiten auf dem Chip z.B.
(PLL-Einheit), aber die kann man sich mal zu Gemüte führen, wenn man
die ersten Gehversuche erfolgreich abgeschlossen hat. Jede Einheit ist
meiner Meinung nach sehr logisch aufgebaut.

Bei meinen Projektentwicklungen hat sich ein leistungsfähigerer
Prozessor in den meiseten Fällen als sehr sinnvoll herausgestellt, da
im Nachhinein vom Kunden immer wieder Wünsche kamen, die dann nur mit
besseren Prozessoren zu bewältigen waren und wenn dieser Prozessor
schon drin ist, umso besser. In diesem Fall wäre es dumm, sich auf das
Pflichtenheft zu berufen und dem Kunden klar zu machen, dass die
Wunschliste schon abgeschlossen ist. Dies würde nur zu Veräergerungen
führen und die Auftragslage würde sich verschlechtern.

Auch wenn man noch etwas Flash-Reserve hat ist das eine gute Sache. Ich
finde es nicht gut, wenn man nach allen Regeln der Kunst programmieren
muss, nur damit sich das Programm gerade noch ausgeht, weil es nicht
notwendig ist.

Ich bin vor Kurzem vom AVR auf den ARM-LPC2138 von Philips umgestiegen
und bin sehr zufrieden. Natürlich hat ein anderer Prozessor nicht nur
Vorteile, aber die Vorteile des ARM überwiegen eindeutig.

Tschüss

Martin

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob die Vorteile überwiegen, hängt davon ab, was man will. Zwei Dinge
würde ich gerne hinzufügen, bei denen der AVR punkten kann:

1. Aufgaben mit exaktem Timing: ob man ein PAL-Signal erzeugen oder die
Softwareemulation eines Busprotokolls implementiert, muß man immer
taktgenaue Assemblerroutinen schreiben. Mein Beileid an denjenigen, der
das beim ARM machen muß ...

2. Die Breite der Produktpalette: ich habe hier z.B. Anwendungen vom
tiny13 bis zum mega128, die denselben Code für die Displayansteuerung
verwenden. Ob ich eben ein Prüfgerät mit einem DIL auf Lochraster
zusammenfrickel oder eine winzige Serienplatine mit einem achtbeinigen
Fliegenschiß -- ich bleibe auf derselben Architektur. Und darum ist in
der Top-Anwendung auch der mega128, auch wenn da ein kleiner ARM
billiger und leistungsfähiger gewesen wäre.

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Martin,

"Natürlich ist das richtig, aber warum soll man nicht trotzdem mehr
Reserven im Hintergrund haben, noch dazu wenn dass Produkt vom Preis
her gleich oder billiger ist?"


Du hast nicht verstanden, was ich sagen wollte:

Um mal bei Deinem Beispiel zu bleiben, mit der falschen Routenplanung,
z.B. von Berlin nach Hamburg über München bin ich auch mit dem
schnellsten PKW langsamer, als wenn ich direkt Berlin - Hamburg fahre.

Die Programmplanung hat in der Regel den wesentlich größeren Einfluß,
als die MIPS-Zahl der CPU.

Wer stur auf die MIPS schaut, kann nur enttäuscht werden.

Und der Preisvergleich stimmt auch nur für die CPU. Aber ein AVR auf 1
Layer oder ein ARM auf 4 Layer macht schon einen erheblichen
Preisunterschied.


Peter

Autor: Ppp Mmm (sanic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ARM auf 4 Layern ? Wofür das denn bitte ?

Grüße

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, hab mal den Benchmark rausgesucht, war schon etwas länger her:

/*
Atmel:

Rechentest mit 1000000 Durchläufen...
Ergebnis: 41956652
Dauer: 44.27 Sekunden, 44.270 µs

ARM:
Rechentest mit 1000000 Durchläufen...
Ergebnis: 41956652
Dauer: 3.80 Sekunden, 3.795 µs

Faktor: 11.6
Nur Multiplikation: Faktor 20.2
*/

static void
rechentest (int count)
{
  int i, a, b, c;
  uint32_t startTime;
  char str[80];

  sprintf (str, "Rechentest mit %d Durchläufen...\n", count);
  uart0Puts (str);
  startTime = getSysTICs ();
  a = 2341;
  b = 3241;
  c = 17;

  for (i = 0; i < count; i++)
  {
    // IOSET = LED1_BIT;
    a = a * b / c;
    // IOCLR = LED1_BIT;
  }
  i = getSysTICs () - startTime;
  sprintf (str, "Ergebnis: %d\nDauer: %.2f Sekunden, %.3f µs\n\n",
a,
     (double) i / sysTICSperSEC, ((double) i * 1000000.0 / sysTICSperSEC)
/ count);
  uart0Puts (str);

}


/*
Atmel:

Kreisschnitt 20000x mode 0...
x: 3.439, y: 1.801
 Dauer 16.500sek. Zeit: 825.000µs
 
 
Kreisschnitt mode 1...
x: 1.705, y: 3.728
 Dauer 16.520sek. Zeit: 826.000µs

ARM:

 Kreisschnitt 20000x mode 0...
x: 3.439, y: 1.801
 Dauer 2.084sek. Zeit: 104.201µs
 
 
Kreisschnitt mode 1...x: 1.705, y: 3.728
 Dauer 2.084sek. Zeit: 104.217µs
 
 
 mit calc_kreisschnitt als inline:
 =================================
 Kreisschnitt 20000x mode 0...
x: 3.439, y: 1.801
 Dauer 1.731sek. Zeit: 86.568µs
 
 
Kreisschnitt mode 1...
x: 1.705, y: 3.728
 Dauer 1.769sek. Zeit: 88.449µs
 

*/

char
calc_kreisschnitt_arm (float x1, float my1, float r1, float x2, float
my2, float r2, char mode, float *x, float *y)
{
  float a1, b1, d, d1, t, u;
  int8_t s3;
  float tol = 0.001;

  if (mode == 0)
    s3 = 1;
  else
    s3 = -1;


  a1 = x2 - x1;
  b1 = my2 - my1;
  d = sqrt (a1 * a1 + b1 * b1);
  if (d <= 1.0)
    return FALSE;
  d1 = ((x2 + x1) * a1 + (my2 + my1) * b1 - (r2 + r1) * (r2 - r1)) /
(2.0 * d);
  a1 = a1 / d;
  b1 = b1 / d;
  t = d1 - x2 * a1 - my2 * b1;
  u = r2;
  d = (u - t) * (u + t);
  if (d < -tol)
    return FALSE;

  if (d < 0.0)
    d = 0.0;
  d = s3 * sqrt (d);
  *x = x2 + a1 * t + b1 * d;
  *y = my2 + b1 * t - a1 * d;

  return TRUE;
}




Autor: mmerten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese ganze Diskussion AVR vs ARM ist doch recht müßig. Beide Familien
haben ihren Einsatzbereich und sind auch nicht direkt miteinander
vergleichbar. Der eine rechnet zwar schneller, ist aber im Bereich I/O
und der zur Verfügung stehenden Treiberleistung doch arg im Nachteil.
Auch sagt der reine Controllerpreis noch nichts über die Gesamtkosten
aus. Zusätzliche Treiber, externe Beschaltung und auwendigere
Leiterplatte machen da manchen Vorteil sehr schnell zu nichte. "Den
Controller", der für jede Anwendung optimal paßt gibt es einfach
nicht.

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Vorteil vom AVR ist, dass er einen echten Power-Down-Modus hat
(< 5uA).
Die ARMs, die ich kenne, verbrauchen mindestens das 10fache.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fritz

Ich kann Deine Angaben für 'rechentest()' bestätigen; mein ATmega mit
16MHZ braucht 45,5µs.
Zum Vergleich habe ich diesen Test auch auf einem H8S2394 mit 20MHz
laufen lassen 12µs bei 16Bit Datenbus und 17,6µs bei 8Bit Datenbus.

Für den Kreisschnitt fehlen mir die Parameter, aber da würde ich Deinem
Angaben vertrauen.
Insgesamt sieht das Ergebnis vom ARM recht gut aus !

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.