Forum: Mikrocontroller und Digitale Elektronik Orientierungshilfe ATXMega oder ARM (ST, NXP)?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Markus M. (adrock)


Lesenswert?

Hi,

für zukünftige Projekte die ein wenig mehr Anforderungen bzgl. 
Arbeitsspeicher (SRAM) und Performance haben als die aktuellen ATmegas 
bieten können, bin ich auf der Suche nach einer neuen Plattform.

Ich schaue mir gerade einen ATXMega192A3 an. Grundsätzlich ist der ganz 
nett, insbesondere was die Peripherie angeht (DMA, Timer etc.). Wobei 
ich mir da teilweise schon denke, ob das nicht ein bisschen zu komplex 
ist (Eventsystem etc.).

Sollte ich eher zu ARM wechseln? Wenn ja, welche Linie? NXP oder eher 
ST?

Von den Möglichkeiten wären die STM32F1... ungefähr das, was ich mir 
vorstelle. Allerdings gibt es kein Evalboard für die, oder? Wäre dann 
ein STM32F0 Discovery board das richtige um den ST-Link/V2 zu haben, und 
da dann ein Board (welches?) mit einem STM32F1... anschließen?

Für den ATXMega würde sprechen, dass ich mich nun gerade ins Studio 6 
einigermaßen eingearbeitet habe.

Bin irgendwie ein bisschen "verloren" zwischen den ganzen Möglichkeiten. 
Die Preise für die eigentlichen Controller, ob nun ATXmega oder 
STM32F1... sind eher nebensächlich (und geradezu ein Witz, gemessen an 
dem, was man an Möglichkeiten/Performance bekommt).

Grüße
Markus

von Lothar (Gast)


Lesenswert?

Der Hauptvorteil von ARM ist die Kompatibilität und die vielen 
Bibliotheken und Programmbeispiele. Am Beispiel NXP kann man sich ein 
"grosses" Evalboard holen zur SW-Entwicklung, z.B. mit LPC176x, und der 
fertige Code läuft dann ohne Änderungen, nur mit anderem CMSIS 
Headerfile, auch auf den anderen Chips LPC8xx, LPC11xx, LPC12xx, 
LPC13xx, LPC175x, LPC40xx.

von da1l6 (Gast)


Lesenswert?

Hallo

Wenn dir der XMega zu kompliziert ist, wird ARM es erst recht sein.

Das XMega Event System muss man nicht benutzen und ich habe es auch noch 
nie.

Bei der Frage ARM vs. XMega würde ich zunächst mal die Gegenfrage nach 
der benötigten CPU Leistung aufbringen. Wenn 32MHz und 8 Bit reichen, 
dann ist der XMega gut und einfach im Umstieg.

da1l6

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Der Hauptnachteil der XMega ist die fehlende 5-Volt Toleranz, der 
fehlende CAN-Controller und die propriaetaere Debugschnittstelle.

von Peter D. (peda)


Lesenswert?

Markus M. schrieb:
> für zukünftige Projekte die ein wenig mehr Anforderungen bzgl.
> Arbeitsspeicher (SRAM)

Der Xmega kann prinzipiell >64kB RAM ansprechen, aber der AVR-GCC nicht.


Peter

von Bastler (Gast)


Lesenswert?

Das STM32 Discovery IST ein EVAL Board mit programmer / debugger gleich 
drauf.
Software und selbsterklärende Bibliatheken gibt es gratis bei ST.
Als IDE ist Coocox zu empfehlen.
Anleitung ist einfach und OHNE Codebegrenzung!

Wunderbar als einstieg.

p.S.: Vergiss den ARM Compiler nicht zu istallieren und den Pfad im 
Coocox anzupassen.

von Markus .. (10mhz)


Lesenswert?

Peter Dannegger schrieb:
> Der Xmega kann prinzipiell >64kB RAM ansprechen, aber der AVR-GCC nicht.
Ohne jetzt gleich wieder eine Bascom-avr vs. AVR-GCC Discussion zu 
schüren aber bei Bascom-AVR kann man einfach >64KB RAM ansprechen.
http://avrhelp.mcselec.com/configxram.htm?zoom_highlightsub=xram

da1l6 schrieb:
> Das XMega Event System muss man nicht benutzen und ich habe es auch noch
> nie.

Das XMEGA Event System ist einfacher als so manches bei ARM.

von Arne Maximilian R. (arnemaximilian_r)


Lesenswert?

Markus M. schrieb:
> Sollte ich eher zu ARM wechseln? Wenn ja, welche Linie? NXP oder eher
> ST?
>
> Von den Möglichkeiten wären die STM32F1... ungefähr das, was ich mir
> vorstelle. Allerdings gibt es kein Evalboard für die, oder? Wäre dann
> ein STM32F0 Discovery board das richtige um den ST-Link/V2 zu haben, und
> da dann ein Board (welches?) mit einem STM32F1... anschließen?

Moin Markus,

ich würde dir zu der ARM-Geschichte raten. Bei der Wahl der IDE ist das 
zuvor erwähnte CooCox für Anfänger vollkommen ausreichend und auch ein 
guter Einstieg.
Zu den Boards gibt es von ST drei gute und auch günstige 
Einstiegsboards:
Dein STM32F0:
http://www.watterott.com/de/STM32F0DISCOVERY
Der STM32F3
http://www.watterott.com/de/STM32L-DISCOVERY
Und der Favorit:
http://www.watterott.com/de/STM32F4Discovery

