Liebe Community, seit vielen Jahren arbeite ich nun schon mit Mikrocontrollern, bisher ausschließlich welche aus der Atmel AVR-Serie. Die funktionieren auch hervorragend, sind preiswert, und es gibt eine riesige aktive Community, wo man zu jedem Problem schnell Hilfe findet. Der AVR ist ja sozusagen der "Allerwelts-Controller". Immer öfter stoße ich in letzter Zeit jedoch an die Grenzen von integriertem SRAM, Flash-Speicher und Taktfrequenz. Hatte kurz darüber nachgedacht, auf die XMega-Serie von Atmel umzusteigen, aber die scheint sich ja nicht richtig durchgesetzt zu haben. Nun überlege ich, auf welche Architektur ich in Zukunft wohl am besten setzen sollte. Meine Wünsche: - Interner SRAM > 100 kByte, Flash > 1 MByte, Taktfrequenz > 64 MHz - Halbwegs gut zu beschaffen auch bei Standard-Händlern (Reichelt, etc) - In-System-Programmierbar, kein sündhaft teurer Programmieradapter - Große, lebendige Community, die einem bei Problemen/Fragen helfen kann Kurz gesagt: Quasi ein zeitgemäßer würdiger Nachfolger für AVR :-) Gehäuse mit feinem Pitch sind für mich (z.B. LQFP), so lange man sie von Hand löten kann (bitte keine BGA-Only-Controller). Mir war jetzt schon die STM32-Serie ins Auge gefallen. Die scheint meine Anforderungen sehr gut zu erfüllen. Sind diese Controller halbwegs weit verbreitet, so dass man Leute zum Nachfragen findet? Ansonsten bitte ich um eure weiteren Vorschläge :-) Grüße, Martin
Atmeltroll schrieb im Beitrag #4356890: > XMega-Atmel-Schrott kannst Du vergessen. Wenn schon, dann ARM Genau das schrieb ich doch, dass ich allmählich von Atmel weg will, weil ich langsam an die Limits komme, und der Xmega sich nicht richtig verbreitet hat... ARM ist ja nun keine konkrete Klasse von Mikrocontrollern. Welche entsprechen da gut oben genannten Anforderungen? STM32? Oder ist eine andere Serie eher zu empfehlen?
Hi Martin, ja, zu den STM32 hätte ich auch geraten. ISP programmier und debugbar, Programmieradapter sind auf den Discovery und Nucleo Boards mit drauf. Und es gibt sie auch bei Reichelt z.b. Und eine aktive Community. Für den Anfang würde ich zum STM32F407Discovery raten. Dafür gibt es die meisten Beispiele. Beste Grüße, Jan
Der ARM Cortex erlebt den gleichen Hype wie früher der x86. Mit den Dingern machst du also nichts falsch. Jeder, äähhh fast jeder, Halbleiterhersteller hat die Dinger im Porgramm.
Von der Leistungsfähigkeit her käme ich für die meisten Sachen eigentlich nach wie vor mit den AVRs gut zurecht. Ärgerlich sind inzwischen die Preise, insbesonders für die etwas grösseren wie Mega644. XMega fasse ich auch überhaupt nicht erst an. STM32 ist das Mittel der Wahl, und ein kleiner F0 ist deutlich preiswerter als ein Tiny2313, kann dafür aber deutlich mehr :-( Sprich: für Neuentwicklungen nehme ich keine AVRs mehr, wenn mehr als Tiny25 gebraucht wird. Aus meiner Sicht sind die AVRs tot, da sich die Preise mit sinkendem Marktanteil eher nach oben als nach unten bewegen und somit den Umstieg beschleunigen. Falsche Preispolitik. Und zu wenig RAM hatten sie schon immer.
Vielen Dank für eure Antworten! Das ist ja ziemlich einheitlich - dann werde ich mich wohl in Zukunft der STM32-Serie zuwenden :-) Grüße, Martin
Hallo ich fange auch gerade mit richtigen uControllern an, habe davor nur mit Arduino gearbeitet. ST scheint im Moment, jedenfalls in der Schweiz recht populär zu sein. Ich kann dir die STM32-Boards auch empfehlen. Hierzu kann ich dir auch noch zwei andere Sachen wärmstens empfehlen. STM32CubeMX ist ein Codegenerator. Das Konfigurieren von Peripherals ist damit echt einfach. Das ist auch so Middleware-Kram drin. Ist gratis schaus dir einfach mal an. Und schau dir auch mal KEIL-MDK an. Solange du keinen STM32F1xx verwendest kannst du den Cube sogar als "Plug-In" für Keil verwenden. Nebenbei ist Keil super zum Debuggen und wie bereits erwähnt enthalten die Nucleo-Boards bereits einen Debugger. Keil selbst hat eine Evaluation-Version die gratis ist und die schon echt verdammt viel bietet, also am besten auch mal reinstöbern. Hoffe konnte dir helfen ;)
:
Bearbeitet durch User
Ich stehe gerade vor der gleichen Entscheidung. Hab da selbst ein wenig recherchiert und bin auch zum Schluss gekommen: Ein ARM wirds werden, voraussichtlich STM32.
Martin schrieb: > - Interner SRAM > 100 kByte, Flash > 1 MByte, Taktfrequenz > 64 MHz XMC4500 bis TC1793 Martin schrieb: > - Halbwegs gut zu beschaffen auch bei Standard-Händlern (Reichelt, etc) > - In-System-Programmierbar, kein sündhaft teurer Programmieradapter > - Große, lebendige Community, die einem bei Problemen/Fragen helfen kann ST
Nachdem nun deine Frage hinreichend gut beantwortet ist, können wir ja mal einen anderen Blickwinkel betrachten. Wenn du wirklich moderne Microcontroller suchst, musst du dir die PSoC-Microcontroller von Cypress anschauen. Die gibt es nicht mit besonders schnellen Kernen oder besonders viel Speicher, aber das Systemdesign und die Entwicklung von Software dafür sind der Konkurrenz um viele Jahre voraus. Leider sind sie eher teuer, es gibt aber sehr günstige Prototyping-Boards, um die mal auszuprobieren. Danach hat man eigentlich überhaupt keine Lust auf was anderes mehr.
Martin schrieb: > Taktfrequenz > 64 MHz Schau dir deine Kandidaten da genau an bzw. überleg' dir, was du wirklich brauchst. Flash ist im Allgemeinen relativ langsam. Man kann ein wenig tricksen und zwei Flash-Bänke interleaven und dergleichen, aber gerade bei den einfacheren Controllern erreichst du die volle Taktrate real nur, wenn das Programm aus dem RAM abgearbeitet wird. Das trifft natürlich auch auf einen ggf. vorhandenen Cache zu, nur dass du dann u. U. nicht mehr vorhersagen kannst, ob es nun gerade im Cache liegt oder nicht. Alternativ musst du dann wichtige, schnell abzuarbeitende Teile halt explizit in den RAM platzieren und von da abarbeiten. Einen gewissen „Heimvorteil“ hat der Thumb-Code der Cortex-Ms hier, da er zu großen Teilen aus 16-Bit-Befehlen besteht, aber der Flash 32 Bit breit organisiert ist, d.h. es werden dann zwei Befehle in einem Speicherzugriff gelesen. Ansonsten ist SRAM halt relativ teuer, weil er viel Platz braucht.
Schön, dass das Thema auf so viel Resonanz stößt. Diesen Code-Generator STM32CubeMX schaue ich mir definitiv mal an. Normalerweise halte ich von Code-Generatoren nicht viel (arbeite seit vielen Jahren als C-Programmierer), aber gerade bei Mikrocontrollern gibt es ja diverse Hardware-Eigenheiten, die man gerne mal übersieht (diverse Flags in Registern setzen, etc.). Da ist das sicher immens nützlich. Der angesprochene Punkt, dass Flash-Speicher eigentlich viel zu langsam für die Taktfrequenz des Kerns ist, ist mir bewusst. Da hoffe/vertraue ich auf einen effizienten Instruction-Cache. Denn die Code-Abschnitte, die sehr viel Rechenzeit benötigen, bestehen ja häufig nur aus wenigen Instruktionen (z.B. ellenlange for-Schleife, die Daten im RAM abarbeitet). Gerade habe ich mir angeschaut, wie man SDRAM mit dem STM32 ansteuert. Zum Glück sehr einfach. Das ist ja z.B. auf dem etwas größeren Evaluation-Board des STM32F4 schon mit drauf (64 MByte SDRAM). Das ist ne ganze Menge, da gibt es endlich keine Speicher-Probleme mehr. Grüße, Martin
Martin schrieb: > Diesen Code-Generator STM32CubeMX schaue ich mir definitiv mal an. > Normalerweise halte ich von Code-Generatoren nicht viel... Dann bleibe bei deiner Ansicht. Das große Problem bei derartigen Codegeneratoren besteht darin, daß die Anwender dadurch noch viel weniger wissen als wenn sie sich selbst mit der Sache mental befassen müßten. Derzeit haben wir in einem anderen Thread genau sowas: da hat einer einen STM32F7xx und hat sich ein USB-CDC generieren lassen, was natürlich erstmal nicht enumeriert und nun fragt er hier an, wieso dies? und daß er eigentlich keine Lust hat, in die Quellen zu schauen oder gar die Funktionalität zu begreifen. Das, was da zunächst wie ein roter Teppich zum Erfolg aussieht, ist auf lange Sicht nur der breite Weg in die eigene Unfähigkeit. Für den Hersteller ist das gut, denn wer zu blöd ist, es selber zu können und daher auf den Codegenerator angewiesen ist, ist damit quasi wie der Galeerensklave an diesen Hersteller angekettet. Martin schrieb: > Der angesprochene Punkt, dass Flash-Speicher eigentlich viel zu langsam > für die Taktfrequenz des Kerns ist, ist mir bewusst. Da hoffe/vertraue > ich auf einen effizienten Instruction-Cache. Cache? Das ist zumeist die verkehrte Stelle bei den hier üblichen Cortexen. Viel mehr hilft, daß der Flash bei einigen Herstellern recht breit ausgelegt ist, also 64 oder 128 bittig. Bei NXP hatte ich das so etwa gelesen. Bei STM32 ist mir erinnerlich, daß man bei höherem CPU-Takt ne Menge Waitstates einlegen muß, bei 180 MHz waren das 8 Waitstates (wenn mich meine Erinnerung nicht trügt) - so daß es bei diesen Teilen gar nicht so sinnvoll ist, den CPU-Takt über 120 MHz hochzuschrauben. Das kostet dann bloß sinnlos Strom. Aber was Anderes sollte hier mal gesagt werden: Viele Cortex M4F kosten in kleineren Gehäusevarianten und mit Taktfrequenzen so um die 100 MHz kaum mehr als ihre kleineren Brüder M0..3. Dafür sind sie aber dank Gleitkomma deutlich leistungsfähiger - und das schafft mehr als ein hochgepuschter CPU-Takt. W.S.
@WS Das BS auf deinem PC hast du selbst geschrieben? Wenn nicht widerspricht das deinem Geschreibsel über Bibliotheken a la Cube und Co. Und was beschleunigt eine FP Hardware Unit, wenn ich nur Integer nutze?
Auch ATMEL hat schöne ARMs, z.B. SAM3. Das wäre eventuell sinnvoller, fallst du dann deine gewohnte Toolchain weiterverwenden kannst. Und die Kinetis-Serie von Freescale ist auch schön. PIC32 gibts auch noch. Auch da gibts Codegeneratoren übrigens ;-) Wenn du trotz besserer Alternativen zu STM32 wechseln willst: Kauf dir nicht diesen Modemist F4. der ist für fast alle Bastelprojekte unnötig kompliziert und sauft Unmengen an Strom. Ein F0 wie der STM32F072 ist ein echtes Upgrade von einem ATMEGA und viel handlicher. PS: Tu dir CUBE nicht an. Bei uns in der Arbeit haben die Firwareentwickler das sehr schnell wieder aufgegeben. Die Codequalität muss unter aller Sau sein. Drum: Wenn schon, dann Peripheral Lin.
mal so schrieb: > Der ARM Cortex erlebt den gleichen Hype wie früher der x86. Mit den > Dingern machst du also nichts falsch. Martin schrieb: > Genau das schrieb ich doch, dass ich allmählich von Atmel weg will Was hast du gegen den Atmel SAM3X8E? mit der ARM Cortex-M3 Architektur?
Felix C. schrieb: > Keil selbst hat eine Evaluation-Version die gratis ist und die schon > echt verdammt viel bietet, also am besten auch mal reinstöbern. Benutze es zwar nicht, aber für die F0-Serie von ST ist die Keil Full-Version kostenlos. Keil MDK-ARM for STM32F0 and STM32L0 provides software developers working with STM32 devices based on the ARM Cortex-M0 and ARM Cortex-M0+ cores with a free-to-use professional tool suite. Keil MDK is the most comprehensive software development system for ARM processor-based microcontroller applications. Keil MDK includes the ARM C/C++ Compiler, the CMSIS-RTOS RTX Kernel, and the µVision IDE/Debugger. The STM32 peripherals can be configured using STM32 CubeMX and the resulting project exported to MDK. Serial: U1E21-CM9GY-L3G4L
Martin schrieb: > Interner SRAM > 100 kByte Da wird die Auswahl aber relativ schnell dünn. Es gibt nicht allzuviele Kontroller mit mehr als 100 bzw. 128KByte RAM. Die Klasse der Cortex M0..M3 fällt damit schonmal weg. Ich selbst arbeite seit Jahren mit den M3 von ATMEL, aber da sind nur mit hängen und würgen 64-96K RAM drin. Bleiben also nur die Cortex-M4 oder darüber hinaus. Was die Preispolitik anbelangt, bin ich da auch nicht begeistert. Fast alle 2 Jahre kommt eine neue Kontrollerfamilie auf den Markt. Um die "neuen" zu pushen, werden die billig angeboten. Im gleichen Zug werden die alten im Preis erhöht, um sie für die Kunden weniger attraktiv zu machen. Als ich die SAM3 Kontroller in Projekten eingesetzt hatte, kosteten die um 3,50 bis 5,- Euro. Dann kamen die SAM4 raus und am selben Tag kosteten die SAM3 zwischen 5,- und 8,- Euro. Frechheit! Das ist in meinen Augen die Leute verars**t. Ich setze von denen nicht nur eine Handvoll ein. Insofern ärgern mich 1-3 Euro im EK schon sehr. Der Dollarkurs tat letztes Jahr sein Übriges. Die Zeiten wo man einen ATMEGA8 für unter 1,- Euro einkauft, sind wohl vorbei. Was die Hersteller anbelangt, würde mich mal interessieren, nach welchen Kriterien die von Euch ausgesucht werden. Also STM oder ATMEL oder NXP etc etc. Geht es dabei um den Preis der Teile oder der Entwicklungsboards? Mir kommt es so vor als ob die oft nur auf gut Glück herausgesucht werden. Obwohl die CPU bei allen gleich oder ähnlich ist, unterscheiden sich die Hersteller in der Peripherie teilweise gewaltig. Da sollte man genau überlegen was man machen will. Ich hatte mich z.B. vor 2-3 Jahren für die SAM3 von ATMEL entschieden, weil diese die leistungsfähigste SPI hatten. Mit automatischen Chipselects und allem Pipapo. Um Daten an 4 verschiedene externe Bausteine auszugeben benötigte der Kontroller 0% Programmlaufzeit, nachdem mal der DMA "angeschubst" war. Der Mitbewerber NXP war damals in dieser Funktion viel umständlicher. Der SAM3X, SAM3A ist jetzt nicht der schnellste Kontroller, hat aber eine sehr leistungsfähigste Peripherie. Er hat z.B. 32Bit Timer (komischerweise haben die Nachfolgetypen SAM4 nur 16Bit), was in vielen Fällen die Dinge sehr vereinfacht. Und es gibt wohl kein billigeres Einsteigerboard als das Arduino Due, zumindest wenn man es über die Bucht in China kauft. Wer ein bisschen mehr Hubraum benötigt, kann sich ja mal die SAMS7/SAMV7 anschauen. 300MHz, >256K RAM, FPU und weitestgehend Peripheriekompatibel mit den Vorgängern. Gruß Joachim
long long schrieb: > Und was beschleunigt eine FP Hardware Unit, wenn ich nur Integer nutze? mein lieber Rather Short, warum benutzt du nur integer, wenn du float hast und selbiges sogar mul und add in einem Takt erledigen kann? Ansonsten hat so ein M4F auch DSP-Funktionalität und wenn du nen guten Compiler wie den von Keil benutzt und ihm auch noch sagst, was du für ne CPU hast, dann macht der in den meisten Fällen aus deinem Geschreibsel nen Code, der deutlich effektiver ist als das, was auf nem M0 oder so überhaupt realisierbar ist. Das isses. W.S.
Du Oberdepp, ich nutzen nur Integer, weil meine Aufgabenstellung kein FP erfordert. ;-) In dem Zusammenhang oben hast du Dummfug gekritzelt. That s all! ;-)
Für einen Umsteiger von AVR ist es sicher das beste, gleich eine FPU und eine Memory Management Unit dabei zu haben. Obendrauf muss dann noch ein Betriebssystem und den Anwendungen (die vorher mit AVRs gemacht wurden) steht nichts mehr im Wege :-)) Dann läuft die "Blinky-LED" sicher gleich viel besser.
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.