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?
http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-ides/sw4stm32.html Am besten ist natürlich ein nacktes Eclipse (+Erweiterungen) und dazu Makefiles, aber ich finde die SW4STM32 IDE auch nicht schlecht, damit hat bei mir alles auf Anhieb funktioniert und man muss nicht Ewigkeiten rumfrickeln.
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.
:
Bearbeitet durch Moderator
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.
Also ich nutze weiterhin CooCox und den aktuellen GCC.
Segger embedded Studio basiert auf rowley crossworks. -> https://www.segger.com/embedded-studio.html
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.
https://web.archive.org/web/*/http://www.ac6-tools.com/downloads/* http://www.ac6-tools.com/downloads/SW4STM32/ Vermutlich Wartungsarbeiten. Könnte dir notfalls die install_sw4stm32_win_64bits-v1.3.exe auch so schnell auf nen Server hochladen. Edit: WTF, Seite braucht ewig zu laden, dann kann man die Datei aber mit 11,2MB/s herunterladen. Na da wird wohl der Server nur mit 100Mbit/s angebunden sein und keine Priorisierung stattfinden...
:
Bearbeitet durch User
Kann man nicht direkt im Eclipse nach "OpenSTM32" suchen und die notwendigen Dateien herunterladen?
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? Beitrag "Re: STM32F7 Discovery Board"
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.
Philipp R. schrieb: > https://web.archive.org/web/*/http://www.ac6-tools.com/downloads/* > http://www.ac6-tools.com/downloads/SW4STM32/ > > Vermutlich Wartungsarbeiten. Könnte dir notfalls die > install_sw4stm32_win_64bits-v1.3.exe auch so schnell auf nen Server > hochladen. Vermutlich sind da gerade alle OSX-Nutzer ;) "STMicroelectronics has made its free development tools for STM32 microcontrollers available to Mac computer users" http://www.st.com/content/st_com/en/about/media-center/press-item.html/n3819.html Als C/C++-IDEs: CodeLite wäre einen Blick wert, ebenso die vielversprechende juCi++-IDE 1) Ansonsten: QtCreator + Baremetal 2) für alles oder falls Visual Studio genutzt werden soll und etwas Geld übrig ist VisualGDB 4) 1) https://github.com/cppit/jucipp 2) https://github.com/nlhans/qt-baremetal (Anleitung für STM32) 3) https://www.emcraft.com/som/stm32f7/running-qt-gui 4) http://visualgdb.com/tutorials/arm/stm32/
Ich nutze den QtCreator mit dem Bare-Metal-Plugin. Das geht bei mir auch gut, jedoch ohne Registeransicht. Dafür nutze ich dann winIDEA.
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.
Ein guter Texteditor (Aktuell: Sublime Text oder Visual Studio Code), ein Makefile und ein Terminal zum debuggen.
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...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...)
BTW: EmBitz 1.00 ist heute erschienen, der Nachfolger von emBlocks bzw. EmBitz 0.42: http://www.emblocks.org/web/downloads-main
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.
Macht doch nicht so viele Vorschläge - da kommt man mit dem Ausprobieren ja gar nicht mehr hinterher! :-)
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...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Push. EM:BITZ streikt, da stellt sich mir aktuell die Frage. Welche IDE ist kostenfrei und angesagt? Grüße!
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
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.