Der letztere ist von der ganz aktuellen Serie (mit Cortex-M4). Auch wenn 
er etwas größer ist als deine Anforderungen findest du viel gute 
Literatur zu diesem Board (sehr populäres Board).

Bei ARM wäre noch eine gute Alternative NXP (wie du schon erwähnt hast). 
NXP hat meines Erachtens eine schöner beschriebene Dokumentation (die 
nunmal sehr wichtig ist bei derartigen Chips). Der Nachteil ist aber 
leider, dass die NXP-Boards nicht ganz so verbreitet sind wie das 
letztere ST-Board. Hier solltest du aber bei Interesse nach den 
LPCXpresso-Boards suchen, die ein günstiger Einstieg (mit Debugger) 
sind.

MfG
Arne

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

STM32F3Discovery hat den Vorteil, dass man durch Umjumpern (Null Ohm 
Brücken) eine serielle Schnittstelle auf den ST-Link legen kann und nach 
Umprogrammieren (z.B. Blackmagic) des ST-Links dann auch serielle 
Ausgabe auf dem USB Stecker hat.

von Jojo S. (Gast)


Lesenswert?

Wenn dir NXP bzw LPC1769 besser gefällt ist der SimpleCortex ein gutes 
Board. Hat auch eine Debugschnittstelle und kann direkt per USB und 
CooCox programmiert werden. Hardwareerweiterung ist mit Arduino Shields 
möglich.
LPCXpresso ist auch eine schöne kompakte Hardware, aber in der freien 
Version nervt das Codelimit der CodeRed IDE. Und wenn man mit CodeRed 
ST32 bearbeiten will braucht man gar die 999$ Version.
Auf jeden Fall machen die Cortex M3/M4 Sinn wenn man mit RTOS, schnellem 
Ethernet, schneller Floating Point Rechnerei oder gleich allem zusammen 
arbeiten möchte.

von Eumel (Gast)


Lesenswert?

Nimm die Stellaris Serie von TI. Dazu gibts ein günstiges Launchpad.

von Roland H. (batchman)


Lesenswert?

Lothar schrieb:
> Am Beispiel NXP kann man sich ein
> "grosses" Evalboard holen zur SW-Entwicklung, z.B. mit LPC176x, und der
> fertige Code läuft dann ohne Änderungen, nur mit anderem CMSIS
> Headerfile, auch auf den anderen Chips LPC8xx, LPC11xx, LPC12xx,
> LPC13xx, LPC175x, LPC40xx.

Etwas off-topic, aber welches CMSIS header file bewirkt, dass Code für 
den 1769 auf dem 1343 oder auf dem 1114 läuft?

von Coder (Gast)


Lesenswert?

Überlege Dir was Du tatsächlich benötigst. Beide (ARM oder XMega) sind 
hinreichend einfach oder schwer. Die App-notes zum Xmega eigentlich ganz 
gut. Und nicht die Erratas vergessen. Ansonsten ist die Lieferbarkeit 
und Preis auch nie verkehrt zu berücksichtigen.

Also mach dir eine Entscheidungs-Tabelle.

von Markus M. (adrock)


Lesenswert?

...also ich habe natürlich schon ein bisschen in die Doku 
reingeschnuppert.

Naja, beim XMega habe ich den Eindruck, dass manche Sachen einfach 
"hingefrickelt" und dadurch unnötig verkompliziert sind, z.B. diese 
HiRes-Erweiterung für die Timer oder das Mapping von (virtuellen) Ports 
in den I/O-Bereich um die IO-Befehle nutzen zu können.

Hmmm... das CooCox IDE sieht schon ganz gut aus. Ich denke ich werde mir 
einfach mal ein STM32 xxx Discovery holen und ein bisschen 
reinschnuppern, leider wird ja das STM32L Discovery noch nicht 
unterstützt.

Danke & Gruß
Markus

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Markus M. schrieb:

> Sollte ich eher zu ARM wechseln?

Vorweg: Ich selbst habe mit keiner µC-Familie so viel gemacht wie 
mit AVR (Hobby) und auch bei der avr-gcc Entwicklung mitgewirkt (auch 
Hobby).

Dennoch würde ich stark zu ARM tendieren wenn Anwendung oder RAM-Bedarf 
größer wird.

Das AVR-Design mit dem RAMP-Zeug ist — sorry — einfach nur krank...

von Lothar (Gast)


Lesenswert?

Roland H. schrieb:
> Etwas off-topic, aber welches CMSIS header file bewirkt, dass Code für
> den 1769 auf dem 1343 oder auf dem 1114 läuft?

Ich habe ein "includes.h" gemacht, in dem über #define die jeweils 
passenden Header Files aktiviert werden, also z.B. statt #include 
"lpc17xx_uart.h" dann #include "lpc13xx_uart.h" usw. Da verschiedene 
Chips die Peripherie auf verschiedenen Pins haben können, sollte man die 
Pins natürlich auch über #define festgelegt haben.

von Roby (Gast)


Lesenswert?

