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
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.
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
Der Hauptnachteil der XMega ist die fehlende 5-Volt Toleranz, der fehlende CAN-Controller und die propriaetaere Debugschnittstelle.
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
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.
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.
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
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.
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.
Nimm die Stellaris Serie von TI. Dazu gibts ein günstiges Launchpad.
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?
Ü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.
...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
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...
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.
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.
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
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.
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.
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
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
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.
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.
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.
@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.
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.
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.
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.
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.
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
> 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.
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.
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.
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.
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.
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?
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?
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.
>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
Nö. Nix 32 Mhz Schluss. Die neuen U Typen können 64 und höher :-)
Wir reden aber hier von Datenblattangaben... ich lass meinen auch immer auf 48 MHz laufen... aber so sollte man ja nicht vergleichen!
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.