Hallo zusammen! Da mir die guten alten ATMegas mittlerweile für einige GLCD-Anwendungen zu langsam werden (FFT aus Audio/Animationen etc). wollte ich mich langsam mal nach einem zukunftsträchtigen Nachfolger umsehen. Bei meiner Recherche (auch bezüglich DSP-Funktionalitäten, evtl. soll später mal ein bisschen was in Richtung Audio-Filterung etc. gehen) haben sich folgende Controller herauskristallisiert. Programmierung soll in C erfolgen *==STM32==* Pro: -Sehr schnell, sehr viele Funktionen -Dev-Board mit GLCD spottbillig (Discovery-Board, um 20€) -Freie Entwicklungsumgebung CooCox Con: -Community/Libraries? -Programmierung schaut komplexer/Umfangreicher aus um das gleiche zu erzielen wie z.B. beim AVR (Port-Init, PWM...) *==dsPic==* Pro: -DSP-Funktionen Con: -Community/Libraries? -mikroC-IDE zwar kostenpflichtig, aber viele Libraries enthalten -schon etwas betagt? Zum XMega habe ich mich noch nicht groß informieren können, aber Programmierung schaut ähnlich aus wie für die klassischen AVRs. Worin lohnt es sich Eurer Meinung nach am ehesten umzusteigen? Beste Grüße Sebastian
Für den STM32 gibt es die HAL-Library, und die beinhaltet auch sehr viele DSP-Routinen. FFT, Filter, alles dabei. Für Deien Anwendung würde ich gleich den STM32F4xx mit DSP-Befehlen nehmen. Gruß, Stefan
Also wenn du auf nem Mega schon einen guten Teil stehen hast, dann ist der Portierungs-Aufwand auf XMega natürlich am geringsten, du gewinnst aber auch am wenigsten an Leistung. Wenn du das ganze eh neu aufrollst (oder dein Code so gut portierbar ist), dann würde ich nich lange mit dsPIC und teurem Closed-Source Kram rumkleckern, sondern einfach mit STM32 und GCC richtig klotzen. Von der Unterstützung schenken sich die zwei nich viel und der STM is halt nach oben offen von der Performance....
Kann zu dsPic nix sagen, aber zu deinen Fragenzeichen beim STM32F4 (also Cortex M4): - Libraries gibts, als Grundlage bietet sich CMSIS direkt von ARM an und dann nimmst du entweder die HAL Lib von ST oder machst es zu Fuß, was auch gut funktioniert. - Es gibt eine DSP Lib, ebenfalls direkt von ARM (CMSIS DSP) und das Beste: optimiert auf Cortex M4 und M3. - Der Cortex M4 hat DSP Befehle und eine hardware floating point Einheit! - Community: Hier gibt es viele Leute für den STM oder auch die LPC Reihe von NXP), es gibt von ST direkt ein Forum, in dem ich relativ häufig fündig werde. Von mir keine persönliche Wertung, weil ich wie gesagt den PIC nicht kenne.
Vom dsPIC würde ich abraten. 16Bit-Architektur und nicht wirklich schnell. Von Microchip gibts den "neuen" PIC32MZ, der hat auch ne DSP drin und kann mit dem STM32F4 mithalten.
Müsste sich halt mal jemand zu äußern, der wirklich viel DSP-Kram macht und evtl. sogar mit beiden Conrollern mal gearbeitet hat und tatsächlich etwas über die Perfomance sagen kann... Little B. schrieb: > dem STM32F4 mithalten Es gäbe noch den F7, aber den halt im LQFP100 als Kleinstes :(
:
Bearbeitet durch User
Little B. schrieb: > "neuen" PIC32MZ Leider sind viele Komponenten im Chip (z.B. der ADC) kaum bis gar nicht nutzbar. Eine FPU ist derzeit auch nicht drin. Man muss also auf die neue Generation warten (PIC32MZxxxA) und hoffen ;-)
Es gibt auch noch die LPC43xx Serie. Ebenso mit CortexM4F-Kern und dazu noch einen M0-Kern. Wenn man mehr Rechenleistung haben möchte, ist dass ein guter Kanidat
Sebastian N. schrieb: > *==STM32==* > > Con: > -Community/Libraries? > -Programmierung schaut komplexer/Umfangreicher aus um das gleiche zu > erzielen wie z.B. beim AVR (Port-Init, PWM...) Egal welchen aktuellen µC Du verwenden wirst, komplexer als ein AVR sind sie alle; da mußt Du durch! Duschen ohne nass zu werden, das geht nicht ;-) Mein Rat wäre ein STM32F407-Discovery Board ohne weiteren Schnick-Schnack. Für < 20 € kannst Du testen und Deine 'Frustgrenze' ausloten ;-) Als IDE für den Anfang würde ich zu kostenlosen Demo-Versionen von IAR bzw. Keil raten. Abgesehen von der Codegrößenbegrenzung sind die einfach am besten. Wenn die Grunderfahrungen gemacht sind, ist emBlocks sehr angenehm. Wie auch immer, unabhängig von dem, was Dir hier geraten wird, mußt Du Deine eigenen Erfahrungen machen!
m.n. schrieb: > Als IDE für den Anfang würde ich zu kostenlosen Demo-Versionen von IAR > bzw. Keil raten. Wieso verwendet eigentlich niemand das TrueStudio? Damit bin ich am einfachsten klar gekommen.
Little B. schrieb: > m.n. schrieb: >> Als IDE für den Anfang würde ich zu kostenlosen Demo-Versionen von IAR >> bzw. Keil raten. > > Wieso verwendet eigentlich niemand das TrueStudio? Damit bin ich am > einfachsten klar gekommen. Bei IAR kann man zum einen mit 'live-watch' WÄHREND der Programmausführung globale Variablen anzeigen lassen und auch in den internen Registern herumspielen, wenn ich mich richtig entsinne und das nicht mit der HEW von Renesas verwechsel. Keil müßte das auch haben.
m.n. schrieb: > Little B. schrieb: >> m.n. schrieb: >>> Als IDE für den Anfang würde ich zu kostenlosen Demo-Versionen von IAR >>> bzw. Keil raten. >> >> Wieso verwendet eigentlich niemand das TrueStudio? Damit bin ich am >> einfachsten klar gekommen. > > Bei IAR kann man zum einen mit 'live-watch' WÄHREND der > Programmausführung globale Variablen anzeigen lassen und auch in den > internen Registern herumspielen, wenn ich mich richtig entsinne und das > nicht mit der HEW von Renesas verwechsel. Keil müßte das auch haben. Keil und auch emBlocks können das ebenfalls.
Jan K. schrieb: > ... emBlocks können das ebenfalls. Welche Version? Mit 2.20 schaffe ich es nur, wenn ich den Cursor auf eine Variable positioniere und dann kein bißchen mehr an der Maus wackel. Also eher zufällig. Gibt es auch eine Listenform, wo mehrere Variablen permanent aufgefrischt werden?
m.n. schrieb: > Jan K. schrieb: >> ... emBlocks können das ebenfalls. > > Welche Version? > Mit 2.20 schaffe ich es nur, wenn ich den Cursor auf eine Variable > positioniere und dann kein bißchen mehr an der Maus wackel. Also eher > zufällig. > Gibt es auch eine Listenform, wo mehrere Variablen permanent > aufgefrischt werden? 2.30, es gibt doch das Variablen Watch Fenster, da kannst du irgendwo einen Haken machen, "live update" oder so heißt das. Bin mir gerade aber nicht sicher, ob für jede Variable einzeln oder ob das für alle gilt.
Sebastian N. schrieb: > Zum XMega habe ich mich noch nicht groß informieren können, aber > Programmierung schaut ähnlich aus wie für die klassischen AVRs. Die physische Programmierung erfolgt nicht mehr über ISP, sondern über PDI. Die Atmel-Programmiergeräte beherrschen das, aber bei den billigen Noname-Teilen ist das nicht so gängig. (Die meisten Xmegas kann man alternativ auch über JTAG programmieren.) Von der Software her sind die Xmegas „aufgeräumter“ als die alten MegaAVR. Die einzelnen Hardwareblöcke sind dort jeweils in eigenen Registerblöcken enthalten, die über einen Strukturzeiger angesprochen werden. Wenn es mehrere gleichartige Blöcke gibt, unterscheiden sie sich dann nur in der Basisadresse. Insofern wiederum ist aber der Unterschied zwischen Xmega und den diversen ARMs nicht allzu groß, denn diese arbeiten in dieser Hinsicht sehr ähnlich. Als Pluspunkt beim Xmega wäre noch das Event-System, sofern du dafür eine Verwendung hast. Das hat Atmel auch in seine neueren ARMs übernommen (SAMD21 & Co.), weiß nicht, ob ST32 etwas Vergleichbares dazu bietet.
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >Als Pluspunkt beim Xmega wäre noch das Event-System, sofern du dafür >eine Verwendung hast. Das hat Atmel auch in seine neueren ARMs >übernommen (SAMD21 & Co.), weiß nicht, ob ST32 etwas Vergleichbares >dazu bietet. Naja, die Xmega sind schon nett und ein "Umstieg" vom normalen AVR auf Xmega ist nahezu trivial. Wenn gleich die Hardwaremodule sowohl in Anzahl als auch Fähigkeiten deutlich erweitert worden sind (DMA, Events, etc.), so ist die reine CPU-Power nur gering gesteigert, denn die CPU ist praktisch die gleiche mit gerade mal mäßig erhöhtem Takt (20 MHz -> 32 MHz). Gleiches gilt für RAM/Flash. Für Projekt mit nur moderaten Ansprüchen sind sie OK, sobald deutlich mehr CPU-Leistung und Speicher benötigt wird, würde ich heute ganz fix auf einen 32 Bitter gehen. Und gerade GLCD & Co sind solche Sachen! Beitrag "Re: Viel RAM am kleinen Controller"
> - Der Cortex M4 hat DSP Befehle und eine hardware floating point > Einheit! Kleiner Korrektur: Der M4 hat keine FPU, das hat nur der M4F. Gibt halt beides. STM32F4 sind aber Cortex M4F.
Guest schrieb: >> - Der Cortex M4 hat DSP Befehle und eine hardware floating point >> Einheit! > > Kleiner Korrektur: > Der M4 hat keine FPU, das hat nur der M4F. > Gibt halt beides. > STM32F4 sind aber Cortex M4F. Danke, hast Recht, kann aber leider nicht mehr editieren oben.
Zum Experimentieren finde ich den Nucleo F411 besser als ein F4 Discovery. Das Nucleo stellt mit dem ST-Link V2-1 auch ein CDC ACM Device zur Verfuegung, so das man mit einer USB Verbindung den Debugger verwenden kann und Debugausgaben ueber dem UART machen kann. SPI/I2C Bausteine zum Spielen gibt es dann als Arduino Shield.
Sebastian N. schrieb: > *==dsPic==* > > Pro: > -DSP-Funktionen > Con: > -Community/Libraries? > -mikroC-IDE zwar kostenpflichtig, aber viele Libraries enthalten > -schon etwas betagt? Microchip liefert Dir alles, was Du brauchst. Der Umstieg vom AVR ist so groß nicht, die Programmierung ist recht einfach, die Peripherie leistungsfähiger als bei AVR. Und die dspic33EP mit 70 MHz sind so langsam auch wieder nicht. Plus: DIL-Versionen erhältlich. fchk
Ingo L. schrieb: > Little B. schrieb: >> dem STM32F4 mithalten > Es gäbe noch den F7, aber den halt im LQFP100 als Kleinstes :( der CortexM7 von Atmel. LQFP64 - der kleinste M7 - das müsste man noch von Hand löten können
Hallo beisammen! oha, da sind ja eine ganze Menge Antworten zusammengekommen, wahnsinn! Nachdem die Mehrzahl vom STM32 so begeistert ist, hab ich mir mal folgendes Board bestellt: http://www.voelkner.de/products/586320/STMicroelectronics-Entwicklungsboard-STM32F429I-DISCO.html?ref=43&products_model=V682941 Wenn es draußen wieder kühler ist, fang ich damit mal an, man muss sich ja auch mal was zutrauen :). Danke nochmal!
So wärmeempfindlich ist der STM32F4 gar nicht ;-) Viel Spaß beim Ausprobieren, Stefan
also die DSPIC's sind leicht in ASSEMBLER zu programmieren und manche haben Audiodav's an Board, aber leider nur die FJ Typen. in meinem "Synthesizer" laufen 5 DSPIC's übertaktet mit 46 mips original 40. Bei meinem nächsten Synthesizer liegt schon ein Board mit CortexM4 bereit. Aber wie gesagt die DSPIC's schaffen bei ein Samplingrate von 46 mips 960Befehle/sample und da kann man schon was machen mit den Dingern, denn so schlecht sind die DSPIC's nämlich nicht und ich finde die neuen EP Typen mit 70 mips durchaus zeitgemäß!!
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.