ARM ist und bleibt mit allem was dranhängt komplizierter und komplexer. 
Die XMegas sind eine runde, ausgereifte Sache. Kann man auch noch 
vernünftig in ASM proggen. Mich kriegen keine 10 Pferde hin zu ARM, 
allen Hardware Preis/Leistungsvorteilen zum Trotz.

von Markus M. (adrock)


Lesenswert?

Ja, das stimmt wohl.

Ich hatte mir den ARM bzw. Thumb(2) Befehlssatz auch mal angeschaut... 
das ist eindeutig nicht für Menschen gemacht ;-) Ein Compiler wird da 
aber wahrscheinlich sehr gute und optimale Konstrukte bauen können.

Grüße
Markus

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Schaue noch in den Artikel: STM32 da gibt es viele Links, Tipps und 
Bezugsquellen.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Markus M. schrieb:
> Naja, beim XMega habe ich den Eindruck, dass manche Sachen einfach
> "hingefrickelt" und dadurch unnötig verkompliziert sind, z.B. diese
> HiRes-Erweiterung für die Timer oder das Mapping von (virtuellen) Ports
> in den I/O-Bereich um die IO-Befehle nutzen zu können.

Das ist nicht korrekt. Die XMEGAs sind die aufgeräumtesten AVRs aller 
Zeiten. Was man bei den neueren PicoPower-MEGAs angefangen hatte, ist 
hier konsequent fortgeführt worden. Wenn Du Dich länger damit 
beschäftigst, merkst Du das auch. Einige Hilfsmittel wurden eingebaut, 
um den Umstieg von den MEGAs zu erleichtern. Nicht zu vergessen sind die 
komplett kostenfreie Entwicklungsumgebung und unzählige AVR-Projekte, 
die nach Anpassung auch (besser) auf einem XMEGA laufen.

Roby schrieb:
> ARM ist und bleibt mit allem was dranhängt komplizierter und komplexer.
> Die XMegas sind eine runde, ausgereifte Sache. Kann man auch noch
> vernünftig in ASM proggen. Mich kriegen keine 10 Pferde hin zu ARM,
> allen Hardware Preis/Leistungsvorteilen zum Trotz.

ACK.

Johann L. schrieb:
> Das AVR-Design mit dem RAMP-Zeug ist — sorry — einfach nur krank...

Wie kommst Du darauf? Nur weil GCC die 24-Bit-Adressierung nicht kann, 
funktioniert der Controller nicht schlechter. Die 3. Registerbytes 
werden übrigens direkt von der Hardware mitbedient und bei 
Over-/Underflow entsprechend aktualisiert. Die komplett lineare 
Adressierung der internen Speicher und Peripherie ist auch sehr elegant 
zu programmieren, gerade in Bezug auf DMA.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Es ist wie immer eine Sache der Anforderung.

Wir arbeiten uns gerade in die STM32-Familie ein und werden kurzfristig 
komplett von AVR auf diese umsteigen.

Für das gleiche Geld hat man eben echte 32Bit, ordentlich Speicher und 
vor allem Geschwindigkeit.

Beispiele und kostenlosen Code findest Du für beide Familien reichlich.

Komplizierter finde ich beim STM32 eigentlich nur die Takterzeugung. 
Ansonsten steigt natürlich immer die Komplexität mit der Anzahl der 
Möglichkeiten - aber wenn man sich die Module nach und nach erarbeitet, 
ist das eigentlich kein Problem.

Zumindest die STM32-Familie ist extrem weit gespreizt - da findest Du 
von LowCost um 1 Euro bis hin zum Flagschiff mit DSP-Fähigkeiten und FPU 
alles, was das Herz begehrt.

Da ist die Entwicklung einfach aufgrund der Konkurrenzsituation viel 
dynamischer als bei den AVRs, die nur Atmel herstellt.

Letztlich muss Du selbst entscheiden: wenn Du jetzt schon weisst, dass 
Du in Zukunft mehr Rechenleistung und hohen Datendurchsatz benötigst, 
würde ich ARM wählen.

Chris D.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Markus M. schrieb:
> leider wird ja das STM32L Discovery noch nicht
> unterstützt.

Ich habe mit beiden Familien gute Erfahrungen gemacht, was man beim 
STM32 durch Zusammensuchen der Tools, aber den geringeren Preis für 
Evalboards reintut, nimmt sich nicht viel gegenüber den XMegas, bei 
denen die Hardware teurer ist, aber dafür gute Tools einfach und 
kostenlos sind.

Mein Tipp ist nur, wenn es ein STM32 Board werden soll, nimm gleich das 
fette mit dem STM32F4 und keines der L,V oder VL Serie, es sei denn, du 
brauchst unbedingt ein LCD drauf. Der F4 ist eindeutig das schnellste 
mit (glaube ich) 132 Mhz und schlägt die kleinen F1 um Längen. Ich 
jedenfalls ärgere mich, das ich die VL Boards habe und nicht den F4.
http://www.st.com/internet/evalboard/product/252419.jsp

von Moritz M. (Gast)


Lesenswert?

Hallo,

ich programmiere auch die STM32 Controller. Hab auch gleich das 
F4Discovery genommen. Wenn man einfach sich mal hinsetzt und das ein 
oder andere Beispiel Projekt sich anguckt steigt man da auch relativ 
schnell durch. Mit der StdLib von ST wird einem auch viel Arbeit 
abgenommen.

