Hallo, mal eine Frage in die Runde: Welche Entwicklungsumgebung / Softwarepaket ist bei euch hoch im Kurs und welche würdet ihr eher meiden? Ich sehe im Moment die Simplicity-IDE von Silabs ganz weit vorne, sie ist Freeware und hält alles wunderbar zusammen was zu einem Controller dazu gehört. Auf Platz 2 kommt wohl Harmony mit der ich allerdings erst oberflächlich gearbeitet habe, die aber ebenfalls eine gute Übersicht zu bieten scheint, gleichzeitig Freeware und für alle Betriebssysteme frei. Auf Platz 3 würde ich das Atmel-Studio einordnen, wobei dieses nur auf Windows ausgelegt ist und somit einen Minuspunkt erhält... Für die Controller von ST und von TI sehe ich auf Seiten der IDEs einige Probleme. Mit ST komme ich bisher so überhaupt nicht zurecht, dass ist für mich irgendwie ein Flickenteppich aus Anbietern und Tools, dass ich garnicht recht weiß, wie ich ein Evalboard mal testen könnte... bin schon total entnervt... Ebenso ist es mit den Controllern von TI, wobei hier immerhin das IAR-Studio durch eine Code-begrenzte Freeware-Version eine brauchbare IDE bietet. Wie sind so eure Erfahrungen mit den unterschiedlichen IDEs und zugehörigen Softwarepaketen, die einem das Leben einfacher machen können?
>Auf Platz 3 würde ich das Atmel-Studio einordnen, wobei dieses nur auf
Windows ausgelegt ist und somit einen Minuspunkt erhält...
Ach ja. Weshalb wuerdest du unter einem anderen OS entwickeln wollen ?
Weil iOS so kuschelig ist ? Weil Linux so praktisch ist ?
Oder D. schrieb: >>Auf Platz 3 würde ich das Atmel-Studio einordnen, wobei dieses > nur auf > Windows ausgelegt ist und somit einen Minuspunkt erhält... > > Ach ja. Weshalb wuerdest du unter einem anderen OS entwickeln wollen ? > Weil iOS so kuschelig ist ? Weil Linux so praktisch ist ? Es soll tatsächlich Leute geben, die haben einen Apple oder Linux-Rechner rumstehen und arbeiten sogar damit. Dürfen die keine Software entwickeln?
Völlig absurd finde ich das Kriterium nicht. Erfahrungen habe ich mit TI CCS und Freescale Kinetis Studio. Beides basiert auf Eclipse. TI ist eine Lösung "aus einem Guss", man installiert CCS, steckt den Debugger an und legt los. Freescale dagegen hat eine ziemliche Toolchain, bei der man in verschiedenen Stufen jeweils zwischen verschiedenen Herstellern wählen kann. Ich habe erst mal einen Tag gebraucht, bis ich die Zusammenhänge kapiert hatte. Dafür kann man hier viel zusammenklicken, was man bei TI zu Fuß implementieren muss. Max
OS wird überschätzt, hauptsache compiler, editor, binutils und webbrowser laufen stabil und schnell.
Makefile + Guter Texteditor (oder beliebige IDE). Gleiche Umgebung für jeden Controller. Gleiche Umgebung auf jedem OS. Compiler + Git/SVN Checkout und man hat alles was man braucht. Keine Abhängigkeit von irgendeiner IDE (Version). Build ist automatisierbar für Test/Build/Paketserver. Deutlich transparenterer Build Vorgang (z.B. compiler flags, linker skript, etc.). Im Fehlerfalle versteht man deutlich besser was im Hintergrund passiert. Keine "geheimen" Source-files mit einkompiliert. Keine Bindung an Controller eines Herstellers. da1l6
Du hast die universellen IDE's vergessen, zum Beispiel Netbeans, Eclipse und IMHO auch Visual Studio.
IDE schrieb: > Hallo, > > mal eine Frage in die Runde: > > Welche Entwicklungsumgebung / Softwarepaket ist bei euch hoch im Kurs > und welche würdet ihr eher meiden? > > Ich sehe im Moment die Simplicity-IDE von Silabs ganz weit vorne, sie > ist Freeware und hält alles wunderbar zusammen was zu einem Controller > dazu gehört. > > Auf Platz 2 kommt wohl Harmony mit der ich allerdings erst oberflächlich > gearbeitet habe, die aber ebenfalls eine gute Übersicht zu bieten > scheint, gleichzeitig Freeware und für alle Betriebssysteme frei. > > Auf Platz 3 würde ich das Atmel-Studio einordnen, wobei dieses nur auf > Windows ausgelegt ist und somit einen Minuspunkt erhält... > > Für die Controller von ST und von TI sehe ich auf Seiten der IDEs einige > Probleme. > > Mit ST komme ich bisher so überhaupt nicht zurecht, dass ist für mich > irgendwie ein Flickenteppich aus Anbietern und Tools, dass ich garnicht > recht weiß, wie ich ein Evalboard mal testen könnte... bin schon total > entnervt... STM32CubeMX für die Konfiguration und Codegenerierung (ähnlich Microchips Harmony Configurator). Gibt es eigenständig und als Eclipse-Plugin, OpenSTM32 (Eclipse-basiert) als IDE. Die div. Discovery-Boards sind in CubeMX hinterlegt, sodaß selbst beim STM32F7 inkl. Peripherie innerhalb von ein paar Minuten was lauffähiges generiert werden kann. em::Blocks/Code::Blocks wäre für die STM32 auch noch eine Möglichkeit, gerade wenn man nicht den Eclipse-Overhead haben will > Wie sind so eure Erfahrungen mit den unterschiedlichen IDEs und > zugehörigen Softwarepaketen, die einem das Leben einfacher machen > können? Benutze eigentlich fast nur VS, NetBeans (MPLAB X), em/Code::Blocks. Eclipse ist, selbst wenn es direkt installiert ist und nicht in einer VM läuft und an div. Schräubchen gedreht wurde, langsamer als VS und NetBeans oder em/Code::Blocks. @Reine Editoren + Makefile: Wer auf die ganzen Produktivitätsfeatures aktueller IDEs verzichten kann/will oder keine autom. kontextsensitiven Hilfen bei der Konfiguration der Controller oder der Arbeit mit den div. Frameworks braucht, gerne. Bei größeren Projekten läuft meist sowieso irgendwo ein eigener Build Server und entsprechende Software zur Versionsverwaltung und es ist egal wie die Commits, Pulls etc. zustandekommen
Atmel Studio (also das auf VisualStudio aufbauende) ist mittlerweile völliger Schrott. Das habe ich jetzt nach einem guten Jahr Quälerei damit festgestellt. Immer mal wieder Abstürze, die Unterstützung ist lachhaft. VisualAssistX nervt einfach mehr, als dass es hilft, und die internen Funktionen (z.B. ne stinknormale Suchfunktion) sind richtig bescheiden frickelig. Ohne VisualAssist krieg ich keine gescheite Intellisense hin. Irgendwie ist der ganze Editor vor 10 Jahren mal stehen geblieben - selbst der simpelste Texteditor von KDE (KWrite/Kate) machen mehr Spaß und sind zügiger zu bedienen. Die Integration der Atmel-Tools in den VisualStudio-Unterbau ist m.M.n. auch recht dürftig bis unflexibel. Vieles verschwindet hinter Dialogen und man kann entweder nur sehr beschränkt eingreifen oder man schreibt doch wieder sein eigenes Makefile... Das integrierte Programming-Tool wäre besser in einem eigenständigen kleinen Programm aufgehoben. Im Prinzip muss man jetzt das ganze VisualStudio installieren, nur um den MK2 zu bedienen. Oder man nimmt avrdude und schreibt doch wieder ein eigenes Makefile... Für kleine Controller benutze ich daher fast nur noch Kate unter KDE und ein simples Makefile. Für größere und für Desktop nehm ich gleich QtCreator her. Der hat zwar seine Stärke eigentlich eher, naja, eben mit Qt, aber als Editor in größeren C(++)-Projekten ist QtCreator einfach nur unschlagbar und schnell.
Nase schrieb: > Im Prinzip muss man jetzt das ganze > VisualStudio installieren, nur um den MK2 zu bedienen. Wenn es nur um's programmieren geht, schmeiß ich auf die betreffenden Rechner schnell das AVR-Studio drauf (4.xx). Ohne Schnickschnack, ohne C-Compiler, nur das reine Studio. Das ist klein, schnell und funktioniert für diesen Zweck ausgezeichnet.
Oder D. schrieb: > Weil Linux so praktisch ist ? Weil Linux eine gigantische Entwicklungsumgebung ist. Deswegen. ;-)
da1l6 schrieb: > Makefile + Guter Texteditor (oder beliebige IDE). +1 So siehts aus. Am Anfang vielleicht hart aber schon nach ner Woche und von da an in alle Zukunft zahlt es sich doppelt und dreifach wieder aus wenn man ohne Ketten und Fußfesseln arbeiten kann und die Tools auf der selben Seite kämpfen wie man selbst und nicht gegen einen.
Rufus Τ. F. schrieb: > da1l6 schrieb: >> Makefile + Guter Texteditor (oder beliebige IDE). > > Und kein Debugger. Steinzeit. Wo hat er geschrieben daß er keinen Debugger verwenden will?
Bernd K. schrieb: > Rufus Τ. F. schrieb: >> da1l6 schrieb: >>> Makefile + Guter Texteditor (oder beliebige IDE). >> >> Und kein Debugger. Steinzeit. > > Wo hat er geschrieben daß er keinen Debugger verwenden will? Muss man halt auch relativieren. Wenigstens auf den meisten 8bittern macht Debuggen eh keinen Spaß :-)
Davon ausgehend, das ich nur Atmel µC habe das Atmel Studio 7. (die 6x war ein Grauss mit der der veralteten Umgebung VS 2003!?). Kann die aufgezählten Probleme überhaupt nicht nachvorziehen. Kenne ansonsten im Linuxbereich nur das Eclipse. Aber egal welche Eclipse IDE inkl. div Plugins. So richtig überzeugen konnte mich diese nie. Auf Linuxbasierten Systemen nutze ich für einfache Sachen nur Geany als Texteditor. Den Terminalbefehl habe ich mir entsprechend mit eingebaut unter den Shortkeys.
Meine Nummer 1: GCC, CMake, GDB und Sublime - skalliert - unterstützt unterschiedliche Controller im gleichen Projekt - integration anderer Tools und eigene build target sind leicht möglich
Welch Zufall: Das Atmelstudio 6.x habe ich heute endgültig runtergeworfen. Windows wollte immer ein Update für das darunterliegende Visualstudio installieren und ist immmer gescheitert und immer das ganze Update blockiert. Ich war auch überrascht dass das Teil so wenig bietet. Hauptsächlich habe ich es wegen des Simulators installiert für 8-Bitter, ist aber eher ein Scherzartikel, ein Logikprotokollanalyzer ist da viel nützlicher da man immer auch Peripherie an einem MC dranhängen hat. Also mir reicht die Arduino-"IDE", dort entwickle ich in plain avr-gcc, debugger brauche ich nicht oder viel zu selten. Da reicht meist ein printf, serielle Schnittstelle oder ne blinkende Diode um gewisse Dinge zu checken. Manches mache ich auch in sublime + plus bashscript für building (ich hasse make), das sind meist eh nur drei Zeilen. Manches wandert auch in git, z.B. eigene Libs.
da1l6 schrieb: > Makefile + Guter Texteditor (oder beliebige IDE). > > Gleiche Umgebung für jeden Controller. > Gleiche Umgebung auf jedem OS. Bernd K. schrieb: > +1 So siehts aus. Ha! O ha! Ihr lauft hiermit Gefahr, von all den IDE-Fans genauso ausgebuht zu werden wie ich. Eines habr ihr noch vergessen: einen Standalone-Brenner (egal wie und womit). Und siehe da, selbst einer unserer heißgeliebten Mods fängt an zu buhen: Rufus Τ. F. schrieb: > Und kein Debugger. Steinzeit. Antwort: Nö. Wer richtig seinen Quellcode schreiben kann, hat herzlich wenig Verwendung für einen (in die IDE integrierten) Debugger. WEIL: blöde Schreibfehler und Unachtsamkeiten findet der Compiler im strikt Modus heraus und alles Andere an Bugs oder Nicht-Funktionalitäten findet man per Debugger ohnehin nicht. Da wäre eher LA oder Oszi angesagt, oder in manchen Fällen ein guter Reassembler. Sieh das mal richtig: Gegen ein gutes Tool zum Herausfinden, warum z.B. ein Interrupt nicht kommt oder warum ein Peripheriecore stuck ist, hätte ich garnix einzuwenden. Aber ein simpler Debugger mit 1..15 Breakpoints ist sowas nicht. Da kann man allenfalls testen, woran es liegt, daß man am Ende einer if..else Spaghettikette mit was Falschem herauskommt. W.S.
W.S. schrieb: > hat herzlich wenig Verwendung für einen (in die IDE integrierten) > Debugger. Du hast das falsch verstanden: Weder da1l6 noch Ich haben irgendwas gegen IDE oder Debugger gesagt. Ich zum Beispiel benutze Eclipse und den Debugger jeden Tag weils schön komfortabel ist. Es gibt ja auch keinen Grund darauf zu verzichten. Es geht vielmehr darum den build-prozess vollständig von der IDE zu entkoppeln und mit einem Tool durchzuführen mit dem man das erstens sowieso besser unter Kontrolle hat, das zweitens überall verfügbar ist und drittens ein etablierter und allgemein akzeptierter de-facto standard ist. Wenn man das so macht dann kann jeder die IDE verwenden die ihm am besten gefällt und eine ganze Klasse von Problemen (und auch der absurde Titel dieses Threads) löst sich in Luft auf. Der eine kann debuggen in Eclipse, der andere kann das selbe im Emacs tun, beide arbeiten am selben Projekt, keiner zwingt dem anderen was auf.
:
Bearbeitet durch User
Habe bisher das STM32f4Disco-Board mit Coocox (Eclipse) programmiert. War damit zufrieden. Jetzt gibt es von AC6 die System Workbench. Hab ich noch nicht mit gearbeitet, aber scheint gut zu sein. Natürlich gibts noch KEIL uvision... Dazu muss ich wohl nichts sagen.
IDE schrieb: > Für die Controller von ST Wir (Andreas und ich) haben die emIDE, mit Texane GDB Server in Betrieb. Ich mag sie, weil sie von Code::Blocks abstammt. Das Discovery (F407) funktioniert gut.
Unangefochten auf Platz 1 steht bei mir der PSoC Creator von Cypress. Das Ding ist echt der Hammer. Die Auto-Vervollständigung könnte besser sein, aber die Integration zwischen IDE, Controller und der gesamten restlichen Infrastruktur ist einfach perfekt. Nun sind die PSOC-MCUs leider ziemlich teuer und auch nicht in "kleinen" Packages erhältlich (außer irgendwelche völlig uninteressanten Typen), was das leider sehr stark einschränkt. Die Eclipse-basierten IDEs finde ich nicht schlimm, solange sie ein einigermaßen aktuelles Eclipse verwenden und die Konfigurationsmöglichkeiten von Eclipse nicht unnötig verstecken (wie z.B. Coocox!) Das Code Composer Studio von TI ist ein gutes Beispiel, wie man eine Eclipse-IDE gut und problemlos umsetzt. Den Preis, den sie dafür verlangen, halte ich aber für völlig überzogen. Eclipse hat einige Vorteile: Es ist ein stabiles und ausgereiftes System, in das Plugins geladen werden, die dann Funktionalität implementieren. Man kann daher sehr viel Flexibilität erreichen, indem man sich neue Plugins installiert. Da es sehr häufig auch für anderweitige Programmierung verwendet wird, kennen sich viele Entwickler auch schon mit den Eclipse-Eigenheiten aus und können das Wissen wiederverwenden. Für Neueinsteiger ist Eclipse aber natürlich ziemlich kompliziert. Und einen leistungsfähigen Rechner sollte man auch haben, sonst ist es manchmal unangenehm langsam. Dafür sind die Code-Vervollständigung und insbesondere der Debugger sehr gut. Von MPLAB X (Netbeans-basiert) war ich ziemlich angetan. Netbeans ignoriert man ja gerne mal, wenn es um IDEs geht, aber da gibt es eigentlich nichts, worüber man sich beklagen könnte: War zügig, alles einigermaßen logisch erreichbar, ich fühlte mich nicht von der IDE behindert. Das Visual-Studio-basierte Zeug mag ich nicht so. Es bedient sich nicht gut, und ständig gibt's irgendwelche neuen Versionen, die das Design wieder genau so weit ändern, dass man nicht mehr damit zurechtkommt. Die Autovervollständigung ist auf einem Stand, den man bereits seit vielen Jahren deutlich besser hinkriegt. VS ist gerade noch okay für die 8-bitter von Atmel, weil da der Codeumfang hoffentlich nicht GROSS wird, aber ich würde mir da wünschen, dass VS mal wieder zu einer zeitgemäßen IDE wird. Die Arduino-"IDE" ist ja mal ein totaler Witz. Muss man nicht mehr kommentieren. Die wenigen Features, die sie hat, sind kaum nützlich und dann auch noch wirklich schlimm implementiert. Ich nutze sie natürlich trotzdem, weil ich einfach faul bin. Sie begünstigt aber wirklich schlechtes, unstrukturiertes und unsauberes Programmieren: Moderne IDEs haben Features, die Projekte mit mehreren Dateien und guter Benennung belohnen (go to declaration/implementation, code-autovervollständigung, funktionierende Projektverwaltung, etc.). Die Arduino-IDE hat das alles nicht und eignet sich daher nur für Wegwerf-Programme, um mal eben schnell was auszuprobieren.
da1l6 schrieb: > Makefile + Guter Texteditor (oder beliebige IDE). > > Gleiche Umgebung für jeden Controller. > Gleiche Umgebung auf jedem OS. > Compiler + Git/SVN Checkout und man hat alles was man braucht. > Keine Abhängigkeit von irgendeiner IDE (Version). > Build ist automatisierbar für Test/Build/Paketserver. > Deutlich transparenterer Build Vorgang (z.B. compiler flags, linker > skript, etc.). > Im Fehlerfalle versteht man deutlich besser was im Hintergrund passiert. > Keine "geheimen" Source-files mit einkompiliert. > Keine Bindung an Controller eines Herstellers. > > da1l6 Das unterschreib' ich sofort. Die Build-Systeme der unterschiedlichen IDEs (selbst die einigermaßen brauchbaren) machen den Build-Vorgang nicht weniger komplex als er eben ist, sondern verstecken nur die Komplexität. Spätestens wenn das mal nicht so tut wie's soll oder wenn man mal auch nur ein bißchen was anderes braucht, als sich der Hersteller das vorgestellt hat, bleibt man damit auf der Strecke. Wer sich einmal die Mühe macht, make (oder von mir aus auch CMake) zu verstehen, macht sich von den IDEs (und ihren manchmal recht schrägen Vorstellungen, wie so ein Build abzulaufen hat) unabhängig und kann jede beliebige IDE verwenden (solange sie nur irgendwie einen make-Aufruf zustande bringt und auf eine Compiler-Fehlermeldung hin an die richtige Quellcodestelle springen kann). Auf "moderne" Features wie Aufrufhierarchien anzeigen oder Refactoring-Unterstützung muß man deswegen nicht verzichten. Im Gegenteil: man kann sich völlig unabhängig vom Build-System das Werkzeug aussuchen, das das am besten kann. Debugging: (fast) dasselbe. IDE's, in denen man debuggen kann, sind sowieso meist lediglich UI für Kommandozeilen-Debugger. Wenn's funktioniert: schön. Wenn nicht, muß man den trotzdem "von Hand" bedienen können. Ich persönlich benutze mittlerweile für alles, was über 50 Zeilen rausgeht, QtCreator. Egal für welche Plattform. Auch für reine C-Projekte. Kann nichts, was mir wichtig ist, schlechter als Eclipse, dafür alles um Faktoren schneller und ohne ständig fehlschlagende Update-Orgien. Für kleine Progrämmchen muß auch mal vi und ein fünfzeiliges Makefile herhalten.
Ich setze auf Kate als Editor, gcc als Kompiler und gdb, valgrind und printf zum Debuggen. Kate ist sehr Komfortabel, da es z.B. Dateien in GIT Projekten auflisten kann und grundfunktionen wie Blöcke zu Verschieben, Auszukommentieren, etc. Ausserdem ist die Automatische einrückung nicht so aggressiv, sondern minimalistisch und wie ich sie eingestellt habe. Besonders bei Komplexeren Programmen ist gdb nützlich, spontanes Setzen von Break- und Watchpoints und die Evaluation auch Komplexer ausdrücke auf der Konsole, welche in IDEs ein Krampf wären einzutippen und dass Ergebnis zu suchen, sind einfach unbezahlbar. Natürlich schreibe ich die Programme immer so, dass ich sie auch am PC Testen kann. Valgrind finde ich hauptsächlich zur Nachkontrolle nützlich. Ich finde ein Programm sollte möglichst wenig alloc's haben, und jedes byte wieder Freigeben. Es ist erstaunlich, wie wenige Programme dies effektiv tun.
Segger Embedded Studio. https://www.segger.com/embedded-studio.html Funktioniert super mit allen ARM CPUs. Man muss natürlich einen J-Link besitzen, aber den haben die meisten ja eh schon. Dafür gibt's dann auch gleich von Segger passendes RTOS, Middleware, usw. Der Compiler ist gcc. Funktioniert unter Windows, Linux und Mac OS X.
>Segger Embedded Studio Das sieht mir ziemlich nach Rowleys Crosstudio for ARM aus, mit dem ich mich hier ganz gut angefreundet habe. Läuft auch unter Debian mit den JLink ganz hervorragend.
yelwoR schrieb: >>Segger Embedded Studio > > Das sieht mir ziemlich nach Rowleys Crosstudio for ARM aus, mit dem ich > mich hier ganz gut angefreundet habe. Läuft auch unter Debian mit den > JLink ganz hervorragend. Ja, richig, das basiert auf Rowley CrossStudio wird aber unabhängig davon weiterentwickelt. Da kommt quasi das Beste aus beiden Welten von Segger und Rowley zusammen.
Hallo, finde die Diskussionsrunde sehr interessant und kann dazu eigentlich nur folgendes dazu sagen: Ich entwickle nun wohl schon seit ca. 31 Jahren embedded Software für Controller. Wenn ich mich an früher erinnere war das alles längst nicht so komfortabel wie die meisten IDEs von Heute. Aber wohl das meiste etwas Funktionaler als Heute. Da ich immer mit speziellen Controllern gearbeitet habe, habe ich immer erst meinen Controller ausgesucht und dann eine Entwicklungsumgebung. Heute gibt sich doch das alles nicht mehr wirklich so viel??? Vor allem wenn bei den meisten IDEs der gcc im Hintergrund sitzt. Viel wichtiger ist für mich nun einmal der Debugger, das er ordentlich auf Hardwareebene geht. Da kann ich nur Segger empfehlen und ihren Standalone Debugger, vor allen geht er in so gut wie jeder IDE. (Bin kein Segger Mitarbeiter und bekomme auch kein Geld für Werbung.) Aber folgende IDEs habe ich zur Zeit in verwendung, die ich alle als Brauchbar Einstufe: Kinetis IDE für Freescale MKL CPUs (Prozessor Expert ist gut) emIDE für STM wird aber nicht mehr gewartet ATmel Studio (soger recht gut, hatte aber am Anfang auch schwierigkeiten damit, neuen Atmel-ICE zugelegt kein Problem mehr.) Silabs IDE (bei mir aber noch eher durch die 8051 Familie) IAR IDE würde ich dann schon eher in meine engere Auswahl nehmen, zwar etwas Konservativer, dafür auch Funktionaler und einfacher zu Konfigurieren. (auch MISRA) Es gibt oft auch so viele Funktionen, die man einfach, wenn man nur Programmieren will nicht braucht. Mir gehts am Schluss um das Endergebniss und nicht ums Feeling mit der IDE. Der Code den gcc produziert ist teilweise schrecklich, IAR schon besser. Crossworks finde ich zu teuer wenn man das Ergebniss betrachtet. Bitte nichts überbewerten, jeder hat da seine Vorstellungen. Werde jetzt aber auch die anderen IDEs mir mal anschauen, Danke. Gruß Sascha
Sascha schrieb: > (Bin kein Segger Mitarbeiter und > bekomme auch kein Geld für Werbung.) Kann ich bestätigen, ich habe keinen Kollegen mit dem Namen ;-). SCNR Sascha schrieb: > Der Code den gcc produziert ist teilweise schrecklich, IAR schon besser. Der IAR Compiler ist tatsächlich noch besser aber der Abstand zu GCC ist nicht mehr so groß. Dafür muss man sich bei IAR mit teuren Lizenzen rumschlagen. Ich denke wie immer gibt es nicht das eine beste Werkzeug. Aber sowohl für den privaten als auch für den komerziellen Bereich gibt es heutzutage eine große Auswahl an brauchbaren Tools.
Moin,
Wenn die IDE die Controllerauswahl bestimmt...
Dann wedelt der Schwanz mit dem Hund.
Dann ist nicht die Anforderung sowas wie: Steuere Magnetventile,
Relais und Thyristoren in Stromrichtern so an, dass Klementine zufrieden
ist oder Frau Sommer keine halbleeren Kaffeetassen abraeumen muss.
Sondern eher sowas wie: Ich will mal eben 'was mit µControllern machen
(Nachdem ich gestern schnell mal 10 Linux-Distibutionen "angetestet"
hab' (sind eh' alle bloed, Mein Flugsimulator-Joystick geht nicht und
Photoshop laggt as hell))
Dann ist anscheinend auch egal, ob's diese Controller fuer mich auch
zu kaufen gibt, und ob man die Gehaeusebauform auch verarbeiten kann.
Dann tu' ich mir mit den Kommandozeilentools irrsinnig schwer.
...
Gruss
WK
Wenn ich mal kurz eine Frage in die Runde werfen dürfte: Hat Simplicity-IDE auch einen Simulator zum debuggen? Ich verwende gezwungenermaßen AtmelStudio und bin mittlerweile auch zufrieden damit, aber eclipse ist eigentlich meine favorisierte IDE da man sie für viele Sprachen einsetzen kann. Leider gibt es kein vernünftiges Plugin für eclipse, außerdem habe ich keinen brauchbaren Simulator gefunden abgesehen von dem in AtmelStudio.
Dergute W. schrieb: > Wenn die IDE die Controllerauswahl bestimmt... > Dann wedelt der Schwanz mit dem Hund. Danke für den Beitrag, ein Volltreffer. Wenn ich als HW/FW-Entwickler freie Hand habe, sieht das so aus: - welche Hardware kann die Aufgabe lösen, ist hinreichend zuverlässig beschaffbar und innerhalb des Zielpreises pro Stück? - bekommt man dafür innerhalb des vorhandenen Budgets eine verwendbare IDE (inkl. Lizenzkosten pro Arbeitsplatz und Einarbeitung)? - beim nächsten Projekt checkt man erstmal die Hardware, mit der Erfahrung vorliegt und setzt die idealerweise wieder ein. Als Entwickler hat man ggf. Vorlieben und legt damit wenn möglich die Reihenfolge der Auswahl fest. In meinem Fall STM32->AVR->PIC->Rest(8051, MSP430, XTENSA, picoblaze, ...). Interessant wird's dann, wenn pro Hardware verschiedene IDEs und Compiler vorhanden sind. Aber auch da gibt's wieder eine (persönliche) Rangliste. Wenn nun allerdings der Kunde spezielle Wünsche hat, was HW und IDE angeht, dann stehen die an erster Stelle. Allerdings muss man dann auch wieder die Gesamtkosten über die Produktlebensdauer betrachten.
Sascha schrieb: > emIDE für STM wird aber nicht mehr gewartet Richtig, aber nur weil es ein nachfolger gibt, der sich EmBlitz nennt und dieser nur noch weiterentwickelt wird. Benutze die aktuell mit dem STlink v2 auf STM32F1 und L1 und bin sehr zufrieden, da funktioniernt alles, von Debugging bis zur Registeransicht.
Aber warum soll man sich überhaupt auf eine IDE für alles festlegen wollen? Früher gab es genug Gründe, die aber mehr von der Hardware der Rechner abhing. Wie sicher die meisten Leute verschiedene Programme zum brennen von CDs und DVDs benutzt haben (oder noch nutzen), weil das kopieren mit CloneCD besser klappte oder ein anderes Programm zum rippen von Filmen nur mit ImageBurn zusammen arbeitete, so kann ich doch für Atmel deren IDE nehmen. Ich persönlich finde das Atmel Studio unglaublich langsam und würde, wenn ich es denn könnte, alles mit Notepad++ machen und dann einfach mit einem makefile arbeiten. Habe mir, dank Jörgs feines Programm war es am Ende sogar recht einfach, auch mal ein makefile gebastelt und alles funktionierte. Aber wenn ich den Controller wechsel oder irgendwelche Bedingungen sich ändern, muss man wieder ein anderes makefile basteln. Das ist mir zu umständlich und da greife ich lieber zu dem, was im besten Falle der Hersteller selbst anbietet. Für mich müsste es eher heißen: "Wenn die Controllerauswahl die IDE bestimmt!" Kurze Antwort darauf könnte sein: "Na und?" Die Computer sind heute allesamt schnell genug, Speicherplatz gibt es ohne Ende und auch der Arbeitsspeicher begrenzt nicht das Arbeiten mit dem einen oder anderen Programm. Warum dann nicht immer das nehmen, was ich für die Aufgabe und für meine eigenen Zwecke am besten finden?
Hallo, @ Jan K. ist es die emblocks.org Seite welche die emBlitz IDE macht? Man muss da ja aufpassen bei der Suchmaschine kommen da auch noch andere Controller Sites hoch. Also ich dachte immer, dass die emIDE mehr zu Segger tendiert, weil der JLink dominant war? Aber klasse werde mir mal emBlitz ansehen. Man sollte aber auch bedenken, dass eine Lizenz z.B. für IAR eigentlich gar nicht so teuer ist, wenn man das in professionellen Rahmen betrachtet. Und wenn ich Heute mit einem JLink und IAR sehr viel Zeit einsparen kann, weil einfach die Funktionalität für so gut wie jeden ARM-Chip habe und nicht lange rummachen muss, ist auch wieder eine menge Zeit gespart. Dazu muss sich mein Team nicht ständig auf irgendwelche neue IDEs einarbeiten. Gute Werkzeuge machen jeden Handwerker Glücklich und Erfolgreich! Gruß Sascha PS. nach eine kleine Frage: AtmelStudio hat doch nur einen Simulator für AVR oder? (ARM?)
Sascha schrieb: > Also ich dachte immer, dass die emIDE mehr zu Segger tendiert, weil der > JLink dominant war? Das tut sie auch. Der J-Link EDU wird sofort erkannt und unterstützt, aber auch der ST-Link funktioniert aber auch daran ganz gut.
F. F. schrieb: > Sascha schrieb: >> Also ich dachte immer, dass die emIDE mehr zu Segger tendiert, weil der >> JLink dominant war? > > Das tut sie auch. Der J-Link EDU wird sofort erkannt und unterstützt, > aber auch der ST-Link funktioniert aber auch daran ganz gut. Ja, genauso isz es. emIDE tendiert nicht nur zu Segger sondern wird zumindest von denen gesponsort ;-). Und mit SES ist emIDE natürlich erstmal obsolet. D.h. natürlich nicht das man nicht auch weiterhin wunderbar mit emIDE arbeiten kann. Der Umstieg nach SES (falls man das möchte) ist ja dann einfach weil beides den GCC Compiler nutzt. Sascha schrieb: > Man sollte aber auch bedenken, dass eine Lizenz z.B. für IAR eigentlich > gar nicht so teuer ist, wenn man das in professionellen Rahmen > betrachtet. Jain, ist schon ziemlich teuer im Vergleich zu z.B. SES. Als Firma kaufst du das ja nicht nur für einen Entwickler sondern gleich für mehrere Entwickler. Und dann hast du den Ärger mit Lizensserver (LMS2), usw. Ich spreche da aus Erfahrung. Schlecht sind aber beide nicht, egal ob IAR oder SES! Ziemlich geil finde ich jetzt SES PRO, https://www.segger.com/embedded-studio-pro.html. Ist natürlich auch nur für den kommerziellen Einsatz interessant, aber da bekommt man ja echt alles aus einer Hand von Segger.
Rufus Τ. F. schrieb: > da1l6 schrieb: >> Makefile + Guter Texteditor (oder beliebige IDE). > > Und kein Debugger. Steinzeit. Damit hadere ich bei meinem Setup gerade auch. AVR Controller, STK500, Lubuntu mit Geany und AVRDUDESS. Aber für On Chip Debugging braucht man Hardware und wenn man die nicht hat, ist die Lösung ausreichend. Und für kleinere Projekte reicht das serielle Rausschreiben von Variablenwerten. Wenn das reicht, kann man das durchaus verwenden. Zwingt den Entwickler zudem dazu, über jeden Schritt gut nachzudenken. Manchmal auch nicht ganz verkehrt.
Hallo Sascha (hier der andere Sascha!) ja so fing das bei mir mal an vor 30 Jahren mit Try and Error und dazu noch mit UV-Fenster zum löschen. Nur sind wir Heute im Jahr 2016?!? Also es geht ja nicht nur um Variablen, sondern auch um bedingte Sprünge,Stack,Register usw. Fürs Hobby na ja, aber so teuer sind die Debugger ja auch nicht. So ein ATmel-ICE als Kit für ca. 89€ der AVR + ARM macht ist doch klasse und dann das Atmel Studio, was könnte es schöneres geben fürs Hobby! Gruß Sascha Und was man beim Debuggen nicht sieht muss man glauben, dass es stimmt? Aber glauben heist nicht wissen!
Tom schrieb: > Ziemlich geil finde ich jetzt SES PRO, > https://www.segger.com/embedded-studio-pro.html. Ist natürlich auch nur > für den kommerziellen Einsatz interessant, aber da bekommt man ja echt > alles aus einer Hand von Segger. Kommt auf den Preis an... Im Moment rennt alles in Richtung "alles aus einer Hand" und App-Store. U.a. Renesas Synergy 1), Microchip Harmony und Embedded Code Source 2), Atmel Gallery + Studio 3) Solange man trotzdem noch seine Lieblingstools/IDEs/etc nutzen kann geht das noch in Ordnung, wenn allerdings Features nur noch in einer IDE oder irgendwann nur bei bestehender Internetverbindung zur Verfügung stehen hört der Spaß, freundlich formuliert, auf. Bei den größeren (IoT) Plattformen mit Intel, Cortex-A oder MIPS-Kern(en) sieht es dagegen z.Z. eher so aus als ob sich offene Lösungen durchsetzen. Meist gibt es angepasste Linux- oder Android-Pakete + Software und man kann alles zur Entwicklung einsetzen was man mag. Wobei wir wieder beim Ausgangsthema wären... Favorisiert unter den Hersteller-IDEs ist hier z.Z. (in etwa der Reihenfolge der Nennung): MPLAB X, STM32CubeMX mit IDE/Editor der Wahl oder SiLabs Precision32 und Cypress' PSoC Creator. Irgendwas auf Eclipse-Basis dürfen gerne andere benutzen. Herstellerunabhängig (Reihenfolge noch nicht ganz klar): Visual Studio, VS Code (basiert auf Electron worauf auch der Atom-"Editor" basiert) und QtCreator. Die beiden letztgenannten sind Open Source und auf allen gängigen Plattformen zu hause. Debugtools: J-Link, lange nichts 1) http://www.renesas.eu/products/embedded_systems_platform/synergy/tools_kits/index.jsp http://synergyxplorer.renesas.com/develop_evaluate/feature/introduction 2) http://www.embeddedcodesource.com/ 3) https://gallery.atmel.com/ 4) https://github.com/sandstorm-io/ekam (taucht hier auf, da es ein interessantes Buildsystem ist und es ein QtCreator-Plugin gibt)
Die Eingangsfrage wurde falsch gestellt. Es geht nicht um eine gute IDE, sondern um die Frage: Was taugt das Lauzeugs? Nimm Keil oder IAR und alle gängigen Architekturen passen.
Arc N. schrieb: > Solange man trotzdem noch seine Lieblingstools/IDEs/etc nutzen kann geht > das noch in Ordnung, wenn allerdings Features nur noch in einer IDE oder > irgendwann nur bei bestehender Internetverbindung zur Verfügung stehen > hört der Spaß, freundlich formuliert, auf. Full Ack! Ist aber bei SES Pro kein Problem, kannst du natürlioh auch mit einem anderen GCC und/oder IDE benutzen, ich wüsste aber nicht wieso ich das machen sollte. SES ist schon ziemlich gut.
Viele schimpfen ja über Atmel (bzw. deren Studio), aber eigentlich muss ich sagen dass ich im großen und ganzen doch recht zufrieden damit bin, auch wenn es mit 6.2 oder 7 schon ein ziemlich großer Haufen Software auf der Platte ist. Es ist eine Umgebung, die eigentlich out of the box funktioniert und genau das erwarte ich auch von einer Entwicklungsumgebung. Dass hier und da mal ein paar Bugs oder Merkwürdigkeiten sind kann ich verkraften. Bei ARM hat mich immer gestört dass es irgendwie nichts vernünftiges gab was kostenlos war und ebenfalls out of the box funktioniert hat. Meist nur komische Anleitungen a la "lade hier Eclipse, lade dort das Plugin, hier den Compiler oder auch dort, und dann hier noch CMSYS und dann dort noch die STM32 Standard Peripheral Libraries und dann pack das da irgendwie hin....", total nervenaufreibend... Dann hatte ich irgendwann CooCox gefunden, fand es anfangs auch gut (weil es auf Anhieb funktioniert hat), aber es ist eben doch eine sehr begrenzte/abgespeckte Eclipse Umgebung. Schlussendlich - auch wenn ich noch nicht allzuviel mit STM32 gemacht habe - bin ich dann bei Em::Blocks (jetzt EmBitz) hängen geblieben. Da ich mit Codeblocks (auf dem Em::Blocks basiert) eh meine ganzen Windows Programme programmiere (auch mit GUI), ist es wenig Umstellung und es ist eine schlanke und funktionelle Entwicklungsumgebung. Und es läuft out of the box, mit STM32 zumindest. Für Linux sehe ich eigentlich für kleinere Projekte eigentlich nur Konsole/Makefile + Editor der einem gefällt - oder eben für umfangreichere Sachen Eclipse.
:
Bearbeitet durch User
Guest schrieb: >> Das sieht mir ziemlich nach Rowleys Crosstudio for ARM aus, mit dem ich >> mich hier ganz gut angefreundet habe. Läuft auch unter Debian mit den >> JLink ganz hervorragend. > > Ja, richig, das basiert auf Rowley CrossStudio wird aber unabhängig > davon weiterentwickelt. Da kommt quasi das Beste aus beiden Welten von > Segger und Rowley zusammen. Ich verwende CrossStudio schon länger, konnte aber noch nichts finden was Segger im SES eingebaut hat was nicht auch schon in Crossworks zu finden ist. So gesehen ist SES nur eine stark verkrüppelte Crossworksversion. Bei den unterstützten Controllern, abgesehen vom generischen Teil, fehlt bei SES auch eine Menge. NXP ist da z.B. nur mit LPC4xxx vertreten, die kleineren fehlen alle. Crossworks geht hervorragend mit einem jlink, aber auch mit vielen anderen Adaptern inkl. stlink. SES geht nur mit jlink, stm32 Boards mit intergrierten Debugger bleiben damit aussen vor, bzw. man muss den intergrierten Debugger ausschalten. Für SES/Arm möchte Segger 1498€ sehen, Crossworks für Arm kostet 1500$ und ist somit sogar preiswerter. Weiterhin ist Crossworks eine named User Lizenz, d.h. ich kann sie auf beliebig vielen Rechnern installieren. Segger ist an die Seriennummer des jlink gedongelt. Mit anderen Worten, im Moment ist es besser man bleibt beim Original. Was ich mir wünschen würde ist ein reiner Debugger so ähnlich wie der von Segger nur mit Unterstützung der Fülle von Adaptern wie bei Crossworks. Damit stehe ich aber wohl so einsam da, dass das ein Wunsch bleiben wird. Hab ich was übersehen?
temp schrieb: > Was ich mir wünschen würde ist ein reiner Debugger so ähnlich wie der > von Segger nur mit Unterstützung der Fülle von Adaptern wie bei > Crossworks. Damit stehe ich aber wohl so einsam da, dass das ein Wunsch > bleiben wird. Spontan würde ich sagen: openocd + gdb + ein gdb GUI deiner Wahl
Axel S. schrieb: > Spontan würde ich sagen: openocd + gdb + ein gdb GUI deiner Wahl das nehme ich jetzt mal nicht ernst. Klar geht das schon irgendwie. Aber schön ist was anderes. Gibt es für den gdb überhaupt eine gute GUI? Bin da zwar aktuell nicht mehr auf dem allerneusten Stand aber alles was ich bisher kenne sind entweder Monster wie Eclips und co. oder kleine Projekte wo die Macher irgendwann die Lust verloren haben (ddd). Wenn es dann auch noch unter Win,Linux und OSX laufen soll bleibt nicht mehr viel übrig. Ich will hier keine emotionale Diskussion auslösen, das bringt eh nichts. Wollte nur zum Ausdruck bringen: Das was Crossworks als Debugger kann wäre meine Idealvorstellung, auf die restliche IDE-Funktionalität könnte ich gut verzichten.
temp schrieb: > Wenn es > dann auch noch unter Win,Linux und OSX laufen soll bleibt nicht mehr > viel übrig. Qt Creator. Ist zwar nicht primär dafür gedacht, funktioniert aber prima. Muß u.U. einmal mit passenden Skripten "hingefummelt" werden, falls es nicht auf Anhieb tut (was es bei mir meist tat),
Rufus Τ. F. schrieb: > da1l6 schrieb: >> Makefile + Guter Texteditor (oder beliebige IDE). > > Und kein Debugger. Steinzeit. Nichts alles was hinkt ist ein Vergleich. Ich arbeite genau so, aber mit Debugger wenn ich ihn brauche Gruß, Holm
temp schrieb: > Für SES/Arm möchte Segger 1498€ sehen, Crossworks für Arm kostet 1500$ > und ist somit sogar preiswerter. Weiterhin ist Crossworks eine named > User Lizenz, d.h. ich kann sie auf beliebig vielen Rechnern > installieren. Segger ist an die Seriennummer des jlink gedongelt. Mit > anderen Worten, im Moment ist es besser man bleibt beim Original. Jain, da vergleicht man Äpfel mit Birnen. Rowley CrossWorks hat z.B. keine native RTT Unterstützung, usw. SES Cortex M kostet 998.- Euro und ist damit günstiger als Rowley CrossWorks. SES unterstützt ALLE Cortex-M Devices, man kann einfach ein neues Projekt anlegen und wenn es kein BSP dafür gibt verrät der J-Link automatisch das Memory Layout. Rowley CrossWorks kann NICHT auf beliebig vielen Rechnern installiert werden sondern ist an eine MAC Adresse gebunden. Bei SES stöpselt man einfach seinen J-Link an den nächsten Rechner/Laptop und läuft. Es gibt also für beides Vor- und Nachteile bzw. es kommt auf den Verwendungszweck an. Ich arbeite den ganzen Tag mit SES und bin seit 10 Jahren Rowley Fan. Ich habe mit beiden keine schlechten Erfahrungen gemacht. Eben erst wieder ein Feature Request gehabt und sofort eine Antwort vom Hersteller bekommen.
IDE schrieb: > Ich sehe im Moment die Simplicity-IDE von Silabs ganz weit vorne, sie > ist Freeware und hält alles wunderbar zusammen was zu einem Controller > dazu gehört. Sehe ich ebenso. Kleiner Minuspunkt: Habe ab und zu das Problem, dass der Debugger den per J-Link angeschlossenen Gecko nicht kennt und deswegen nicht debuggen möchte. Die Leute scheinen ihr Handwerk zu verstehen. Das EFM32 SDK macht genau das was es soll (keine Abstraktionslayer-Orgien), und die Beispiele und Application Notes runden das ganze schön ab. Die Geckos sind auch mittlerweile extrem günstig geworden. Nur das High End ist eher unterbelichtet.
Ich hätte mal eine Frage bzgl. dem Code-Configurator in der Silabs-IDE: Man erstellt ja zunächst ein neues Simplicity-MCU-Projekt, dann wählt man sein Device. Dann öffnet ein Fenster, in dem man die Auswahl hat, ein leeres C, leeres C++, ein Example oder ein Bibliotheksprojekt zu erstellen. Wenn ich allerdings die Happy-Geckos als Device wähle, dann wird zusätzlich die Auswahl "Simplicity Configurator-Project" angezeigt, und zwar nur bei den HappyGeckos. Kann es sein, dass der Code-Configurator bisher nur für die Happy-Geckos funktioniert?
Guest schrieb: > Rowley CrossWorks kann NICHT auf beliebig > vielen Rechnern installiert werden sondern ist an eine MAC Adresse > gebunden. Aber ich kann Crossworks auf alle Rechner die ich habe mit ihren unterschiedlichen MAC Adressen gleichzeitig aktivieren und nicht nur auf einem wie bei Keil und Konsorten. "Beliebig viel" stimmt sicher nicht ganz, aber diese Art von Lizense ist mir trotzdem wesentlich lieber.
>Auf Platz 3 würde ich das Atmel-Studio einordnen, wobei dieses nur auf >Windows ausgelegt ist und somit einen Minuspunkt erhält... Für mich gibt es zwei starke Argumente dagegen: Sowohl im Berufsleben als auch privat entwickle ich mit Eclipse. Zu Hause unter Linux. Wegen AtmelStudio musst ich mir einen neuen Rechner bestellen: Beitrag "Atmel Studio 7 schnarchlangsam"
Ich nutze seit Anfang Jahr Codeblocks v16 in Ubuntu 14.04 auf einem Stick PC. Ist schnell und einfach zu handhaben mit vernünftigem Support auf diversen Foren. Nach vielen Jahren Atmel Studio auf einem "grossen" PC ist es ein echter Fortschritt in Sachen Produktivität und Stromverbrauch. Nur wird jetzt im Winter mein Büro nicht mehr so schön geheizt :-) Mit Eclipse wurde ich übrigens nicht glücklich
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.