Ich habe hier ein Nucleo-F446RE rum liegen und würde damit gerne mal
anfangen rum zu spielen.
Zu Hause habe ich mir gestern schon Atollic TrueStudio gezogen.
Hier auf der Arbeit habe ich gerade festgestellt, dass für ARM die CoIDE
frei gegeben ist.
Nur, CoIDE scheint nicht mehr gepflegt zu werden? Die "aktuelle" Beta
ist ja inzwischen fast ein Jahr alt.
Aber, was nimmt man denn da gerade aktuell, so für den sanften Einstieg?
Mit Betonung auf aktuell, sich in eigentlich tote Software einzuarbeiten
bringt irgendwie nicht so viel.
Eine Codegrößen-Beschränkung kann ich nicht gebrauchen, zumindest nicht
auf 32kB, ich würde das Nucleo gerne an mein FT810 TFT hängen und da
kommen schnell Bild-Daten für mehr als 32kB zusammen.
Rudolph schrieb:> so für den sanften Einstieg?
Du Scherzbold.
Nimm deinen Editor, dazu ne Toolchain a la Yagarto (wenn's denn GCC sein
muß) oder die Freewareversion vom Keil (dramatisch einfacher zu
benutzen) und den Totalcommander resp. Krusader. Dazu noch ein Flashtool
deiner Wahl. Das geht am "sanftesten" dieweil du dich nicht mit den
Befindlichkeiten irgendwelcher IDE's befassen mußt, sondern dich auf
dein eigentliches Vorhaben konzentrieren kannst.
W.S.
Ich benutze aktuell emBitz ( http://www.emblocks.org/ ).
Das ganze basiert auf Code:Blocks und bisher konnte ich keine
Einschränkungen finden.. ST-Link V2 geht, Breakpoints, Stacktrace,
Watches, IO-View.
Code::Blocks schrieb:> Code::Blocks
So für sich noch nicht zu gebrauchen, oder?
Das ist eine offenene IDE, aber nicht speziell für den STM32.
W.S. schrieb:> ... Das geht am "sanftesten" dieweil du dich nicht mit den> Befindlichkeiten irgendwelcher IDE's befassen mußt, sondern dich auf> dein eigentliches Vorhaben konzentrieren kannst.
Selber Scherzbold, wenn man das alles schon ist das leicht gesagt.
Aber von Null auf selbst-gebastelte IDE? Eher nicht so.
Besser kann das später immer noch werden, im Moment würde mir nen
Arduino Target auch reichen.
Jan K. schrieb:> Ich benutze aktuell emBitz
Aber in Beta, Version 0.42 vom November 2015?
Rudolph schrieb:> Aber in Beta, Version 0.42 vom November 2015?
EM::Bitz ist absolut brauchbar, egal ob Beta oder nicht. Der verwendete
Compiler ist gcc, und der ist garantiert nicht Beta.
Philipp R. schrieb:> Am besten ist natürlich ein nacktes Eclipse
Warum ist Eclipse am besten? Und warum sogar "natürlich am besten"? Für
mich ist das Eclipse nur ein lahmes ressourcenfressendes Monstrum, das
mich komplett ausbremst.
Frank M. schrieb:> Philipp R. schrieb:>> Am besten ist natürlich ein nacktes Eclipse>> Warum ist Eclipse am besten? Und warum sogar "natürlich am besten"? Für> mich ist das Eclipse nur ein lahmes ressourcenfressendes Monstrum, das> mich komplett ausbremst. Dagegen ist EM:Blocks aka EM:Bitz einfach um> Größenordnungen flotter und eine Wohltat.
Kenn viele die Eclipse verwenden, beste war wohl etwas übertrieben, war
aber mehr auf die zusammengefrickelte Lösung SW4STM32 bezogen, die
benutzen ein angepasstes Eclipse, hier kann ggf. ein selbst
angepasstes Eclipse von Vorteil sein (Erweiterbarkeit, etc), muss
natürlich nicht sein. Andere IDE sind natürlich auch gut, keine Frage.
Frank M. schrieb:> EM::Bitz ist absolut brauchbar, egal ob Beta oder nicht.
Das mag ja sein, aber nachdem ich das gerade installiert habe musste ich
feststellen, dass ich den STM32F446 nicht als Target auswählen kann.
Die Liste geht von STM32401CB bis STM32F439ZI.
Sieht sonst ja interessant aus.
Das SW4STM32 kann ich mir nicht mal ansehen, ich bekomme
http://www.openstm32.org/ nicht geöffnet.
Oh, ja, so langsam passiert was, der Server steht aber entweder auf dem
Mond, ist per Modem angebunden oder wird gerade angegriffen?
Nach zehn Minuten lädt Seite die immer noch.
Rudolph schrieb:> da kommen schnell Bild-Daten für mehr als 32kB zusammen
Was hat denn eine Codegrößen-Beschränkung mit Bild-Daten zu tun? Du
willst doch wohl nicht ein Hintergrund-Bild als const Array in den Code
packen?
Bernd schrieb:> Kann man nicht direkt im Eclipse nach "OpenSTM32" suchen und die> notwendigen Dateien herunterladen?
Nö, aber das GNU-ARM Plugin zu installieren schafft noch jeder...
Und mehr braucht man nicht für eine lauffähige IDE.
Hmm, der aktuelle Konsens scheint zu sein, dass es keinen Konsens gibt.
:-)
Nur so vom Look&Feel zur Installation liegt EmBitz bei mir im Moment
vorn, ohne Target bringt das nur wenig.
Segger Embedded Studio ist immerhin installiert, naja.
Ein Minuspunkt ist auf jeden Fall schon mal, dass man den ST-Link zum
J-Link umflashen muss um das Nucleo zu benutzen, immerhin kann man das.
SW4STM32 scheitert gerade noch an der JRE-Installation.
Eclipse, was? Würg.
QtCreator ist vor der Installation schon raus, oder auch sonstiger Kram
der mehr Arbeit mit der IDE an sich verspricht, als hilft schnell Code
auf den gewünschten Controller zu bringen.
Einfach "im Eclipse" nach irgendwas suchen ist sowieso nicht drin,
da es von dem Rechner hier nicht nach draussen darf.
Aus dem Grund habe ich vor Jahren auch mal eine CooCox Installation
aufgegeben, eines der notwendigen Plugins war einfach nicht als Download
zur Installation verfügbar.
Atmel-Studio möchte ich da mal als Referenz nennen, Installieren und
läuft, vom ATTiny bis zum ATSAM alles benutzbar, inklusive diverser
Eval-Boards.
Ich wollte mit dem Controller rum spielen, nicht ne Woche lang die IDE
einrichten.
Falls der Controller dann überhaupt interessant genug ist, kann die
Entwicklungsumgebung immer noch besser werden.
Rudolph schrieb:> Ich wollte mit dem Controller rum spielen, nicht ne Woche lang die IDE> einrichten.
Ach..wirklich? Deine vorletzten Worte klangen da aber ziemlich anders:
Rudolph schrieb:> Selber Scherzbold, wenn man das alles schon ist das leicht gesagt.> Aber von Null auf selbst-gebastelte IDE? Eher nicht so.
Wie kommst du bloß auf den Gedanken, daß man zu allererst irgendeine
IDE braucht?
Wer danach trachtet, sich vorrangig mit einer IDE zu befassen oder wer
so grottenschlecht im Programmieren ist, daß er den in die IDE
eingebauten Debugger 10x mehr braucht als Compiler und den Rest der Welt
zusammen, de kommt wohl um eine IDE nicht herum.
Aber wenn ich lese, daß der Wunsch-Chip leider nicht in der IDE
auswählbar sei, dann kommt mir das große Kopfschütteln.
Ich benutze nen stinknormalen Editor, der reicht zum C- und
Assembler-Schreiben völlig aus. Den Compilerlauf startet man per
Batchdatei oder Script per Mausklick, der Bootlader-brenner ist sowieso
bereits auf dem Bildschirm, so daß man dort auch bloß draufklicken muß
und fertig ist die Laube.
UND: Es geht immer, solange die eigentliche Toolchain nen Code für die
Ziel-CPU erzeugen kann.
Kurzum, ich habe nichts Prinzipielles gegen IDE's - aber nur so lange,
wie mich sowas nicht behindert oder gar einschränkt. Doch
ärgerlicherweise tun genau das eigentlich alle IDE's, die es zum
stinknormalen C-Programmieren so gibt.
W.S.
Rudolph schrieb:> Atmel-Studio möchte ich da mal als Referenz nennen, Installieren und> läuft, vom ATTiny bis zum ATSAM alles benutzbar, inklusive diverser> Eval-Boards.
Wenn Du alles von einem Hersteller haben willst: Silicon Labs Simplicity
Studio ist auch kostenlos und vom kleinsten 8051 bis zum dicksten ARM
benutzbar. Läuft unter Win, Mac, Linux
Ich habe jetzt Code::Blocks für den STM32F4 und F0 + OpenOCD Debugger am
Laufen.
Ich mag Code::Blocks. Er ist schnell, kann viele Targets (alles was GCC
ist; selber nehme ich ihn für AVR, PC-Software und nun ARM) und läuft
auf mehreren Betriebssystemen (Windows + Linux selber in Verwendung).
Alles Eclipse-artige habe ich immer (beobachte seit ca. 2004) als
wuchtig auf meinen PCs empfunden. Egal ob 1.4GHz Centrino oder i7 jetzt.
Interessanterweise aber immer gleich träge.
Es gelingt/scheitert die Einbindung eines Kontrollers immer an den
selben Punkten: Linker-File, Startup-File, die eine oder andere
Compileroption.
Den Debugger einzurichten ist auch immer ein Glücksspiel (für mich
jedenfalls). monitor halt on reset (oder doch nur monitor reset halt)...
Naja.
Aber wenn das Projekt steht, ist man glücklich.
Was mir fehlt ist eine ESP8266 Einbindung ohne makefile! Mit ist es eh
kein Problem.
Code::Blocks kann wunderbar mit eigenen Variablen für Pfade usw. in den
Einstellungen umgehen. Dadurch werden die Projekte wirklich portierbar
und laufen (wenn sauber gemacht) überall. Relative Pfade ist sowieso
eine der Stärken von CB.
W.S. schrieb:> Ich benutze nen stinknormalen Editor, der reicht zum C- und> Assembler-Schreiben völlig aus. Den Compilerlauf startet man per> Batchdatei oder Script per Mausklick, der Bootlader-brenner ist sowieso> bereits auf dem Bildschirm, so daß man dort auch bloß draufklicken muß> und fertig ist die Laube.
Das hab ich vor 10 Jahren genau so gemacht - ging bestens und ohne
Probleme.
Heute arbeite ich aber ausschließlich mit IDE !
(ich weiß nicht - clickt sich irgend wie besser)
Und unter den Kollegen ist man übrigens auch besser angesehen,
weil man nicht zu den ewig Gestrigen gehört.
Sepp aus Hintertupfing schrieb:> Und unter den Kollegen ist man übrigens auch besser angesehen,> weil man nicht zu den ewig Gestrigen gehört.
Klingt nach 2005.
Ich will hier noch einmal nachlegen: Es gibt heutzutage absolut
exzellente Texteditoren mit Projektverwaltung und sehr mächten Plugins.
Der Vorteil einer dedizierten IDE ist mir nicht mehr ersichtlich. Der
Nachteil ist hingegen, dass man meist mit ziemlich eingeschränkten
Editor-Funktionen leben muss. Wo ist da noch der Vorteil? Dass man mit
"ctrl-b" compilen kann? Da kann ich mir auch eien "Make"-Aufruf drauf
legen...
Tim . schrieb:> Ein guter Texteditor (Aktuell: Sublime Text oder Visual Studio Code),> ein Makefile und ein Terminal zum debuggen.Tim . schrieb:> Ich will hier noch einmal nachlegen: Es gibt heutzutage absolut> exzellente Texteditoren mit Projektverwaltung und sehr mächten Plugins.
Es ist absolut dir überlassen mit welcher Methode du am besten zum Ziel
kommst.
Tim . schrieb:> Der Vorteil einer dedizierten IDE ist mir nicht mehr ersichtlich
Das deutet darauf hin (kann mich auch täuschen) das du nicht sehr tief
in den HW Niederungen
einsteigen musst dann reicht wahrscheinlich ein Terminal.
Also ich habe früher sehr viel nach der Methode von "W.S." gearbeitet.
Nachdem nach und nach die IDEs modern wurden (Keil war hier der Pionier)
hab ich mir die IDE von Silicon Labs angelacht.
Für mich waren die Vorteile frappierend darunter die Produktivität der
Testerei.
Warum?
Ein Beispiel:
Die Aufgabe soll sein einen Colorsensor über eine eigene I2c
Schnittstelle (selbst gestrickt)
einzulesen und dann Max Min - Werte der einzelnen Farben zu erfassen.
wie üblich am Anfang geht gar nichts.
Was machen?
Möglichkeit 1: (old fashion)
Ein Terminal an eine funktionierende serielle
Schnittstelle anschließen
Die Funktionsaufrufe welche interessieren
werden dann voll gespickt mit printf's
und dann wird geschaut was für Werte kommen.
Funktion ändern, Compilieren, linken und locaten
Hex File generieren flashen und dann "hoffen" dass sich was tut
und zwischen durch Hypothesen aufstellen warums nicht tut.
Das ganze als Iteration die nicht enden will.
Führt durchaus zum Ziel braucht aber Ausdauer.
1 Möglichkeit 2: (new fashion)
Man nützt die Möglichkeiten eine IDE.
Schließt den passenden Progadapter an
und mit 2 (zwei) Click ist das ganze "gemaked"
und im Ziel Prozessor geflasht - das schon mal für den Anfang.
Hernach geht man mit dem CURSOR zur Stelle im Quelltext hin
wo man das ganze stoppen will.
Wiederum ein Click (go to Cursor) und der Prozessor steht.
Nun kommt das Geile an der Sache:
man clickt auf die Variablen , Index, Arrays u.s.w
die einen interessieren und schiebt sie ins "Watch" Fenster.
Die IDE kennt bereits die passende Formatierung
(aus dem Deklarationsteil) und stell alles sauber aufbereitet dar.
So konnte man sehr schnell sehen, dass das 1. Problem
am i2C Driver lag (die LA Aufzeichnung war o.k.)
und im diesen Stiel macht man dann weiter.
Den Terminal Anschluss benutze ich trotzdem noch
aber nur für übergeordnete Funktionstest (BITE)
Mit CooCox-IDE und IAR-IDE (ARM)
machte ich genau die gleichen Erfahrungen.
Zusammenfassung:
Wenn man nicht in den HW Niederungen (HW-Fegefeuer) einsteigen muss
und hauptsächlich auf der "HAL" Ebene rumplätschert
dann tut es die Editor-Compiler-Terminal Variante
ansonsten sind die oben genannten IDE's ein MUSS.
Sepp aus Hintertupfing schrieb:> Testerei.> Möglichkeit 2: (new fashion)>> Man nützt die Möglichkeiten eine IDE.>> Schließt den passenden Progadapter an> Hernach geht man mit dem CURSOR zur Stelle im Quelltext hin> wo man das ganze stoppen will.> Wiederum ein Click (go to Cursor) und der Prozessor steht.> man clickt auf die Variablen , Index, Arrays u.s.w> die einen interessieren und schiebt sie ins "Watch" Fenster.> Die IDE kennt bereits die passende Formatierung> (aus dem Deklarationsteil) und stell alles sauber aufbereitet dar.> Zusammenfassung:
Das ist KEIN Test.
Das ist exploratives Rumprobieren (o.neg. Konnotation, ist gut und
auch nötig)
Ein Test ist reproduzierbar, dessen Ergebnisse logbar (mit
Zeitstempel & co.) UND maschinell bewertbar (gut/schlecht als minimum)
Darum kann man mit GUI-Entw.Werkzeuge nur auf kompliziertem Wege
Testen (obendrauf mit dem unkalkulierbaren Risikofaktor Mensch).
Hinweis:
der allererste Test ist schon mal das Builden (primitiv: keine
Kompilierfehler, ein Binary entsteht).
Ich will meinen nicht 1x builden, sondern immer wieder, nach jeder Code
UND Toolchain änderung/anpassung.
Dies will ich gerne "gratis", also ohne Mäuseschubser/Hotkeydrücker,
haben.
Also gehört das Builden in ein Makefile (so auch das Übertragen aufs
Target), damit es einfach in Nighlybuilds aka CI u. Konsorten
geht.
Mehr als new fashion ist dies zeitloses The Engineers Way - so vor
20, vor 10 Jahren, genauso wie heuer und in 10, in20++ Jahren.
Ja, mit einigen IDEs geht es auch , irgendwie, aber so gut wie immer
umständlich .
Nein, ich will nicht unterschiedliche (Build-)Abläufe auf des
Entwicklers Arbetsplatz(-Computer) und auf dem unbemannten
Build-&Test-Computer.
Hallo Rudi,
ich vote für "emBitz"
schlank, übersichtlich, schnell...
Es gibt auch einen "ARM-Wizard"
Das Grundprojekt bastelt man mit CubeMx (CMSIS/HAL)
das Startup-Skript (*.s) und das Linker-Skript aus CubeMx ins
Projekt-Root kopieren, ferdsch.
Grüße Runout
Ich nutze Eclipse. Die Konfiguration ist nicht so toll, aber nach einer
Weile geht das auch ohne lange suchen und probieren.
Ich verwende Eclipse für AVR-, ARM- und SPARC-Projekte und habe dafür
jeweils die GNU Toolchain installiert. Klappt super, entweder mit
Makefiles oder auch mit den für AVR oder ARM zur Verfügung stehenden
Plugins.
Zum Debuggen nehme ich bei AVR den JTAG ICE MkII bei ARM den J-Link und
beim SPARC den GRMON. Alle 3 Archituren lassen sich dann mit dem
entsprechenden GDB unter Eclipse debuggen.
Ich habe also eine IDE für 3 Architekturen. Darum ist das Konfigurieren
nicht so schlimm, ist ja bei allen Architekturen identisch. Und das
mache ich unter Linux und Windows so. Brauche mich also auch da nicht
umstellen.
Und der Editor in Eclipse ist meiner Meinng nach super. Die
Code-Ergänzung oder Makro-Auflösung (bei Maus-Hovering) oder "goto
definition" eines Types. Refactoring, automatische Code-Formatierung und
und und. Das Editieren läßt einfach keine Wünsche offen.
Und das Eclipse langsam ist, den Eindruck kann ich nicht bestätigen.
Falls jemand einen anderen Editor kennt, der das ähnlich gut bietet,
dann würde ich diesen gerne kennenlernen (ernsthaft).
Wer da einen einfachen Texteditor + Konsole bevorzugt, gerne. Nur sehe
ich bei diesen Kollegen immer, wie schwer sie sich tun beim editieren
zumindest. Wie war noch gleich der Name des Counters in der Struktur??
Suchen.... Ich nutze einfach die Code-Ergänzung.
Das beste Werkzeug ist eh das, mit dem man am produktivsten ist. Also
das, mit dem man sich gut auskennt.
Sepp aus Hintertupfing schrieb:> Die Funktionsaufrufe welche interessieren> werden dann voll gespickt mit printf's> und dann wird geschaut was für Werte kommen.>> Funktion ändern, Compilieren, linken und locaten> Hex File generieren flashen und dann "hoffen" dass sich was tut> und zwischen durch Hypothesen aufstellen warums nicht tut.>> Das ganze als Iteration die nicht enden will.> Führt durchaus zum Ziel braucht aber Ausdauer.
Einerseits siehst du von oben herab auf Leute wie mich "Das hab ich vor
10 Jahren genau so gemacht" und dünkst dich durch das Verwenden einer
IDE nebst Quellcode-Debugger um 10 Jahre moderner - und andererseits
zeigst du mit deinem Beispiel, daß bei dir der Knackpunkt ganz woanders
liegt.
Iteration ohne Ende?
Nee, ich sehe da viel eher, daß du trotz jahrzehntelangem Programmieren
nicht wirklich das gründliche Denken VOR dem Codeschreiben gelernt
hast. Ich finde, daß genau dort deine Schwachstelle ist, die du durch
den Debugger zu umschiffen versuchst.
Das scheint mir heutzutage ubiquitär zu sein: Die Leute hauen zu
allererst in die Tasten und klicken sich dann im Debugger durch die
Einzelschritte, um herauszufinden, was sie da eigentlich angerichtet
haben.
Ich mach das umgekehrt: Zuerst gründlich nachdenken, dann die Stellen
mir merken, die beim Lesen des RefMan's noch unklar sind, dann die
Firmware konzipieren und erst dann in die Tasten hauen. Das hilft
ungemein, denn man braucht nur noch genau DAS auszuprobieren, was im
RefMan nicht klar genug zu lesen war - und das ist in ganz vielen Fällen
nur noch sehr wenig.
Nochwas zu IDE's: Die haben genau dort ihren tieferen Sinn, wo man
spartenübergreifend arbeiten muß. Klassisches Beispiel ist Delphi und
Konsorten: Einerseits Programmierung, andererseits grafische Gestaltung
der Programmoberfläche.
W.S.
W.S. schrieb:> Nee, ich sehe da viel eher, daß du trotz jahrzehntelangem Programmieren> nicht wirklich das gründliche Denken VOR dem Codeschreiben gelernt> hast.
Es soll Leute geben die vor lauter denken VOR dem Codschreiben,
Angstzustände bekommen wenn sie es dann in die Tat umzusetzen müssen.
(alles schon erlebt).
Also mich kannst du diesem Gebiet nicht provozieren.
W.S. schrieb:> Das scheint mir heutzutage ubiquitär zu sein: Die Leute hauen zu> allererst in die Tasten und klicken sich dann im Debugger durch die> Einzelschritte, um herauszufinden, was sie da eigentlich angerichtet> haben.
Wie den sonst ?
Also ich kann Dir nur raten lass die Finger von diesem
ganzen Opensource Geraffel, das ist Wusel in höchster
Ausprägung. Ich habe mir eine "nichtkommerzielle " Lizenz von
Rowley Crossworks gekauft.
Aufspielen und funzt. Alles andere ist doch nur Krampf.
Ich bin hier zum ersten mal auf VisualGDB aufmerksam geworden und habe
mir als Visual-Studio-User auch gleich die Testversion installiert.
Verglichen mit der bisherigen GNU-Arm & Eclipse bin ich da angenehm
überrascht. Ich wundere mich, dass das hier so wenig Erwähnung findet.
Gibt es da gravierende Nachteile, die sich beim ersten Probieren noch
nicht offenbaren?
@Cube_S:
Nein, funktioniert gut, hatte es eine Weile im Einsatz. Leider habe ich
ein paar Projekte, welches reine Makefile basierende Umgebungen sind,
und auch bleiben müssen, und mit diesen hatte ich Probleme im VisualGDB.
Am Schluss bin ich wieder auf ein einfacheres System zurück gegegangen:
Beitrag "STM32F7 (Nucleo) Makefile Projekt mit Programmer's Notepad"
Lag aber nicht an VisualGDB oder Visual-Studio, mehr an meinen Marotten
:-)
...die Frage hatte ich mir auch letztlich wieder gestellt. Nach
Betrachten aller Alternativen (kommerzielle Lösungen ausgenommen) bin
ich auch wieder bei emBitz gelandet.
Funktioniert soweit gut (STM32F0), allerdings ist es mir gestern
innerhalb von drei Stunden "build, debug, repeat" zweimal komplett
gecrasht.
> Es soll Leute geben die vor lauter denken VOR dem Codschreiben,> Angstzustände bekommen wenn sie es dann in die Tat umzusetzen müssen.> (alles schon erlebt).
:-) unterschreib.
Diese Angst minimiert sich deutlich wenn gut praktiziertes CI
funktionierend vorliegt.
>> Wie den sonst ?
Nur "korrekten"[TM] und "sinnvollen"[TM] Code schreiben.
Erreicht man durch vernünftig modulares/schrittweises Vorgehen; ist
verwandt mit "tesbaren Code" schreiben.
(Abgrenzung Test<->Rumpröbeln s. oben)
NB: es gibt Jecken die bedienen alle in diesem Thread erwähnten Schritte
(Source & Makefiles editieren, kompilieren, aufs-Target-laden,
per-GDB-debuggen, Doku-lesen-inkl-www) schön integriert aus Emacs raus.
Crashfrei.
--> IDE-Empfehlung: EMACS
(bin selbst leider noch nicht auf diesem Guru-Level...)
Markus M. schrieb:> BTW: EmBitz 1.00 ist heute erschienen
Danke für die Info, aber auch diese Version kennt den STM32F446 nicht.
Wobei das für mich selber aktuell nicht mehr so wichtig ist, da ich mich
zum einen gerade mit Visual Studio Code anfreunde, zum anderen aber
aktuell mit MPC5748 und RH850F1L unterwegs bin. :-)
Cube_S schrieb:> Gibt es da gravierende Nachteile, die sich beim ersten Probieren noch> nicht offenbaren?
Habe visualgdb seit einem guten Jahr im Einsatz. Es gibt auch eine
Version bei der man das linker Script per klickibunti verwalten kann.
Verglichen mit em::bitz, eclipse, Keil und was ich sonst noch alles
ausprobiert habe, fand ich das für meine Zwecke am geschicktesten. Der
Debugger ist einfach Top.
Nachteile: einige kleine debugger-Bugs, die dahingehend führen, dass man
bei jedem debugger-Start die immer gleichen Handgriffe ausführen muss.
So zb. Verschwinden manchmal die vorher eingefügten live variablen aus
der Liste. Vor allem tretwa diese Bugs auf, wenn man mit c++
programmiert.
900ss D. schrieb:> Und der Editor in Eclipse ist meiner Meinng nach super. Die> Code-Ergänzung oder Makro-Auflösung (bei Maus-Hovering) oder "goto> definition" eines Types. Refactoring, automatische Code-Formatierung und> und und. Das Editieren läßt einfach keine Wünsche offen.>> Und das Eclipse langsam ist, den Eindruck kann ich nicht bestätigen.>> Falls jemand einen anderen Editor kennt, der das ähnlich gut bietet,> dann würde ich diesen gerne kennenlernen (ernsthaft).
QtCreator. Ist fast auf Visual Studio Niveau, nur bei zu viel Template
magic steigt er aus. Ansonsten ist er einfach top, hervorragendes
Codecompletion, sehr gute Performance und ein ordentliches dark theme
(ohne will ich nicht mehr). Eclipse ist gut, aber die Performance
ertrage ich nicht. Mein Atollic True Studio in der Arbeit braucht 3
Minuten um zu starten! Inzwischen benutze ich auch da QtCreator. True
Studio erledigt build und debugging und zum schreiben benutze ich
QtCreator. Daheim lasse ich True Studio weg und benutze Makefile +
Terminal und QtCreator (Debugging geht auch in QtCreator).
Um QtCreator mit make zu verwenden (bzw. QtCreator als exzellenten
Codeeditor zu verwenden), auf neues Projekt gehen, Projekt importieren,
Import eines existierenden Projektes. Alles Weitere ist so ziemlich
selbsterklärend. Bei Bedarf GDB einrichten.
Man kann aber auch den ganzen QtCreator für bare metal verwenden:
http://doc.qt.io/qtcreator/creator-developing-baremetal.html .
Ich war selbst ewig lang auf der Suche nach einer ordentlichen IDE für
embedded unter Linux, gefunden hab ich letztendlich QtCreator. Was
besseres gibts aktuell für mich nicht (höchstens Visual Studio, aber
unter Linux ist da nix).
TriHexagon schrieb:> (höchstens Visual Studio, aber unter Linux ist da nix).
Dann solltest Du Dir mal Visual Studio Code ansehen:
https://code.visualstudio.com/
Das ist ein reiner Editor, ist OpenSource, kostenlos und läuft unter
Windows, Linux und MacOS.
Das einzige was mich an dem "stört" ist, dass ich die Plugins nicht
durch den Proxy auf der Arbeit getunnelt bekomme.
Man kann die zwar auch direkt runterladen und installieren, dafür muss
man aber erstmal erraten wie sich der Link für das gewünschte Plugin
zusammen setzt.
Rudolph R. schrieb:> TriHexagon schrieb:>> (höchstens Visual Studio, aber unter Linux ist da nix).>> Dann solltest Du Dir mal Visual Studio Code ansehen:> https://code.visualstudio.com/>> Das ist ein reiner Editor, ist OpenSource, kostenlos und läuft unter> Windows, Linux und MacOS.>> Das einzige was mich an dem "stört" ist, dass ich die Plugins nicht> durch den Proxy auf der Arbeit getunnelt bekomme.> Man kann die zwar auch direkt runterladen und installieren, dafür muss> man aber erstmal erraten wie sich der Link für das gewünschte Plugin> zusammen setzt.
Sieht auf jeden Fall brauchbar aus. Muss ich dieses Wochenende mal
ausgiebig testen. Den Editor habe ich damals, als er raus kam, mal
angeschaut, war ganz nett. Aber es gibt viele Editoren die "ganz nett"
sind. Bin gespannt wie gut das Codecompletion ist. Vielen Dank!
TriHexagon schrieb:>... Eclipse ist gut, aber die Performance> ertrage ich nicht. Mein Atollic True Studio in der Arbeit braucht 3> Minuten um zu starten! ...
Und ansonsten ist Dein Arbeitsrechner ein Rennpferd?
Ich finde die 17s (inkl. manueller Interaktion bei der Workspaceauswahl,
bis zum Arbeitsbeginn) die TS 5.4 auf meiner alten Mühle braucht schon
recht lahm...
Rudolph R. schrieb:> TriHexagon schrieb:>> (höchstens Visual Studio, aber unter Linux ist da nix).>> Dann solltest Du Dir mal Visual Studio Code ansehen:> https://code.visualstudio.com/>> Das ist ein reiner Editor, ist OpenSource, kostenlos und läuft unter> Windows, Linux und MacOS.
Ich mag VS-Code. Es ist ein relativ schlanker Editor mit Git-Integration
und auch irgendwelche Aufgaben lassen sich ganz gut automatisieren.
Gewissermaßen so ein bisschen wie Atom nur schneller und mit mehr
Features (von Haus aus) als Sublime, dafür einen ticken langsamer.
Was auch wirklich gut ist, ist die Debugger-Integration. Über ein Plugin
kann man sich damit auch GDB mit OpenOCD zurechtbasteln:
https://marketplace.visualstudio.com/items?itemName=webfreak.debug
Der große Knackpunkt meiner Meinung nach ist die C/C++ Integration. Das
Plugin von Microsoft kann man für Embedded Projekte vergessen und mit
anderen Completion-Plugins wird das ganze sehr schnell sehr langsam.
Deshalb taugt mir VS-Code momentan einfach nicht für C/C++. Für andere
Sprachen, wie z.B. Python oder Go ist es durchaus mehr als ein sehr
guter Editor und darf sich da durchaus IDE schimpfen. Für C/C++ ist es
eben "nur" ein sehr guter Editor.
Mit VisualStudio hat VisualStudio Code außer dem Namen und dem
Hersteller absolut nichts gemeinsam.
TriHexagon schrieb:> Ich war selbst ewig lang auf der Suche nach einer ordentlichen IDE für> embedded unter Linux, gefunden hab ich letztendlich QtCreator. Was> besseres gibts aktuell für mich nicht (höchstens Visual Studio, aber> unter Linux ist da nix).
Kann ich nur unterschreiben. QT-Creator ist schnell, hat eine gute
Completion-Engine, ordentliche Debugging-Funktionen und Git ist auch mit
integriert. Trotzdem fühlt sich das ganze immer noch sehr schlank und
überhaupt nicht überladen an. Kann ich nur empfehlen.
FYI, Atollic TrueStudio ist seit einiger Zeit kostenlos für STM32.
Eclipse basierend und hat u.a. alle Register schon aufbereitet. Man kann
z.B. auch einzelne Bits in den Register per Mausklick zur Laufzeit
ändern. Das ist nett
