mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR vs ARM Lohnt ein Umsteigen


Autor: Delay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo lieben Member,

ich bin zur Zeit sehr mit der Materie uC beschäftigt und benutze zur 
Zeit den Mega8 und programmiere diesen in C++.
Was könnten gute Gründe sein, um von den AVRs auf ARM umzusteigen??? 
Werden die anders programmiert? Sind einfacher in der handhabung? 
Leichter oder schwerer aufzubauende Grundbeschaltung? Befehlssatz, 
Fähigkeiten?  Programmierbarkeit in C++ wie die AVRs? Schnittstellen 
(auch zum Prrgammieren?) Sind die Features wie ADC, UART, TIMER, 
SLEEPFunktionen etc auch bei den ARMs enthalten?

Würde mich über jede Antwort freuen
Delay

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Delay wrote:
> Hallo lieben Member,
>
> ich bin zur Zeit sehr mit der Materie uC beschäftigt und benutze zur
> Zeit den Mega8 und programmiere diesen in C++.
> Was könnten gute Gründe sein, um von den AVRs auf ARM umzusteigen???

Die Gruende koennten sein dass man Projekte entwickelt die so 
umfangreich sind dass ein AVR nicht mehr ausreicht. Aber wenn Du schon 
so fragst wuerde ich sagen dass Du dort lange noch nicht bist -- ich 
uebrigens auch nicht. Ich denke auch dass fuer meine Zwecke 
wahrscheinlich selbst der kommende XMega schon kaum mehr auszureizen 
sein wird.

Komplexere Architektur bringt natuerlich auch mehr Aufwand in Aufbau und 
Programmierung mit sich, das ist klar, was?

Gruss,
Michael

Autor: sadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ARM's sind 16 oder/und 32 Bit Prozessoren. Wenn du viel mit 32 Bit 
zahlen anstellen musst und das in einer kürzesten Zeit, würde ich zum 
ARM greifen, um über USART 2 Byte/h zu übertragen, reicht auch ein 
Atmega. Wenn du basteln willst ist ein Atmega in der DIP Ausführung auch 
um einiges leichter zu handhaben. Vom Preis her sind die ARMs nicht 
teurer als größere Atmegas wie Atmega128,Atmega2561 etc. Wie gesagt, es 
kommt drauf an, was man machen möchte.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Delay (Gast)

>ich bin zur Zeit sehr mit der Materie uC beschäftigt und benutze zur
>Zeit den Mega8 und programmiere diesen in C++.

C++? Wohl eher C. C++ ist wenig sinnvoll auf einem AVR.

>Was könnten gute Gründe sein, um von den AVRs auf ARM umzusteigen???

Mehr Speicher, höherer Takt, mehr Datenurchsatz, mehr Pins, mehr 
Schnittstellen . . .

>Werden die anders programmiert?

Prinzipiell nicht.

> Sind einfacher in der handhabung?

Nein. Aber auch nicht extrem schwerer.

>Leichter oder schwerer aufzubauende Grundbeschaltung?

Ähnlich.

[8Entwicklungsboard mit AT91SAM7Sxxx - selbstgemacht]]

> Befehlssatz,
>Fähigkeiten?

Mehr.

>  Programmierbarkeit in C++ wie die AVRs?

Mehr.

>(auch zum Prrgammieren?) Sind die Features wie ADC, UART, TIMER,
>SLEEPFunktionen etc auch bei den ARMs enthalten?

Logisch!

MfG
Falk

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man AVRs gewohnt ist und mehr Performance braucht, ist der kommende 
XMega in der Tat eine Alternative, bevor man die Plattform komplett 
wechselt.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Haken an den ARMs ist der Einstieg, besonders wenn man von AVR 
gewohnt ist nichts für Software zahlen zu müssen. WinARM/Yagarto ist ein 
prima Paket, aber mancher braucht für das Verständnis von Startup-Code 
und Linkerscripten länger als ihm lieb ist. Bei AVR entfällt das, bei 
ARM nur im Rahmen kommerzieller Umgebungen.

Für sparsamen Batteriebetrieb sind ARMs übrigens nicht wirklich 
geschaffen. Klar gibt es Sleep-Modi, aber zwischen AVR und den diversen 
ARM-Familien klaffen in der Hinsicht Welten. Zumal die durchweg 
mindestens saubere 3,3V haben wollen, also ohne Regler wie bei AVRs 
möglich geht nichts.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sadi wrote:

> ARM's sind 16 oder/und 32 Bit Prozessoren.

Ein 16bit ARM ist mir noch nicht begegnet. Wenn du Thumb damit meinst - 
ein 32bit Prozessor mit 16bit Codebreite bleibt ein 32bit Prozessor. 
AVRs sind ja auch nicht 16bittig und die PIC16 nicht 14bittig.

Neben der breiteren Datenverarbeitung spielt auch die Adressierfähigkeit 
eine wichtige Rolle. Mehr als 60KB Daten zu verarbeiten - egal ob in RAM 
oder ROM - wird bei AVRs umständlich, die XMegas eingeschlossen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der XMega mag auch nur noch maximal 3.6V, läuft aber auch schon ab 1.7V.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>C++? Wohl eher C. C++ ist wenig sinnvoll auf einem AVR.

