Vor Jahren habe ich mir Atmel Studio fuer die AVRs angesehen und war recht beeindruckt. So eine nette Entwicklungsumgebung fuer umsonst, ohne Einschraenkungen gibt es immer noch nicht von vielen Herstellern. Heute interessieren mich die SAMD, SAMG und SAM 4 Chips allerdings wesentlich mehr und da ist meine Frage ob dafuer Atmel-Studio 6.1 auch was taugt? Soweit sind mir folgende Punkte aufgefallen: Download ist flott, der Serrver kann mit meine Kabelverbindung Schritt halten Installation dauert relativ lange Die Oberflaeche mag ich wirklich sehr Studio laeuft nicht auf Linux oder MAC aber das ist mir zusammen mit >> 90% der professionellen Benutzern egal Bisher habe ich nur kleine Programme in "C" geschrieben und ohne Probleme getestet, wo habt ihr Probleme? (Bitte nur ARM relevant) Auf meinem neuen (sauberen) Laptop hatte ich keinerlei Probleme Wuerde mich sehr ueber Feedback / Kommentare freuen.
Das Atmel-Studio setzt auf Microsoft Visual Studio auf. Das ist scheint für viele Leute aus dem MCU-Bereich ungewohnt und zu schwerfällig zu sein. Für normale Windows Entwickler ist hier aber wenig Umgewöhnung erfolderlich. Störend finde vor allem Atmels Update-System und den "App-Store", da beide nie so richtig zu funktionieren scheinen. Es gibt noch eltiche freie Entwicklungsumgebungen, die auf Eclipse aufsetzen. Mir persönlich ist das zu unaufgeräumt, aber das ist Ansichtssache sein. Eclipse-Basierte IDES: CooCox - Unabhängig, komplett frei, für etliche Cortex-MCUs LPCXpresso - NXP/Code, frei bis 256kb?, für NXP MCUs DAVE - Infineon, komplett frei?, für Infineon MCUs Code-irgenwas? - Texas Instruments, frei bis?, MSP430/TI ARM
Ich nutze die Eclipse C/C++ IDE, direkt von Eclipse.org und bin damit sehr zufrieden. (CDT-Plugin, makefile und Linkerscript selbst erstellt und Codesourcery oder Launchpad als GCC/GDB) Ist zwar nicht "Anfänderfreundlich" dafür kann ich alles das machen was/wie ich will.
Ist ein Anfänder ne Kreuzung aus nem Anwender und nem Anfänger?
Robert Teufel schrieb: > Studio laeuft nicht auf Linux oder MAC aber das ist mir zusammen mit >> > 90% der professionellen Benutzern egal dafür bietet atmel aber die asf und die toolchain ohne atmel studio als separaten download an, auch für linux :) und schon kann man seinen lieblings-edi damit verbinden
Erst mal danke an alle, die sich gemeldet haben. Ich hoffe noch auf Erfahrungsberichte mit Studio 6. Was alternativ genuetzt werden koennte ist mir sehr gut bekannt und nicht Teil meiner Frage. @Tim, Bisher die beste Antwort. Mir sind andere ARM IDEs wohl bekannt, bin allerdings speziell an Erfahrungen mit Studio 6.1 und SAM Microcontrollern interessiert. @Markus, Information ist gut, leider etwas an der Frage vorbei @j.t. Spassvoegel gibt's wohl in jedem Forum :) @Alex Wie gesagt, Linux und MAC OS sind nicht mein Ding, deine Anwort trifft genau den Punkt, den ich in der Frage ausgeschlossen hatte.
Das es Dir bisher gefällt ist die einzige korrekte Antwort: Weitermachen. Du kannst Dir ziemlich sicher sein, dass Du mit Visual Studio eine ausgreifte Oberfläche erhältst. Der Rest ist Geschmackssache.
:
Bearbeitet durch User
Wollt gerade mal meinen SAM3X8E (Arduino-Due) über Atmel Studio 6.1 und den SAM-ICE programmieren. Hab ein neues C-Projekt (GCC C Executable Project) aufgemacht, und das einzige was ich geändert habe ist, dass ich ein paar Warnungen eingeschaltet habe: -Wall -Wextra -Werror -pedantic -pedantic-errors Und was soll ich sagen... die Vorlage lässt sich nicht kompilieren, es gibt 72 Errors! Mach ich das ganze als C++-Projekt (GCC C++ Executable Project) kompiliert das ohne Probleme, 0 Errors, 0 Warnings, bei gleichen Einstellungen für die warnungen/Errors. 21 dieser Errors beruhen darauf, das in der core_cm3.h GCC extensions benutzt werden, die restlichen 51 Errors befinden sich in "startup_sam3xa.c" und beruhen auf "ISO C forbids conversion of function pointer to object pointer type". Das diese Warnungen/Errors nur wegen dem -pedantic kommen, ist mir schon klar, und mit den "Error: GCC extension" kann ich mich noch anfreunden, schließlich wir das Studio ja mit dem GCC ausgeliefert. Aber bei den restlichen Fehlern muss ich schon sagen: Meiner Meinung nach ist das schon ein ganz schöner Fauxpas, etwas auszuliefern, das nicht mal mit dem beigelegten Compiler einwandfrei baut. Meiner Ansicht nach muss das auch bauen, wenn ich die Fehlerflags des Compilers ausnutze, denn genau dazu sind die Flags ja da. Und ich will nicht den C++-Compiler benutzen müssen, oder meine Fehlereinstellungen runterschrauben müssen, nur weil ich C Programmieren und damit den C-Compiler benutzen möchte. Aber wahrscheinlich hab ich da schon wieder zu hohe Ansprüche... Das ist das einzige was mich gerade am Atmel Studio stört. Ansonsten hab ich damit keine Probleme, und benutze es sehr gerne. Grüße
> So eine nette Entwicklungsumgebung fuer umsonst, ohne > Einschraenkungen gibt es immer noch nicht von vielen Herstellern. Von wem denn nicht? > Probleme getestet, wo habt ihr Probleme? (Bitte nur ARM relevant) Also ich mag ja HEW am liebsten, aber durchgesetzt hat sich wohl eindeutig Eclipse. Klar, es ist lahm und ueberkompliziert, aber es ist Hersteller uebergreifend. Letzteres ist im profesionellem Umfeld wichtig wo man gerne auch mal mit unterschiedlichen Controllern rummacht. BTW: Arbeitest du jetzt fuer Atmel und willst ein bisschen promoten, oder was ist der genaue Sinn deines Postings? Olaf
@Robert Vielleicht hilft Dir der Link auch weiter: http://visualgdb.com/tutorials/arm/stm32/f4_discovery/ "STM32F4-Discovery tutorial with Visual Studio"
@ Olaf schrieb: >> So eine nette Entwicklungsumgebung fuer umsonst, ohne >> Einschraenkungen gibt es immer noch nicht von vielen Herstellern. > > Von wem denn nicht? Hi Olaf, Von wem denn? - NXP hat Einschraenkungen fuer LPCXpresso (code size) - Freescale hat Einschraenkungen fuer CodeWarrior (code size) - ST hat ?? gar nichts eigenes Discovery kommt mit Beispielen fuer IAR, Keil, Atollic; alle mit Einschraenkungen - TI hat Einschraenkungen fuer CodeComposer Studio (time or code size) Das sind meiner Meinung nach die Hauptakteure im general purpose Cortex-M3 Markt. Keine Einschraenkungen aber eben auch nicht Hauptakteure im ARM-Cortex Markt: - Cypress PSoC Creator (nicht Eclipse), PSoC ist ein Nischenprodukt. Wenn er genau passt, dann ist er fast nicht zu schlagen. - SiLabs Precision 32 (Eclipse) Das kann noch sehr interessant werden. Die Firma SiLabs zusammen mit den Energy Micro Geckos imponiert mir sehr. - Infineon DAvE (sorry meine alten Freunde, noch ist Infineon kein Hauptakteur hier aber wenn ihr Hilfe braucht das zu aendern ;) > Also ich mag ja HEW am liebsten, HEW hab ich schon lange nicht mehr angesehen (seit 2008). Da hat sich vermutlich viel verbessert. Im Jahr 2008 war HEW allerdings nicht gerade mein Lieblingstool. Das ist vermutlich so wie Sprachen. Bereits unsere Kinder "wissen", dass Deutsch sehr einfach ist, sie sind damit aufgewachsen. Fuer andere ist Deutsch hoellisch kompliziert ;) > aber durchgesetzt hat sich wohl eindeutig Eclipse. Bin ich noch nicht so ganz sicher. Im Bereich "alles ausser umsonst ist teuer" gibt es fast nur Eclipse aber es gibt eben auch Atmel Studio, basierend auf Visual Studio, MPLAB basierend auf Netbeans und auch bei den hochpreisigen IDEs existieren noch non-Exclipse IDEs. Allerdigns ist ein Trend klar ersichtlich, dass auch die Firmen mit den besten proprietaeren Compilern mindestens eine Eclipse Version anbieten. > Klar, es ist lahm und ueberkompliziert, aber es ist > Hersteller uebergreifend. Letzteres ist im profesionellem Umfeld wichtig > wo man gerne auch mal mit unterschiedlichen Controllern rummacht. > > > BTW: Arbeitest du jetzt fuer Atmel und willst ein bisschen promoten, > oder was ist der genaue Sinn deines Postings? Ne, bin kein Atmel Angestellter. Im Rahmen eines Projektes schaue ich mir verschiedene IDEs an und mit Atmel haben viele Forum Teilnehmer hier deutlich mehr Erfahrung als ich. Robert
:
Bearbeitet durch User
Markus Müller schrieb: > @Robert > > Vielleicht hilft Dir der Link auch weiter: > http://visualgdb.com/tutorials/arm/stm32/f4_discovery/ > "STM32F4-Discovery tutorial with Visual Studio" @Markus, Vermutlich werde ich in meinem Leben nicht mehr dahin kommen, wo ich mir eine eigene Anpassung einer IDE stricke. Meine Zeit ist einfach zu teuer dafuer. Trotzdem Danke fuer die Info. Robert
Robert Teufel schrieb: > Hi Olaf, > Von wem denn? > - NXP hat Einschraenkungen fuer LPCXpresso (code size) > - Freescale hat Einschraenkungen fuer CodeWarrior (code size) >... man kann hier noch Microchip hinzufügen obwohl kein ARM, die haben zwar eine kostenlose IDE und einen C Compiler, dieser ist aber auch eingeschränkt. Die kostenlose Variante kann lediglich kompilieren mit sehr limitierten Optimierungen. Will man Optimierung einschalten, kostet es was und zwar nicht wenig. Will man noch mehr Optimierungen, kostet es noch mehr (in der Pro Version). Natürlich je Arbeitsplatz
> Hi Olaf, > Von wem denn? Ist das nicht unhoeflich eine Frage mit einer Gegenfrage zu beantworten? .-) Mein Eindruck ist doch wie folgt. Es gibt im Prinzip immer zwei Moeglichkeiten fuer einen Controller Code zu erzeugen. Entweder ich kaufe mir einen Proficompiler (z.B von IAR) oder ich verwende den gcc. Ein Controllerhersteller liefert mir also entweder einen eingeschraenkten Compiler mit, oder es ist nur der gcc. Wenn mir ersteres nicht gefaellt dann installiere ich mir halt selber den gcc oder kaufe mir im umgekehrten Fall den Proficompiler weil mir Support oder eine Zertifizierung (z.B SIL) wichtig ist. Kennst du also einen Hersteller der einen unbeschraenkten Proficompiler mitliefert? Ich nicht, wuerde mich aber interessieren. Von daher waere also vielleicht noch interessant wie der Hersteller seine Compiler beschraenkt wenn man nicht gcc verwenden will. Bei Renesas, wo ich das zufaellig kenne, gibt es da eine Grenze von 64kb(M16C) oder 128kb(SH). Also fuer viele Controller garnicht existent weil der Controller weniger Flash hat. Oder aber es gibt fuer einen Controller gar keinen gcc. Da waere fuer private Bastler sicher auch interessant zu wissen weil ich so einen Controller privat niemals verwenden wuerde. > HEW hab ich schon lange nicht mehr angesehen (seit 2008). Da hat sich > vermutlich viel verbessert. Im Jahr 2008 war HEW allerdings nicht gerade Nein. Es ist eher so das Renesas von HEW weg will. Sie unterstuetzen es noch weiter weil sie ja eine riesige Entwicklerbasis haben, aber bei neuen CPUs ist es ihnen wohl lieber wenn Eclipse verwendet wird. BTW: Auch fuer IAR gibt es ja von IAR selber einen Patch damit man deren Compiler in Eclipse verwenden kann. (Kein Wunder, IAR im Original erinnert mich auch immer an das letzte Jahrtausend) Ich denke das zeigt wohin die Reise geht, die muessen schon ganz schoen unter Druck stehen das sie das machen. > teuer" gibt es fast nur Eclipse aber es gibt eben auch Atmel Studio, > basierend auf Visual Studio, MPLAB basierend auf Netbeans und auch bei Noe, das gibt es nicht. (so allgemein) Das gibt es nur fuer Atmels. Ich habe beruflich mit einer grossen Zahl unterschiedlicher Controller zutun, teilweise auch gerne in einem Projekt. Da will ich nicht eine Spezialumgebung fuer eine Familie verwenden. Das nervt dann einfach. Ausserdem ist eine Verwandschaft mit Visual Studio auch nicht gerade eine Empfehlung. Olaf
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.