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
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
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.
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.
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.jsphttp://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.
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