CooCox ist auch sehr einfach. Nur nen paar Änderungen und die ersten 
LED´s blinken.

Die F4 Controller können bis 168MHz.

Moritz

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Matthias Sch. schrieb:

> Mein Tipp ist nur, wenn es ein STM32 Board werden soll, nimm gleich das
> fette mit dem STM32F4 und keines der L,V oder VL Serie, es sei denn, du
> brauchst unbedingt ein LCD drauf. Der F4 ist eindeutig das schnellste
> mit (glaube ich) 132 Mhz und schlägt die kleinen F1 um Längen. Ich
> jedenfalls ärgere mich, das ich die VL Boards habe und nicht den F4.
> http://www.st.com/internet/evalboard/product/252419.jsp

Sehe ich auch so - das STM32F4DISCOVERY gibt ja wirklich für wenig Geld 
mit integriertem JTAG-Debugger und da hast Du Platz (1 MB) und 
Geschwindigkeit (sind 168MHz) und alle Möglichkeiten.

Das Einrichten von Eclipse für die ARMs ist etwas mühsam, aber es gibt 
dafür gute Anleitungen. Wir verwenden das hie runter Linux 
ausschließlich, weil wir mit Eclipse auch alles andere (PHP für unsere 
Website, Tcl/Tk, Python etc.) erschlagen können.

Ansonsten wurde ja schon Coocox erwähnt.

Chris D.

von Hugo Habicht (Gast)


Lesenswert?

Markus M. schrieb:
> Für den ATXMega würde sprechen, dass ich mich nun gerade ins Studio 6
> einigermaßen eingearbeitet habe.

Mit dem ATXmega habe ich meine helle Freude gehabt. Ich kann Dir nur 
abraten. Der Aufwand um sich einzuarbeiten ist in meinen Augen für ARM 
oder ATxmega gleich groß. Nimm den ARM dann wirst Du glücklich.

von Chris (Gast)


Lesenswert?

Also wenn Du Dich bereits in Atmel Studio 6 eingearbeitet hast, dann 
nimm doch den SAM4 von Atmel. Das SAM4S Xplain kit hat einen SAM-ICE 
Debugger onboard und kostet nur 29USD, und Du bekommst eine günstige 
Hardware und kostenlose Entwicklungsumgebung ohne Einschränkungen. Wenn 
Du etwas größeres machen willst, gibt es das SAM4S-EK mit Display.

http://store.atmel.com/PartDetail.aspx?q=p:10500321;c:1000001

Wenn Du dann noch das Software Framework im Studio 6 nutzt, könntest Du 
sogar eine 8Bit/32Bit Portierung Deiner Anwendung sehr leicht vornehmen, 
da lediglich dann die HAL abgeändert werden muß. Als Bsp, ich hab meine 
USB Device Anwendung vom Xmega16A4U zu SAM4S in wenigen Minuten 
portiert. Sowas ist selbst zwischen den Cortexen diverser Hersteller 
nicht möglich, bei Atmel funktioniert sowas selbst zwischen 2 völlig 
unterschiedlichen Architekturen. Das ist es warum ich sowohl die Xmega's 
als auch die SAM3/4 verwende.

Was mir auch an Atmel gefällt ist dass man diverse Plugins fürs Studio 6 
bekommt, z.b. ein Subversion plugin zur Versionskontrolle, aber auch die 
Integration von FreeRTOS für die SAM Familie.

Überleg Dir Deine Auswahl wirklich gut, gute kostenlose TOols mit 
Support vom Hersteller sind das wichtigste, welchen Chip Du dann nimmst 
ob Xmega oder Cortex ist dann fast nebensächlich. P.S: Xmega kann Dank 
EBI auch ein SDRAM ansprechen und den verfügbaren Speicher deutlich 
vergrößern...je nach Bedarf. Wie es geht kannst Du auf einem der Xplain 
Kits (www.atmel.com/xplain) nachsehen, auch recht preisgünstige Tools.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

@Markus
Wenn die Entscheidung für Entwicklungen in einer Firma von nöten sind, 
dann kann ich nur zu einem Prozessor Cortex M3/4 raten.
Wenn das nur Hobby bleiben soll, dann mache wie Du magst.

von Roland H. (batchman)


Lesenswert?

Roby schrieb:
> ARM ist und bleibt mit allem was dranhängt komplizierter und komplexer.

Das ist einfach nicht richtig. Nenne mal neben dem Mythos ein paar 
handfeste Punkte.

Ich zähle mal ein paar Dinge auf, welche in der 32-Bit-Welt einfacher 
sind (dazu gehören noch PIC32/MIPS und Renesas RX, AVR32 kenne ich 
nicht), das gilt teilweise auch für MSP430 und PIC16):