Woher kommt nur dieser Schmarrn ?
Durch Verwendung von C++ spare ich viel Zeit und erhalte deutlich 
kompakteren und übersichtlicheren Code. Auch die 
Codewiederverwendbarkeit wird deutlich erhöht. So habe ich u.a. eine 
einfache Scheduler-Klasse, von der ich meine einzelnen "Tasks" ableite. 
Im Handumdrehen ist ein solcher erzeugt / hinzugefügt. Bei "etwas 
größeren" Sachen (z.B. Mega16 mit LCD und Tastatur) kann man mit einem 
objektorientiertem Ansatz sehr kompakt die Menüführung implementieren. 
Die Praxis zeigt dass sich so sogar noch etwas Flash sparen lässt, was 
allerdings (geringfügig) etwas zu Lasten der RAM geht.

Stefan

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... sparsamen Batteriebetrieb sind ARMs übrigens nicht wirklich
geschaffen ...

Dies ist ein Wischi-Waschi 'nicht wirklich' Satz. Und großer Quatsch!

Autor: Anglizissmenübersetzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"nicht wirklich" -> "eigentlich nicht"

"Performance" -> "Effizienz", "Durchsatz"

Wenn ich schon beim Thema bin, der Oberknaller neulich war "thermaler 
Stress". Aua. Aber nun genug "Offtopic" -> "abseits des Themas".

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald wrote:

> Und großer Quatsch!

ATMega644P Power-Save mit RTC Osc: 0.6µA
LPC2368 Äquivalent dazu: I(Bat) 28µA, I(3,3V) 150µA.
LM3S611 alles abgeschaltet im Deep Sleep: ~1mA.

Natürlich kann man das auch mit Batterie machen. Wirklich sparsam ist 
das jedoch nicht. Es mag aber bessere Typen geben.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anglizissmenübersetzer wrote:

> Wenn ich schon beim Thema bin, der Oberknaller neulich war "thermaler
> Stress".

Kette dich mal an einem gut befeuerten Ofen fest - dann weisst du was 
thermaler Stress ist. ;-) Und wenn du solche Töne spuckst, solltest du 
wenigstens den Anglizismus richtig schreiben.

Autor: Anglizismenübersetzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Kette dich mal an einem gut befeuerten Ofen fest
...aber das wäre doch dann "thermischer Stress", nicht "thermaler 
Stress" :-)

>Und wenn du solche Töne spuckst, solltest du wenigstens den Anglizismus
Was haben nun sinnlose und schmerzhafte Anglizismen mit der deutschen 
Rechtschreibung zu tun ? Das sind zwei verschiedene Themen. Ich habe 
weder behauptet die deutsche Rechtschreibung perfekt zu beherrschen, 
noch alles besser zu wissen und bedanke mich abschließend für die 
Verbesserung, die ich hiermit gleich habe einfließen lassen, und für das 
hübsche Bildnis mit dem ofen. :-)

Gruß

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es mag aber bessere Typen geben.

Allerdings:
Der STM32F103: 3.5µA im Standby mit Watchdog + 1.4µA für RTC.
Bei 8MHz stehen ~3mA (AVR) gegen ~11mA (STM32).
Bei 72MHz: -- gegen 63mA.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anglizismenübersetzer wrote:

> ...aber das wäre doch dann "thermischer Stress", nicht "thermaler
> Stress" :-)

Duden: "ther|mal <Adj.> [(engl., frz. thermal) zu griech. thérmē, 
→Therme] (selten): 1.  durch Wärme bewirkt, ...".

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gaebe es auch noch den uC3 basierend auf der AVR32 architektur. Die 
bietet uebrigens bei bei voller Geschwindigkeit einen Stromverbrauch von 
23 mAs.
Also fuer einen 32-bit Controller eine ausgezeichnete Leistung.
Es sei auch noch gesagt, dass ein AVR(8) bei z.B. 10 MHz fuer 
Rechenanwendungen VIEL weniger Rechenleistung bringt als ein AVR32 bei 2 
MHz. Also das mit Power sollte immer in 2 Betriebsarten angesehen 
werden, im aktiven Betrieb mit angestrebter Rechenleistung und im 
Ruhebetrieb. Grundsaetzlich haben fast alle 8-bit Controller sher gute 
Ruhestroeme wogegen sie im aktiven Betrieb nur dann mit 32-bit 
Controllern strommaessig mithalten koennen, wenn es um "bit-schupsen" 
geht.

Brauchste Rechenpower, dann musste wahrscheinlich vom AVR8 umsteigen, ob 
das auf den XMEGA, den ARM, den Cortex oder den AVR32 ist, bleibt den 
Anforderungen vorbehalten. Der einfachste Umstieg waere zum XMEGA, dann 
AVR32, dann die ARM basierenden Typen.

Hoffe es hilft ein wenig, Robert

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allesamt,

hat schon wer darüber nachgedacht die Programmiersprache Java für den uC 
zu verwenden?

Oder ist Java in diesem Forum fehl am Platz?

Manfred

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Delay wrote:
> Was könnten gute Gründe sein, um von den AVRs auf ARM umzusteigen???

Die Frage, welche Anwendungen Du damit realisieren willst.
Für alle Arten von Steuerungen ist ein 8-Bitter dicke ausreichend.

Ein 32-Bitter lohnt sich erst bei massivem Rechenbedarf, z.B. Audio- 
oder Videobearbeitung. Oder bei sehr großen Datenmengen (SRAM >64kB).


> Sind einfacher in der handhabung?

Eindeutig nein.


> Leichter oder schwerer aufzubauende Grundbeschaltung?

Man sollte schon erstmal ne 8-Bit Applikation erfolgreich layoutet haben 
und stabil zum Laufen gebracht haben.
Als Anfänger sollte man für nen 32-Bitter mindestens 4 Layer nehmen.


Peter

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.