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
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
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.
@ 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
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.
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.
>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
"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".
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.
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.
>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ß
> 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.
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, ...".
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
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
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