- Die Hardware beim AVR passt leider nicht zum GCC
-   Kein prog mem. D. h. auch nicht Ausgabefunktion in zwei Varianten. 
Schon mal probiert, in C++ operator overloading mit String und prog mem 
String zu machen?
-   Echtes "const"; die landen im ROM
-   C++ vtables landen im ROM
-   String merging
- Keine Fuses, kein ver-fusen
- Keine Probleme jenseits der 64k, keine Trampoline
- Hard faults, exceptions
- Im ROM integrierter boot loader (ARM, RX)
- Startup in C möglich, Interrupt-Handler sind "normale" C-Funktionen 
(ARM)
- Man kann Integer(arithmetik) ohne Bedenken exklusiv auf uint32_t 
auslegen
- Der Kern ist normiert (nur ARM: systick, NVIC, CMSIS)
- Mehrere Hersteller, riesige Auswahl (ARM)
- Peripherie: Z. B. massig Timer mit 16/32/64-Bit, integrierte CAN 
transceiver, integriertes Ethernet PHY
- Atomare Zugriffe auf 16/32-Bit Variablen
- Für "low power" einen CM0, für Rechenpower mit FPU einen CM4.
- Das ADC beim atxmega256a3 (ich kenne nur diesen) ist arg kompliziert.
- Es gibt inzwischen auch ARMs mit integriertem EEPROM (TI Stellaris)
- Es gibt inzwischen auch ARMs mit "single-cycle access to the GPIOs" 
für schnelles "pin toggle" (lpc8xx)
- Gibt es xmega mit CAN?
- Gibt es xmega in DIP (ARM lpc1114, PIC32)? Der lpc1114 macht eine sehr 
gute Figur auf dem Steckbrett (wenig externe Beschaltung, interner Takt 
bis 48 MHz)
- Treiber/Funktionen im ROM (TI Stellaris, einige lpc)
- Programmierer und Debugger für 12 EUR (ARM, stm32f407 discovery, Dank 
Normierung durch ARM kann dieser z. B. auch für lpc eingesetzt werden)
- Preis
- Erheblich kompakterer Code: in ARM thumb passt in 32k wesentlich 
mehr als at(x)mega. Gleiche Applikation, gleiche GCC-Version:
1
  text     data      bss      dec      hex  filename
2
  28490       48     1148    29686     73f6  comparison-lpc1114-4.6.2.elf
3
  28552       40     1312    29904     74d0  comparison-lpc1343-4.6.2.elf
4
  33748       64     1436    35248     89b0  comparison-stm32f407-4.6.2.elf
5
  45744      255     1074    47073     b7e1  comparison-atmega644-4.6.2.elf
6
  47602      312     1218    49132     bfec  comparison-atxmega256a3-4.6.2.elf

Diese Punkte beziehen sich auf xmega. tiny/mega gibt es in DIP. Es kämen 
ein paar andere hinzu (max. Takt bei 3.3V, max. Takt überhaupt).

Als Nachteile für 16-/32-Bit fallen mir ein
- Memory alignment, darauf muss geachtet werden. Das schmerzt bei den 
kleinen MSP430, aber nicht bei den 32-Bittern, da dort genügend RAM 
vorhanden ist.
- Meinetwegen gibt es noch ein paar Punkte, bei denen 5V von Vorteil 
sind. Ich sehe es als Nachteil

Jetzt würden mich die Dinge interessieren, welche auf einem ARM/PIC32/RX 
"komplizierter und komplexer" sind.

Chris D. schrieb:
> Komplizierter finde ich beim STM32 eigentlich nur die Takterzeugung.

Auch die xmegas haben ein kompliziertes Clocks setup. Das gibt sich 
nichts.

Matthias Sch. schrieb:
> Ich jedenfalls ärgere mich, das ich die VL Boards habe und nicht den F4.

Ich finde das VL-Board gar nicht so schlecht. Der stm32f100 erschlägt 
einen nicht mit der Peripherie, und alle Pins sind frei. Man kriegt ihn 
auch in zwei Steckbretter eingesteckt.

Knut Ballhause schrieb:
> Nur weil GCC die 24-Bit-Adressierung nicht kann,
> funktioniert der Controller nicht schlechter.

Zugegeben sehe ich das Ganze nur aus der GCC-Sicht, und es mag sein, 
dass mit einem anderen Compiler einige SW-technische Punkte der obigen 
Liste entfallen. Für viele (zumindest für mich) ist der GCC die 1. Wahl, 
da sonst die cross-platform Entwicklung m. A. nach schwieriger ist. 
Damit bringt mir der beste µC nichts, wenn es gewisse Probleme im 
Zusammenspiel mit dem GCC gibt.

Mir ist nur unklar, weshalb man das xmega-Design so gewählt hat. Wenn 
man arm7tdmi mit Cortex-Mx vergleicht, sieht man sehr deutlich, wie gut 
ARM CMx auf den GCC angepasst hat: Es wurden einige sehr lästige 
Probleme im Zusammenspiel mit dem GCC eliminiert, obwohl ARM mit Keil 
selbst einen Compiler anbietet. Microchip hat für PIC32 gar nicht mehr 
damit begonnen, einen C(++)-Compiler anzubieten.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Roland H. schrieb:

> Chris D. schrieb:
>> Komplizierter finde ich beim STM32 eigentlich nur die Takterzeugung.
>
> Auch die xmegas haben ein kompliziertes Clocks setup. Das gibt sich
> nichts.

Ah, ok - wusste ich nicht - ich bezog mich jetzt nur auf die "alten" 
AVRs und den Sprung von dort zu den ARMs. Gut, dann ist das also auch 
kein Vorteil.

Wobei man sich da auch nur einmal einarbeiten muss - mit dem 
Blockschaltbild vom F4 unter der Tischauflage hat man da schnell den Bus 
bzw. den Takt gefunden, den man benötigt.

