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
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
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 ;-)
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?
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.
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.
Wichtige Frage: Wie sieht eine prof. Entwicklungsumgebung für ARM aus? Ist Keil die einzigste Alternative? Gibt es kostengünstige JTAG-Emulatoren?
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).
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.
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.
>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?
>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
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.
<< dabei war der ARM Faktor 8 schneller (LPC2106). Das bedeutet, der ARM macht eine float-mul in ca. 3-4 µs ?
Wieso bei I/O langsamer? Braucht man so viele operationen bis man mal ein bloedes ausgangsregister gesetzt hat?
"Wieso bei I/O langsamer?" Weil, wie gelegentlich schon erwähnt wurde, manche LPC2000 Varianten einen eher langsamen Peripheriebus haben.
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é
@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.
@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.
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
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.
@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
So, hab mal den Benchmark rausgesucht, war schon etwas länger her:
1 | /*
|
2 | Atmel:
|
3 | |
4 | Rechentest mit 1000000 Durchläufen...
|
5 | Ergebnis: 41956652
|
6 | Dauer: 44.27 Sekunden, 44.270 µs
|
7 | |
8 | ARM:
|
9 | Rechentest mit 1000000 Durchläufen...
|
10 | Ergebnis: 41956652
|
11 | Dauer: 3.80 Sekunden, 3.795 µs
|
12 | |
13 | Faktor: 11.6
|
14 | Nur Multiplikation: Faktor 20.2
|
15 | */
|
16 | |
17 | static void |
18 | rechentest (int count) |
19 | {
|
20 | int i, a, b, c; |
21 | uint32_t startTime; |
22 | char str[80]; |
23 | |
24 | sprintf (str, "Rechentest mit %d Durchläufen...\n", count); |
25 | uart0Puts (str); |
26 | startTime = getSysTICs (); |
27 | a = 2341; |
28 | b = 3241; |
29 | c = 17; |
30 | |
31 | for (i = 0; i < count; i++) |
32 | {
|
33 | // IOSET = LED1_BIT;
|
34 | a = a * b / c; |
35 | // IOCLR = LED1_BIT;
|
36 | }
|
37 | i = getSysTICs () - startTime; |
38 | sprintf (str, "Ergebnis: %d\nDauer: %.2f Sekunden, %.3f µs\n\n", |
39 | a, |
40 | (double) i / sysTICSperSEC, ((double) i * 1000000.0 / sysTICSperSEC) |
41 | / count); |
42 | uart0Puts (str); |
43 | |
44 | }
|
45 | |
46 | |
47 | /*
|
48 | Atmel:
|
49 | |
50 | Kreisschnitt 20000x mode 0...
|
51 | x: 3.439, y: 1.801
|
52 | Dauer 16.500sek. Zeit: 825.000µs
|
53 |
|
54 |
|
55 | Kreisschnitt mode 1...
|
56 | x: 1.705, y: 3.728
|
57 | Dauer 16.520sek. Zeit: 826.000µs
|
58 | |
59 | ARM:
|
60 | |
61 | Kreisschnitt 20000x mode 0...
|
62 | x: 3.439, y: 1.801
|
63 | Dauer 2.084sek. Zeit: 104.201µs
|
64 |
|
65 |
|
66 | Kreisschnitt mode 1...x: 1.705, y: 3.728
|
67 | Dauer 2.084sek. Zeit: 104.217µs
|
68 |
|
69 |
|
70 | mit calc_kreisschnitt als inline:
|
71 | =================================
|
72 | Kreisschnitt 20000x mode 0...
|
73 | x: 3.439, y: 1.801
|
74 | Dauer 1.731sek. Zeit: 86.568µs
|
75 |
|
76 |
|
77 | Kreisschnitt mode 1...
|
78 | x: 1.705, y: 3.728
|
79 | Dauer 1.769sek. Zeit: 88.449µs
|
80 |
|
81 | |
82 | */
|
83 | |
84 | char
|
85 | calc_kreisschnitt_arm (float x1, float my1, float r1, float x2, float |
86 | my2, float r2, char mode, float *x, float *y) |
87 | {
|
88 | float a1, b1, d, d1, t, u; |
89 | int8_t s3; |
90 | float tol = 0.001; |
91 | |
92 | if (mode == 0) |
93 | s3 = 1; |
94 | else
|
95 | s3 = -1; |
96 | |
97 | |
98 | a1 = x2 - x1; |
99 | b1 = my2 - my1; |
100 | d = sqrt (a1 * a1 + b1 * b1); |
101 | if (d <= 1.0) |
102 | return FALSE; |
103 | d1 = ((x2 + x1) * a1 + (my2 + my1) * b1 - (r2 + r1) * (r2 - r1)) / |
104 | (2.0 * d); |
105 | a1 = a1 / d; |
106 | b1 = b1 / d; |
107 | t = d1 - x2 * a1 - my2 * b1; |
108 | u = r2; |
109 | d = (u - t) * (u + t); |
110 | if (d < -tol) |
111 | return FALSE; |
112 | |
113 | if (d < 0.0) |
114 | d = 0.0; |
115 | d = s3 * sqrt (d); |
116 | *x = x2 + a1 * t + b1 * d; |
117 | *y = my2 + b1 * t - a1 * d; |
118 | |
119 | return TRUE; |
120 | }
|
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.
Der Vorteil vom AVR ist, dass er einen echten Power-Down-Modus hat (< 5uA). Die ARMs, die ich kenne, verbrauchen mindestens das 10fache.
@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 !
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.