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
Wenn man AVRs gewohnt ist und mehr Performance braucht, ist der kommende XMega in der Tat eine Alternative, bevor man die Plattform komplett wechselt.
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.
Der XMega mag auch nur noch maximal 3.6V, läuft aber auch schon ab 1.7V.
>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
... sparsamen Batteriebetrieb sind ARMs übrigens nicht wirklich geschaffen ... Dies ist ein Wischi-Waschi 'nicht wirklich' Satz. Und großer Quatsch!
"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
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.