Hat man das ein paar Mal gemacht, ist das kein Problem mehr.

Chris D.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Roland H. schrieb:
> Ich finde das VL-Board gar nicht so schlecht. Der stm32f100 erschlägt
> einen nicht mit der Peripherie, und alle Pins sind frei. Man kriegt ihn
> auch in zwei Steckbretter eingesteckt.

Nö, schlecht ist es auch nicht, ich habs sogar mit hochbiegen der Pins 
an der Schmalseite auf ein Steckbrett bekommen :-), aber für die paar 
Euro mehr ist der F4 eben ein Tier von MC, während der F103 den XMega 
nicht wirklich abhängt. Da ich hier ein und dasselbe Projekt (BLDC mit 
FOR) hier auf drei Platformen realisiert habe (Mega, XMega und 
STM32F1XX) ist die Leistung ganz gut abzuschätzen. Der XMega punktet 
hier durch die AWEX Erweiterung, der STM32 durch die 32bit Verarbeitung 
und der kleine Mega88 hechelt sich einfach nur durch... STM32F103 und 
Xmega(192/256A3) nehmen sich da nicht viel, da der Xmega 8-bitter mit 32 
MHz und der STM32 nur mit 24 Mhz läuft und mehr auch nicht rauszuholen 
ist.

von Unrouted (Gast)


Lesenswert?

Matthias Sch. schrieb:

Matthias Sch. schrieb:
> Roland H. schrieb:
>> Ich finde das VL-Board gar nicht so schlecht. Der stm32f100 erschlägt
>> einen nicht mit der Peripherie, und alle Pins sind frei. Man kriegt ihn
>> auch in zwei Steckbretter eingesteckt.
>
> Nö, schlecht ist es auch nicht, ich habs sogar mit hochbiegen der Pins
> an der Schmalseite auf ein Steckbrett bekommen :-), aber für die paar
> Euro mehr ist der F4 eben ein Tier von MC, während der F103 den XMega
> nicht wirklich abhängt. Da ich hier ein und dasselbe Projekt (BLDC mit
> FOR) hier auf drei Platformen realisiert habe (Mega, XMega und
> STM32F1XX) ist die Leistung ganz gut abzuschätzen. Der XMega punktet
> hier durch die AWEX Erweiterung, der STM32 durch die 32bit Verarbeitung
> und der kleine Mega88 hechelt sich einfach nur durch... STM32F103 und
> Xmega(192/256A3) nehmen sich da nicht viel, da der Xmega 8-bitter mit 32
> MHz und der STM32 nur mit 24 Mhz läuft und mehr auch nicht rauszuholen
> ist.

Hallo,

der STM32 hat doch auch eine PWM Einheit über den Advanced Timer 1... 
Mit Totzeit Generierung usw.
Was hatte die AWEX hier für Vorteile? Wir benutzen momentan momentan 
auch einen XMega sind aber von den ganzen erratas zu controller und AWEX 
usw. mittlerweile stark am überlegen auf STM32 Cortex M0 umzusteigen. 
Vor allem muss man sagen dass bei Cortex gefühlt recht viel luft nach 
oben (M0/M3, F0..., F1..., F3..., F4...) ist, während man mit dem XMega 
auf der AVR Reihe eher schon "oben" ist.

von Markus M. (adrock)


Lesenswert?

Roland H. schrieb:
> Roby schrieb:

> Ich zähle mal ein paar Dinge auf, welche in der 32-Bit-Welt einfacher

Danke für den interessanten Vergleich.

> Auch die xmegas haben ein kompliziertes Clocks setup. Das gibt sich
> nichts.

Jepp... ich habe zwei Stündchen gebraucht bis ich es hinbekommen habe, 
den XMega mit einem externen Oszillator und x2 PLL zu takten. Aber gut, 
wenn man es einmal gemacht hat kennt man die Fallstricke (Reihenfolge, 
geschützte Register -> inline Assembler notwendig).

Naja, ich werde jetzt wohl mein aktuelles Vorhaben mal mit dem XMega 
durchziehen und schauen wie ich klarkomme. Aber einen ARM werde ich mir 
trotzdem nochmal anschauen.

Was ich noch nicht ganz verstehe ist das Zusammenspiel zwischen 
Toolchain und Hardware:

Angenommen ich möchte die CoIDE verwenden und habe jetzt sagen wir mal 
ein STM32 F0/F4 Discovery board. Damit kann ich ja (wenn ich es richtig 
verstanden habe) über den ST-LINK/V2 alle (von CoIDE unterstützen) STM32 
Controller programmieren und debuggen, richtig?

Also z.B. auch einen Controller auf diesem Board:

https://www.olimex.com/Products/ARM/ST/STM32-H103/

(das ist ziemlich genau was ich brauchen könnte: Gute Rechenleistung mit 
72MHz, wenig Schnickschnack und schön klein)

Viele Grüße
Markus

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

> alle (von CoIDE unterstützen) STM32 Controller programmieren und debuggen,
> richtig?

Ja. Beim STM32 F0/F4 Discovery board ist der ST-LINK/V2 bereits mit auf 
dem Board implementiert, den man auch für eigene Projekte nutzen könnte 
(Jumper).
Somit wäre ein extra ST-LINK/V2 nicht nötig zu kaufen.

