Hallo, es gibt hier ja immer wieder die Diskussionen ob nun Atmega, Xmega oder ARM. Die Frage ist zwar auch berechtigt, aber darum soll es hier wirklich nicht gehen. Ich selber verwende noch keine ARM controller, bin aber grad am überlegen für welche Familie, bzw. Firma ich mich entscheiden sollte. Dabei ist mir aufgefallen, dass hier fast nur STM32 verwendet werden. Warum wird hier so gut wie keine SAM4 von ATMEL eingesetzt? Die Controller sind doch auch richtig gut und das AVR Studio 6 bietet doch eine perfekte Entwicklungsumgebung oder woran liegt das? Die XMC Reihe von Infineon finde ich auch richtig Interessant. Dazu gibt es ja auch den von Infineon kostenlos mit dazu gelieferten DAVE, mit welchem man Die Controller konfigurieren und programmieren kann. Leider sind die Controller aber nicht so einfach zu kaufen. Atmel - SAM http://www.atmel.com/microsite/sam_cortex/default.aspx http://www.atmel.com/products/microcontrollers/arm/sam4e.aspx Infineon - XMC http://www.infineon.com/cms/de/product/promopages/32-bit_industrial_microcontroller/index.html https://www.mikrocontroller.net/articles/XMC4500 STMicroelectronics - STM32 http://www.mikrocontroller.net/articles/STM32
Einfach mal ins Blaue geraten: Die STM32-Evalboards, z.B. STM32F4 Discovery, gibt es zu einem Spottpreis (noch günstiger als der Einzelstückpreis des STMs selbst).
:
Bearbeitet durch User
Hallo, ich hab bisher nur mit den SAM-Controllern etwas gemacht und finde die eigentlich ganz nett. Wenn man mit ASF + AS6 schon gearbeitet hat (z.B. für Xmega o.ä.) ist die Umstellung auf den Cortex nicht wirklich schwierig. Was mich ein bisschen gestört hat ist, dass beim Sam4S der Flash langsamer ist als die CPU-Frq. Wodurch man dann alles langsamer wird. Wie ist das eigentlich bei den STM32, bei 120Mhz Takt wie viele Takte braucht eine Instruktion bis sie vom Flash aus augeführt wird? René K. schrieb: > Einfach mal ins Blaue geraten: Die STM32-Evalboards, z.B. STM32F4 > Discovery, gibt es zu einem Spottpreis (noch günstiger als der > Einzelstückpreis des STMs selbst). Das denke ich auch, und das Discovery war meines Wissens nach schon relativ früh verfügbar im Vergleich zu den anderen genannten.
Mirco Controller schrieb: > Was mich ein bisschen gestört hat ist, dass beim Sam4S der Flash > langsamer ist als die CPU-Frq. Wodurch man dann alles langsamer wird. Es gibt von Atmel Varianten mit und ohne Cache, die mit Cache sind echt super flott, da werden die Verluste wg. Waitstates größtenteils eliminiert. Andere Hersteller wie ST versuchen das Problem mit einem speziellen HW Block zu eliminieren, am Ende kommt es aufs gleiche raus. Wir haben einen Crypto Algorythmus sowohl auf dem SAM4S als auch auf dem STM32 mit ART implementiert, beim gleichen Takt (dieselbe IAR Compiler Version) hat die Verschlüsselung 48s gedauert auf dem SAM4S ohne Cace, 36s mit Cache. Beim ST mit ART 38s. In unserem Fall war also der Cache die bessere Lösung, das hängt aber extrem von der Applikation ab. Gerade eben entdeckt: eine Dual Core CortexM4 + CortexM4F Maschine von Atmel :-) ist zwar für Metering Applikationen gedacht, aber ich sehe auch andere Anwendungsmöglichkeiten vor allem wegen 2 Cortex Cores http://www.atmel.com/devices/SAM4C16.aspx
...das ging aber schnell. ich habe im vergangenen Jahr sehr viel mit dem xmegas und dem AVR Studio 5 gearbeitet. Ich fand die Controller und die Entwicklungsumgebung echt super. Daher würde ich gern die SAM4 verwenden in der Hoffnung das mit denen auch alles so gut klappt. Beim Suchen habe ich aber so gut wie keine Beispiele gefunden und bin immer wieder nur auf die STM32 gestoßen, was mich jetzt etwas abschreckt.
Hi, die meisten Snippets die ich bisher benutzt habe sind aus den Beispielprojekten vom ASF. Gerade wenn du ein Devboard nimmst (z.B. das Sam4SXplaind) hast du zu fast jeder HW-Komponente ein Beispiel das zum Board passt.
@bluematrix, Die Antwort auf die Frage warum es hier vor allem STM32 Beitraege gibt ist sehr einfach, ST war der erst grosse Lieferant von Cortex-M3 basierenden MCUs. Davor gab es noch Luminary (jetzt TI) aber ST ist den Markt mit Macht angegangen und hat sehr viele Designs gewonnen. Erfahrungsgemaess dauert es eine Weile bis neue Chips genuegend Akzeptanz gewinnen und die dann hier in greosserem Masse vorkommen. So hat es mehrere Jahre gedauert bis der XMega hier richtig vertreten war und der urspruengliche AVR hat immer noch viel mehr Beitraege als der XMega. Zum Them SAM4, das ist definitiv ein konkurrenzfaehiges Teil. Allerdings ist er noch recht neu und deshalb wenig vertreten. Ausserdem wurde ja schon erwaehnt, dass es die Einsteigerboards fuer STM32 extrem guenstig gibt, was fuer den SAM4 in diesem Masse noch nicht zutrifft. Akzeptanz in diesem Forum ist tatsaechlich oft an den Preis der Boards gekoppelt und spiegelt nur bedingt die Akzeptanz im professionellen Bereich wieder. Der XMC hat es etwas schwer, weil er Infineon intern Konkurrenz hat und man die Kunden des XC2000 und TriCore nicht zu sehr beunruhigen moechte. Als weitere Option kannst du dir noch die LPC1xxx oder LPC4xxx von NXP anschauen, sind definitv auch schick, schnell und es gibt dafuer auch guenstige Boards. Noch etwas zum Thema Entwicklungsumgebung; das ist bereits heute und noch mehr in der Zukunft das Unterscheidungsmerkmal schlechthin. Nimm eine gewohnt Entwicklungsumgebung und du hast dein Projekt sofort um ein paar Wochen verkuerzt. Also wenn du mit AVRStudio 6 vertraut bist, dann sollten auch die 40-50 Euro fuer ein Board kein Hindernis sein. Gruss, Robert
Hi, ich denke ein Teil der Attraktivität der STM32 macht auch die Library von ST aus. Damit sind viele Probleme echt fix und klassenübergreifend (STM32F0 bis F4) erschlagen. Mit Coocox gibts auch eine Entwicklungsumgebung in die das Ganze gut integriert ist. Außerdem ist auf den Entwicklungsboards direkt ein Programmier/Debuggerät mit drauf, welches sich auch für Eigenentwicklungen nutzen lässt. Bzgl. der Flash Ausführung: Der Flash hat schon mehr Verzögerung als bei den anderen. ST hat aber wohl einen Zwischenspeicher eingebaut, so dass nach einem Sprung quasi instantan weiter Code ausgeführt werden kann. Liebe Grüße, Jan
Gegen XMC spricht zumindestens die Lizenz, die man beim Herunterlader von Datenblaettern abnicken muss. Gegen Atmel spricht m.e.a. die nicht vorhandende 5-Volt Toleranz der Eingaenge. Systeme mit gemischten Versorgungsspannungen sind doch haeufiger als man denkt...
Robert Teufel schrieb: > Also wenn du mit AVRStudio 6 vertraut bist, dann > sollten auch die 40-50 Euro fuer ein Board kein Hindernis sein. die xplain kits mit debugger gibts für 29USD, die neuen Xplain pro ab 39USD, also ob ein board nun 10Euro oder 20Euro kostet, das ist so als würde man zum Tanken extra 20km weiter fahren um 2cent einzusparen. Ich finde die Hersteller sollten schon kostendeckend arbeiten, und nicht unbedingt die boards gratis hinterherwerfen die dann meistens irgendwo verstauben da man zwar mit einem board schön die MCU kennenlernen kann, aber das wars dann meistens auch schon. ich finde Atmel hat hier guten weg eingeschlagen. Die Xplain kits als die low cost Variante zum kennenlernen Die Xplain Pro kits mit denen man auch mal ein Prototyp erstellen kann dank der Wings auch mal neue Technologien erproben kann (finde das OLED display upgrade sehr interessant). Und dann die vollwärtigen Evalkits die dann halt auch etwas mehr kosten, dafür aber auch ein Display und komplette Kommunikationsports bieten. Hier schenkt sich meistens auch nicht viel, wenn man die Preise eines ST Evalkits und Atmel Evalkits vergleicht sind sie für uns alle meistens zu teuer. Wobei teuer und billig alles relativ ist, mein Tankstellenbsp. heute der Diesel für 1.48Euro und alle schreien wie teuer der ist. Wenn in zwei stunden Der Preis auf 1.45Euro fällt rennen alle hin wie bekloppt weil der Sprit billig ist ;-)
Ich habe im vergangen Monat im Rahmen des Praxissemesters mit einem SAM4S Xplained Pro Board zutun gehabt, privat habe ich mir jetzt hauptsächlich aufgrund des Preises ein STM32F3Discovery zugelegt. Ich kann das Atmelboard nur empfehlen. Die mitgelieferte IDE ATmel Studio 6 ist super und das Reference Manuel von Atmel ist im Vergleich zu dem von ST deutlich verständlicher und besser erklärt.
Hi! Ja, ich weiß dass das Thema schon fünf Monate alt ist - für mich z.B. aber derzeit aktuell... Bei mir stellt sich auch gerade die Frage: 1) STM32 wegen der vielen Leute die diesen Nutzen und bei Fragen bestimmt eine Idee hätten oder 2) Atmel ARMs wegen der 800€ weniger IDE kaufen (Finde das Coocox nicht so prall) und weil ich die Visual Studio IDE eigentlich schon kenne... Was ein Dev-Kit kostet ist erst einmal egal. Gibt es zum heutigen Zeitpunkt da interessante "Wendungen" oder so aus der Sicht der Leute die auch schon vor der Frage standen? Grüße, Toni
Toni schrieb: > Gibt es zum heutigen Zeitpunkt da interessante "Wendungen" oder so aus > der Sicht der Leute die auch schon vor der Frage standen? Ich bin aus diesem Grund (Support, IDE, Libraries) bei PIC32 gelandet. Ob in Deinem Chip ein ARM oder MIPS drinsteckt, interessiert eigentlich nicht wirklich - das ganze wird ohnehin in C programmiert, und damit kommst Du mit dem eigentlichen Kern nicht in Berührung. Dafür spricht auch die Verfügbarkeit von kleinen Varianten, auch DIL. fchk
Hi Frank. PIC kommt mir nicht mehr ins Haus ;) Damit habe ich damals keine guten Erfahrungen machen können. Für mich käme wirklich nur STM oder Atmel in die Auswahl. Danke trotzdem!
Toni schrieb: > Für mich käme wirklich nur STM oder Atmel in die Auswahl. Ich weiss dass hier im Forum NXP unterrepräsentiert ist, aber die ARM Compiler und Libraries sind "deutlich" gepflegter als bei STM oder Atmel. Die Boards sind ebenso günstig im Bereich 10-20 EUR Nebenbei hat NXP als Einziger ARM auch als DIP, und STM und Atmel haben auch keine Multicore M4 mit 200 MHz.
Mal was neues: http://www.ti.com/tool/EK-TM4C1294XL Ethernet mit integriertem PHY und die Standard Peripheral Library finde ich wesentlich angenehmer als die von ST. Leider ist die Informationsdichte noch etwas gering da sehr neu. Werde irgendwann diese Woche auch noch eine Anleitung schreiben, wie man eine offene Entwicklungsumgebung unter Linux einrichtet.
>Was mich ein bisschen gestört hat ist, dass beim Sam4S der Flash >langsamer ist als die CPU-Frq. Wodurch man dann alles langsamer wird. >Wie ist das eigentlich bei den STM32, bei 120Mhz Takt wie viele Takte >braucht eine Instruktion bis sie vom Flash aus augeführt wird? (Zum xten Mal) Bei den meisten (bsp ST,NXP,Atmel,Freescale,Nuvotr. ) läuft der Flash nur mit ca 30MHz. Cache (egal wie die es nennen) wirkt nur bei linearem Befehlsstrom. Einige Japaner haben schnelleren Flash.
Toni schrieb: > Hi Frank. > > PIC kommt mir nicht mehr ins Haus ;) > Damit habe ich damals keine guten Erfahrungen machen können. Wahrscheinlich war das die alte PIC16/PIC18 Architektur. PIC24/PIC32 ist komplett was anderes. fchk
Moin, Ich finde die CoIDE von CooCox auch nicht so toll. Als Alternative gibt es Em::Blocks. Die finde ich schon deutlich besser als die CoIDE. Deshalb würde ich dir trotzdem zu STM32 raten. Die sind recht günstig (auch die Endwicklungsboard) und bieten sehr viel Peripherie (Ethernet/USB FullSpeed, HighSpeed) und mehr Leistung (180MHz / 225DMIPS). Im Bereich Cortex M schätz ich mal ist STMicro zurzeit führend. http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks Moritz
MCUA schrieb: > Bei den meisten (bsp ST,NXP,Atmel,Freescale,Nuvotr. ) > läuft der Flash nur mit ca 30MHz FTDI will beim Start den gesamten Flash in ein Shadow-RAM laden: http://www.ftdichip.com/MCU.html
Lothar schrieb: > auch keine Multicore M4 mit 200 MHz. Atmel hat Multicore M4, sogar 1x M4 + 1x M4F. Siehe SAM4C Hat Nxp sowas? Technisch gesehen sehe ich Atmel stark am Aufholen. Mein aktueller Lieblingscontroller ist der SAM4E: http://www.youtube.com/watch?v=ICP42gZZK6U&feature=player_embedded
Paul schrieb: > Technisch gesehen sehe ich Atmel stark am Aufholen. Mein aktueller > Lieblingscontroller ist der SAM4E: Findet man im Internet auch irgendwelche Tutorials über die Atmel SAM? Gruß Felix
Paul schrieb: > Atmel hat Multicore M4, sogar 1x M4 + 1x M4F. Siehe SAM4C > Hat Nxp sowas? NXP hat immerhin 1x M4F + 2x M0 mit 204 MHz und 80MHz ADC, und das Board gibt es für 18 EUR (das nehmen die nämlich als Debugger, kann man aber mit eigenen Programmen flashen): http://www.nxp.com/products/microcontrollers/cortex_m4/LPC4370FET256.html http://www.watterott.com/de/LPC-Link-2 Außerdem ist die Performance vom SAM4C nicht so überragend sonst hätte Atmel den SAMA5 nicht gebracht.
Lothar schrieb: > Paul schrieb: > Atmel hat Multicore M4, sogar 1x M4 + 1x M4F. Siehe SAM4C > Hat Nxp sowas? > > NXP hat immerhin 1x M4F + 2x M0 mit 204 MHz und 80MHz ADC, und das Board > gibt es für 18 EUR (das nehmen die nämlich als Debugger, kann man aber > mit eigenen Programmen flashen): > > http://www.nxp.com/products/microcontrollers/corte... > http://www.watterott.com/de/LPC-Link-2 > > Außerdem ist die Performance vom SAM4C nicht so überragend sonst hätte > Atmel den SAMA5 nicht gebracht. Sam4c ist ein mcu, sama5 ist eine mpu fuer ganz andere applikationen wie highend gateway, hmi usw. Sam4c ist auch nicht dafur entwickelt worden um high performance zu haben, sondern fuer einen speziellen markt und smart meter applikationen. Dabei kann der m4 core die kommunikationsstacks und applikation bedienen, wahrend der m4f fuer die metrology zustaendig ist und trotzdem die notwendige trennung von metrology code und application code erfuellt. Trotzdem kann man die zwei herzen gut fuer rechenintensive aufgaben nutzen
thorsten schrieb: > Sam4c ist ein mcu, sama5 ist eine mpu fuer ganz andere applikationen wie > highend gateway, hmi usw. Laut Atmel-Werbung nicht: es wurde ein ARM9-Nachfolger gesucht, und man war mit der M4 Performance unzufrieden, einen M5 gibt es (noch) nicht, daher hat man den A5 genommen, der "eigentlich" ein Applikations-Prozessor ist. Die Peripherie vom SAMA5 zeigt aber auf Mikrocontroller Anwendungen (CAN, SPI). Natürlich kann man dank MMU den SAMA5 auch für Linux nehmen, aber dafür gibt es anderswo schnellere, billigere, und genau so stromsparende A7
Kennt vielleicht jemand ein Tutorial welches auf die SAM4S ausgelegt ist. Finde nut tuts zu den STM ARMs. Danke ;)
:
Bearbeitet durch User
Dominic S. schrieb: > Kennt vielleicht jemand ein Tutorial welches auf die SAM4S ausgelegt > ist. Finde nut tuts zu den STM ARMs. > > Danke ;) Ich habe auch schon lange danach gesucht, aber nichts gefunden.
Felix L. schrieb: > Dominic S. schrieb: >> Kennt vielleicht jemand ein Tutorial welches auf die SAM4S ausgelegt >> ist. Finde nut tuts zu den STM ARMs. >> >> Danke ;) > > Ich habe auch schon lange danach gesucht, aber nichts gefunden. Der einfachste Weg: Xplained-Board oder EK von Atmel + Atmel Studio, mit Datenblatt die ASF-Beispiele durchgehen, da gibt es die ganz einfachen mit blinkenden LEDs bis hin zu Beispielen für die einzelnen Komponenten (ADC, UART usw.) Es wird sich kaum jemand die Mühe machen ein Tutorial zu erstellen, das einen völlig anderen, vermeintlich einfacheren, Weg als die ASF geht. Das Initialisieren der Clock oder einen GPIO-Interrupt zu benutzen ist eben relativ komplex auf einem ARM. Hat man das ASF-Prinzip erstmal halbwegs verstanden, kann man neue Sachen dann relativ schnell umsetzen.
hä schrieb: > Wer oder was ist denn ein ASF und findet man das? Das ist das Atmel Software Framework: http://asf.atmel.com Thomas F. schrieb: > at man das ASF-Prinzip erstmal halbwegs verstanden, kann man neue > Sachen dann relativ schnell umsetzen. Das ist das Problem :D Gruß Felix
Thomas F. schrieb: > Das Initialisieren der Clock oder einen GPIO-Interrupt zu benutzen ist > eben relativ komplex auf einem ARM. Bei den NXP ARM eben nicht weil die die Peripherie von den NXP 8051 "geerbt" haben. Bei den "Bastlern" haben sich aber die deutlich komplexeren STM32 durchgesetzt. Hier mal ein NXP LPC1700 GPIO-Interrupt (Taster an P0.23, LED an P1.25): void EINT3_Init(void) { IO0INTENR_bit.P0_23 = 1; // ext irq on rising edge (= button release) SETENA0 |= 1<<(EINT3_IRQ); // ext irq all port pins enable (NVIC) } void EINT3_IRQHandler(void) { FIO1PIN_bit.P1_25 ^= 1; // LED toggle IO0INTCLR_bit.P0_23 = 1; // ext irq clear CLRPEND0 |= 1<<(EINT3_IRQ); // ext irq all port pins clear pending (NVIC) } Die Clock braucht man u.U. gar nicht initialisieren, wenn der interne Oszillator reicht, der läuft nämlich als Default.
Lothar schrieb: > Thomas F. schrieb: >> Das Initialisieren der Clock oder einen GPIO-Interrupt zu benutzen ist >> eben relativ komplex auf einem ARM. > > Bei den NXP ARM eben nicht weil die die Peripherie von den NXP 8051 > "geerbt" haben. Bei den "Bastlern" haben sich aber die deutlich > komplexeren STM32 durchgesetzt. Hier mal ein NXP LPC1700 GPIO-Interrupt > (Taster an P0.23, LED an P1.25): > Mit der ASF ist das nun auch nicht so komplex: http://asf.atmel.com/docs/latest/sam4s/html/sam_pio_quickstart_use_case_2.html Man sollte halt einmal im ASF-Code/Datenblatt nachsehen, was die benutzten Funktionen/Makros machen.
Auf gallery.atmel.com gibt es fuer den sam4l ein paar trainings Hat mir den einstieg in asf erleichtert Kennt man einen sam4 dann kennt man alle
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.