Für den Start mit dem STM32 empfehle ich ein STM32F4DISCOVERY Borad. 
Kostet 12..18 EUR und alles ist drauf. Das ist garantiert keine 
Fehlausgabe um kostengünstig einen STM32 kennen zu lernen und auch erste 
Kein-Projekte damit realisieren zu können.

Wenn man doch mehr mit dem STM32 macht und die Projekte mal mehrere 
100KB FLASH benötigen empfehle ich den SEGGER J-LINK.
- Ist der schnellste
- Ist effizienteste
- Unterstützt nahezu alle ARM Prozessoren (NXP, Atmel, ST, Analog, ... 
uvm)
- EDU Version für Privat kostet auch nicht viel.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Unrouted schrieb:
> der STM32 hat doch auch eine PWM Einheit über den Advanced Timer 1...
> Mit Totzeit Generierung usw.
> Was hatte die AWEX hier für Vorteile?
Richtig, beim F103 ist es glaub' ich, Timer 8 (muss ich nochmal gucken). 
Klar nehme ich den. AWEX ist praktisch, wenn du im Betrieb zwischen 
Sinus und Blockkommutierung umschalten willst. Der F103 hat da eine böse 
Falle, bei der du dabei auch noch die Polarität der Outputs mitschalten 
musst. Wie gesagt, die nehmen sich in dieser Anwendung nicht viel.
> Wir benutzen momentan momentan
> auch einen XMega sind aber von den ganzen erratas
Was mich wirklich ärgert, ist das EEPROM Desaster. Ich kann mir einfach 
nicht leisten, nur zum Schreiben des EEPROM die ganze Kiste in Sleep zu 
versetzen, da musste ein externes herhalten. Da hat sich STM ja mit dem 
Nichtvorhandensein des EEPROM schön rausgewunden. Die Probleme mit dem 
ADC der XMegas kann ich hier nicht nachvollziehen, das geht alles 
bestens.

Schön beim XMega ist eben das EBI, an dem man mal eben 8MB SDRAM 
ranhängen kann. Brauch ich für den BLDC nicht, ist aber auf dem Xplained 
Board bei einem Datenlogger im Einsatz.

von Roland H. (batchman)


Lesenswert?

Matthias Sch. schrieb:
> STM32F103 und
> Xmega(192/256A3) nehmen sich da nicht viel, da der Xmega 8-bitter mit 32
> MHz und der STM32 nur mit 24 Mhz läuft und mehr auch nicht rauszuholen
> ist.

Interessanter Vergleich. Ist das "gefühlt" gleich oder tatsächlich 
irgendwie messbar?

Eines verstehe ich nicht, wieso läuft der stm32f103 nicht mit 72 MHz 
(das Limit mit 24 MHz kenne ich von der Value line wie dem stm32f100)?

Chris D. schrieb:
> Wobei man sich da auch nur einmal einarbeiten muss - mit dem
> Blockschaltbild vom F4 unter der Tischauflage hat man da schnell den Bus
> bzw. den Takt gefunden, den man benötigt.
>
> Hat man das ein paar Mal gemacht, ist das kein Problem mehr.

Ja, so ist das :-) Dem Aufwand des Einarbeitens in die Clocks steht im 
übrigen das Thema Fuses gegenüber, das fällt auch nicht vom Himmel.

Markus M. schrieb:
> Angenommen ich möchte die CoIDE verwenden und habe jetzt sagen wir mal
> ein STM32 F0/F4 Discovery board. Damit kann ich ja (wenn ich es richtig
> verstanden habe) über den ST-LINK/V2 alle (von CoIDE unterstützen) STM32
> Controller programmieren und debuggen, richtig?

Ob es aus der CoIDE heraus geht, weiss ich nicht. Es soll möglich sein, 
mit dem stm32f4 discovery einen lpc zu programmieren/debuggen - das hat 
ARM genormt. Das meinte ich mit "Debugger für ca. 14 EUR".

Markus M. schrieb:
> (das ist ziemlich genau was ich brauchen könnte: Gute Rechenleistung mit
> 72MHz, wenig Schnickschnack und schön klein)

Der stm32f103 hat u. U. einen Schönheitsfehler: CAN und USB gehen nicht 
gleichzeitig. Da es genügend Auswahl gibt, würde ich mir einen anderen 
aussuchen.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

STM32F107 oder STM32F2xx oder STM32F4xx, bei denen geht CAN und USB 
gleichzeitig.

Der STM32F1xx kann garantiert 72MHz. Der kann auch mehr, aber dann 
funktioniert der nicht mehr im gesamten spezifizierten 
Temperaturbereich, also nicht empfohlen. Besser dann einen nahezu 
Pinkompatiblen STM32F2/F4 verwenden und das gleich schon im Layout 
vorsehen, siehe Datasheet.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Matthias Sch. schrieb:
>> auch einen XMega sind aber von den ganzen erratas
> Was mich wirklich ärgert, ist das EEPROM Desaster. Ich kann mir einfach
> nicht leisten, nur zum Schreiben des EEPROM die ganze Kiste in Sleep zu
> versetzen, da musste ein externes herhalten. Da hat sich STM ja mit dem
> Nichtvorhandensein des EEPROM schön rausgewunden. Die Probleme mit dem
> ADC der XMegas kann ich hier nicht nachvollziehen, das geht alles
> bestens.

Dann nehmt doch einfach mal aktuelle Steine. Die neueren XMEGAs mit USB 
sind fehlerbereinigt und laufen hoch zuverlässig. Es sind außerdem neue 
Funktionen dazugekommen, wie z.B. echte DACs (kein Sampling), 
Portrouting für fast alle Peripherie und einige Erweiterungen.

von Roland H. (batchman)


Lesenswert?

Markus Müller schrieb:
> Der STM32F1xx kann garantiert 72MHz.

... wenn das letzte x >= 3 ist :-)

Die Value line STM32F100x kann offiziell nur 24 MHz, 101 geht bis 36 
MHz.

Matthias Sch. schrieb:
> Da ich hier ein und dasselbe Projekt (BLDC mit
> FOR) hier auf drei Platformen realisiert habe (Mega, XMega und
> STM32F1XX) ist die Leistung ganz gut abzuschätzen.

Noch eine Nachfrage, da es so selten Vergleiche dieser Art gibt: 
Könntest Du bitte die Code-Größen posten?

von Basti (Gast)


Lesenswert?

Also ich denke der Unterschied liegt bei kleinen Preis hier:

STMF1: 32 Bit, etwas mehr Flash und SRAM
XMega: "unzählige" Timer, SPIs,UARTs,2xI2C und USB...

Jedenfalls sind das meine Beobachtungen beim gleichen Preis... 
XMega32A4U mal eingeworfen... STMF1 im selben Preissegment...

Also was brauchste, Rechenleistung oder Schnittstellen und Timer ohne 
Ende?

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Roland H. schrieb:
> Interessanter Vergleich. Ist das "gefühlt" gleich oder tatsächlich
> irgendwie messbar?

In meiner Hauptschleife läuft ein simpler Profiler (beim debug build) 
und darüber kriegt man mit, wie oft der MC Zeit hat, in 'main' 
rumzutrödeln.
Da der BLDC Kram ausschliesslich in Interrupts läuft und nur der 
Kommandointerpreter und Konsolenzeugs in der Hauptschleife, klappt das 
so ganz gut (Xmega und STM32) bis lala beim Mega88.

Roland H. schrieb:
> Noch eine Nachfrage, da es so selten Vergleiche dieser Art gibt:
> Könntest Du bitte die Code-Größen posten?

Aber klar:
AVR Studio 4 mit WinAVR
Mega88/168/328 : Programm 7536 Bytes, Data 97 Bytes
XMega192A3:      Programm 9494 Bytes, Data 115 Bytes
AtollicTS 2.3.0
STM32F103RB(VL) : Programm 15580 Bytes, leider ist Data nicht so leicht 
rauszukriegen.

Allerdings benutze ich beim STM32 mehr die Std.Peripheral Lib, da mir 
das Rumgewursteln in den STM Registern oft zu blöde war. Auch haben die 
Versionen für Xmega und STM32 ein paar mehr Features, um die 
Rechenleistung auch zu nutzen. Alle tun aber das gleiche: BLDC Motor mit 
Sensoren regeln und überwachen. Sinusmodulation aus Tabelle, Anlauf über 
Blockkommutierung. Ein PID Regler ist auch immer dabei.

Knut Ballhause schrieb:
> Dann nehmt doch einfach mal aktuelle Steine. Die neueren XMEGAs mit USB
> sind fehlerbereinigt und laufen hoch zuverlässig.

Nö, im Moment tuts ja der externe 93C46 sehr gut und man kann ihn 
einfach auswechseln, alles nicht tragisch. USB brauch ich nicht und ich 
hab im Moment auch keine Lust, QFP mit weniger als 0,7er Pitch zu 
montieren. Falls sich herausstellt, das die XMegas die beste Wahl sind, 
kann ich das immer noch machen.Erstmal rausfinden, welche Familie die 
beste ist.

von Basti (Gast)


Lesenswert?

>USB brauch ich nicht und ich hab im Moment auch keine Lust, QFP mit weniger >als 
0,7er Pitch zu montieren. Falls sich herausstellt, das die XMegas die >beste Wahl 
sind, kann ich das immer noch machen.Erstmal rausfinden, welche >Familie die beste 
ist.

hö? Beim z.B. 32A4 ist es so, dass die USB Variante das selbe kann und 
kleineres erreta hat als der ohne USB und zudem noch knapp die hälfte 
kostet!
Die packeges unterscheiden sich schon mal gar nicht und USB musst du ja 
nicht nutzen.

Problem ist, wenn man merkt, dass man doch mehr Rechenpower braucht. 
Dann nimmt man den STM Source und geht ein Controller höher. Beim XMega 
ist bei 32 MHz Schluss.
Obwohl ja Atmel mit der ASF bemüht ist das halbwegs kompatibel für 
andere Atmel Controller zu bekommen. ... naja

von Roby (Gast)


Lesenswert?

Nö. Nix 32 Mhz Schluss. Die neuen U Typen können 64 und höher :-)

von Zedd (Gast)


Lesenswert?

Wir reden aber hier von Datenblattangaben... ich lass meinen auch immer 
auf 48 MHz laufen... aber so sollte man ja nicht vergleichen!

Bitte 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
Noch kein Account? Hier anmelden.