Hallo,
ich suche eine freie IDE für STM32 ohne irgendwelche Limitierungen,
welche sich vernünftig bedienen lässt. Momentan benutze ich CooCox
CoIDE.
Da es sich bei mir für die meisten Projekte anbietet gleich die
"components" wie z.B. CMSIS usw. zu benutzen, habe ich natürlich auch
darauf zurückgegriffen. Nun nervt mich z.B., dass ich z.B. die Datei
"system_stm32f10x.c" nicht direkt in CoIDE editieren kann, um z.B. den
Takt einzustellen. Dafür benutze ich einfach einen externen Editor und
das nervt.
Ich möchte mich eher wenig mit der IDE auseinandersetzen. Vielmehr
möchte ich mich mit meinen Projekten beschäftigen und nicht wie ich die
Unzulänglichkeiten der IDE umgehe.
Nun interessiert mich, welche IDEs ihr so verwendet, welche Erfahrungen
ihr damit habt, wie zufrieden ihr damit seid und wie hoch der
Einrichtungsaufwand war. Dabei sollen nur die freien Tools ohne
Limitierung berücksichtigt werden.
Grüße
>Ich möchte mich eher wenig mit der IDE auseinandersetzen. Vielmehr>möchte ich mich mit meinen Projekten beschäftigen und nicht wie ich die>Unzulänglichkeiten der IDE umgehe.
Dann lerne einen Compiler und Linker ohne IDE zu benutzen.
Thomas S. schrieb:> Schau Dir mal OpenSTM32 / AC6 an.> http://www.openstm32.org> http://www.openstm32.org/System+Workbench+for+STM32> Alternativ:> CooCox-IDE: http://www.coocox.org/
Openstm32 habe ich gestern noch ausprobiert! Danke für den Hinweis.
Allerdings bin ich damit nicht zufrieden. CooCox benutze ich schon seit
einiger Zeit, bin aber mit der neusten Version sehr unzufrieden!
Klugscheisser schrieb:> EmBitz
Danke für den Hinweis, habe ich gerade eben ausprobiert. Gefällt mir
leider auch nicht.
Bernd K. schrieb:> Eclipse/CDT mit GNU-Arm-Plugin und die offizielle arm-none-eabi-gcc> Toolchain.
Danke für diesen Hinweis. Dem werde ich als nächstes nachgehen.
holger schrieb:> Dann lerne einen Compiler und Linker ohne IDE zu benutzen.
Bei kleinen Projekten gehe ich da voll mit.
Aber:
Eigene Makefiles zu schreiben ist genau das, was ich mir in Zukunft
sparen möchte, da die Projekte und damit auch die MakeFiles immer
umfangreicher werden. Bisher habe ich eigene Makefiles geschrieben,
möchte mir dies aber von eine IDE abnehmen lassen (Nicht weil eine IDE
es besser kann, sondern schneller). Zusätzlich finde ich die
Projektverwaltung ab einer gewissen Größe in einer IDE deutlich
einfacher, als dies manuell zu händeln.
Andreas R. schrieb:> Ich benutze die Arduino IDE.
In der Arduino IDE sind einige Dinge sehr gut umgesetzt, allerdings
gefällt sie mir nicht, weil die meisten nützlichen Funktionen einer IDE
einfach weggelassen worden sind.
Zwischenzeitlich habe ich noch Atollic ausprobiert. Auch nicht schön.
Somit bleibe ich bei CooCox, obwohl ich die IDE nicht schön finde. So
muss ich mich aber nicht umgewöhnen.
1234567890 schrieb:> Eigene Makefiles zu schreiben ist genau das, was ich mir in Zukunft> sparen möchte, da die Projekte und damit auch die MakeFiles immer> umfangreicher werden.
Dann laß das Schreiben von Makefiles doch einfach bleiben. Man kann
eigentlich jeden Compiler auch ohne sowas aufrufen.
Aber mal was Grundsätzliches:
Wenn du Bastler bist, dann hast du mit Sicherheit keine wirklich großen
umfangreichen Projekte vor dir, also sehe ich dein argument als eher
tentativ an und nicht wirklich realistisch.
Wenn du kein Bastler bist, dann verdienst du damit deine Brötchen und
du solltest dir ne Toolchain raussuchen, die sowas per se nicht nötig
hat - auch wenn es ne Profi-Software ist, die Geld kostet.
Also was denn nun?
W.S.
W.S. schrieb:> Wenn du Bastler bist, ...W.S. schrieb:> Wenn du kein Bastler bist, ...
Bitte keine wilden Vermutungen! Ich bin kein Bastler, sondern ich
verdiene mein Geld damit. Es geht auch nicht darum, das es etwas kosten
darf. Das wäre an dieser Stelle egal. Normalerweise benutze ich Keil. Es
geht eher um ein paar rechtliche Geschichten vertsrickt mit technischen
Lösungen bzw. Lösungsmöglichkeiten.
An dieser Stelle kann ich auch sagen, dass ich eine Ganze Reihe von
Lösungen habe, aber mit keiner zufrieden bin. Entweder die Lizenzmodelle
der Software verbieten es oder Software bzw. das Software-Paket ist
grottig. Wichtig ist eigentlich nur, dass es nichts kosten darf, einfach
zu bedienen ist, einfach einzurichten ist und trotzdem eine vollständige
IDE mit allem drum und dran, den Rest analysiere ich dann schon selber.
Ich hatte die Vermutung, dass hier irgendwer noch eine schöne Idee bzw.
Umsetzung hat, auf die ich noch nicht gekommen bin.
W.S. schrieb:> Man kann> eigentlich jeden Compiler auch ohne sowas aufrufen.
Kann man, muss man aber nicht! Das ist dann noch schlimmer als MakeFiles
zu schreiben. Mit MakeFiles machen innerhalb des Projektes schon mal
alle das Gleiche. ;-)
1234567890 schrieb:> Openstm32 habe ich gestern noch ausprobiert! Danke für den Hinweis.> Allerdings bin ich damit nicht zufrieden.> Bernd K. schrieb:>> Eclipse/CDT mit GNU-Arm-Plugin und die offizielle arm-none-eabi-gcc>> Toolchain.>> Danke für diesen Hinweis. Dem werde ich als nächstes nachgehen.
Brauchst Du nicht, wenn Du nicht mit OpenSTM zufrieden bist, das ist ein
am STM32 angepasstes Elipse.
1234567890 schrieb:> Wichtig ist eigentlich nur, dass...
Du brauchst keine IDE, sondern einen Butler, der die Arbeit für dich
macht.
Und wenn du den Keil benutzt, dann schreibst du dir einmal ne .xcl für
Compiler und Linker und fertig ist die Laube. Wo ist eigentlich dein
Problem? Ich kann kein wirkliches Problem sehen, nur einen heftigen
Wunsch nach Schlaraffenland, wo einem die Chips von selbst fertig
gebraten auf die LP fliegen. Wär ja schön, ist aber illusorisch.
W.S.
1234567890 schrieb:> Eigene Makefiles zu schreiben ist genau das, was ich mir in Zukunft> sparen möchte, da die Projekte und damit auch die MakeFiles immer> umfangreicher werden.
Das muss nicht sein. In der Praxis wirst Du bald ein liebevoll
handgeklöppeltes (und daher menschenlesbares) Makefile haben das sich
mit nur kleinen oder (oder auch gar keinen) Änderungen für beliebige
neue Projekte wiederverwenden lässt, auch gibt es keinen Grund warum das
umfangreicher werden sollte wenn das Projekt wächst, es wird nur so
lange wachsen und reifen bis Du es für perfekt erachtest, zu dem
Zeitpunkt kennst Du es dann in- und auswendig wie Deine Westentasche.
Eclipse kann übrigens hervorragend mit Makefile-Projekten umgehen, wenn
Du den "Build-Output-Parser" richtig konfigurierst (die RegExp für den
Compilernamen) dann scannt der automatisch die Ausgaben des
Buildvorgangs und konfiguriert in Eclipse vollautomatisch alle
Include-Pfade und Defines für die Code-Assistenz, Du musst also nichts
doppelt pflegen.
Makefile hat den großen Vorteil daß wenn Du irgendwann doch mal die Nase
voll hast von Eclipse Du ohne irgendwas zu konfigurieren direkt zur
nächstbesseren IDE (also eine die heute noch nicht existiert) wechseln
kannst oder genausogut auch mal ohne Probleme nen vierwöchigen Vim- oder
Emacs-only Extremsport-Urlaub einlegen kannst wenn Dich mal unerwartet
das Retro-Fieber überkommt.
1234567890 schrieb:> den Rest analysiere ich dann schon selber.
Na dann analysiere mal.
Manche Leute haben die goldene Zitrone wirklich redlich verdient.
hatteaucheine zeit lang coocox
mitlerweile durchden STM32F7 zu dem OpenSTM / SW4/SW6 gewechselt.
weil da die unterstützung da ist und auch der debugger(colink EX ) nicht
so oft buggt
Ich nutze hier den nucleo stlink V2 der bisher ... 1/2Jahr recht
zuverlässig läuft.
bei größeren projekten in coocox klemmt auch ab und an die IDE .. findet
#defines nicht und man muss doch häufig neustarten.
die OpenSTM kiste ist auch nicht perfekt ...
( gerade was das linken in ordnern und so angeht ... )
aber sonst funktioniert die kiste
coocox hat momentan das problem das es scheinbar seit 1J nicht mehr
weiterentwickelt wird.
weder features , noch neue µC kommen hinzu
und das obwohl mir der gedanke einer multi-hersteller IDE für CM0 - CM4
durchaus gefallen hat.
Ich nehme einfach Notepad++, GCC, ein Linkerscript und ein Buildscript
(Batchdatei/Windows, Shellscript/Linux). Auf den Controller flashe ich
das dann mit CoFlash.
Zum gelegentlichen Debuggen nehme ich CoIDE, das ist aber sehr selten.
das geht sicher wunderbar wenn die projekte kleiner sind.
ich hab aktuell ca 500kb an compiliertem code.
dabei sind 5-6 libs die ich "nur" nutze
Da tot sich langsam die IDE schwer .. coocox ist bei > 200kb schon oft
genug abgestürtzt.
zumindest häuft sich der effekt wenn man viele dateien hat.
wenn der debugger dann mal nicht funktioniert wie gewünscht steht man
doof da
bei coocox war das dann oft so das er die symbole nicht mehr findet.
die debug infos sind dann einfach weg.
oft hilft dann neu starten der IDE und häufiges an/abstöpseln des
debuggers
Segger muss nicht sein, das istz ein verkappter Rowley.
Ich nutze mit großem Erfolg emIDE... zwar etwas betagter, aber dafür
stabil und direkte Unterstützjg für den JLink.
Falls einem der im Installer enthaltene Compiler zu alt sein sollte,
kann man den ganz einfach gegen etwas jüngeres austauschen.
1234567890 schrieb:> ich suche eine freie IDE für STM32 ohne irgendwelche Limitierungen,> welche sich vernünftig bedienen lässt.
Mit Vernunft lässt sich jede Toolchain effektiv nutzen, User ohne
Vernunft/Verstand haben es natürlich schwerer sich was aus
gcc/make/Editor zu stricken. Persönlich halte ich GUI-basierte
toolchains für eher unvernünftig, da nur schwer
automatisier/archivierbar. Nimm also make/gcc/scriptsprache und bastele
dir daraus was flottes.
STM32 schrieb im Beitrag #4715984:
> Segger muss nicht sein, das istz ein verkappter Rowley.>> Ich nutze mit großem Erfolg emIDE... zwar etwas betagter, aber dafür> stabil und direkte Unterstützjg für den JLink.
Klar basiert SES auf Rowley aber wo ist das Problem? Das sehe ich eher
als Vorteil weil auf etwas bewährtem aufgesetzt wurde.
Und emIDE ist letztlich auch von Segger... ;-).
Du sagst selber, dass du dich nicht mit den Unzulänglichkeiten von IDE's
herumschlagen willst. Die einzige richtige Konsequenz daraus ist, keine
IDE zu verwenden.
Also Editor der Wahl (Emacs) und den Rest mit Makefile. Das skaliert,
das funktioniert, das buggt nicht rum. Sogar debuggen geht im gdb-mode
genauso wie in der IDE
Als "Zwischending" zwischen IDE und Editor finde ich Geany schön - läd
zügigst, hat eine Projektverwaltung/Makefileaufruf und viele nette
Plugins (die man übrigens mit wenig Lernaufwand auch einfach selbst
schreiben kann), unter anderem ein Terminal.
Ist vielleicht einen Blick wert.
P.S.: Debugger-Plugin für GDB gibt's übrigens auch.
> Ich möchte mich eher wenig mit der IDE auseinandersetzen. Vielmehr> möchte ich mich mit meinen Projekten beschäftigen und nicht wie ich> die Unzulänglichkeiten der IDE umgehe.
Das widerspricht "kostenlos" :-)
> Dann lerne einen Compiler und Linker ohne IDE zu benutzen.
Oder so, noch besser :-)
> Aber mal was Grundsätzliches:> Wenn du Bastler bist, dann hast du mit Sicherheit keine wirklich großen> umfangreichen Projekte vor dir [...]
Ich habe in Hobbyarbeit die NetLase LC entwickelt. Diese streamt Daten
vom PC (ETH) und gibt diese mit harten Echtzeitanforderungen (Lag
zwischen Ton und Licht) analog für einen Laserprojektor wieder aus. Oder
streamt ILDA Files von SD Karte, DMX gesteuert.
Das Projekt wurde komplett mit ARM Tools (MDK-ARM & Middleware + ULINK
pro) entwickelt. Zugegeben, als Entwickler von Teilen dieser Tools komme
ich da kostenlos ran, aber ohne diese Werkzeuge wäre es verdammt viel
mehr Arbeit gewesen, die Anforderungen zu erfüllen und die Fehler zu
finden.
Vor allem sporadische Probleme sind schwer mit printf zu debuggen
(weil's die Laufzeit beeinflusst), sondern nur mit Werkzeugen, die nicht
invasiv sind (vgl. DWT, ITM). (Klugsch***: ja, ITM ist (geringfügig)
invasiv, wie UART).
Kostenlose IDEs oder Makefile/gcc sind im Hobbybereich eine feine Sache,
solange die Projekte nicht zu heftig werden. Und hier hat man auch
ausreichend Zeit, sporadische Probleme zu finden und zu beheben (häufig
durch rumprobieren).
In meiner AVR Zeit habe ich mit Editor & makefiles entwickelt. Debuggen
per UART printf (langsam) und Pin-toggling/Oszi (high speed Probleme).
Ab einer bestimmten Projektgrösse steigt aber der Gewinn komerzieller
Produkte und Debug Adapter gegenüber den komplett freien Sachen.
Und:
- Einige Tools sind bis 32k frei, was z.B. für CM0 oder viele Projekte
bereits ausreicht, vor allem, wenn man ohne DriverLibrary arbeitet.
- Aktuelle Boards haben meisst einen Debugger mit on Board (CMSIS-DAP,
JLink, ST-Link), welche einige Möglichkeiten von High Speed Debuggern
bieten, z.B. langsames SWO (DWT, ITM).
Fazit:
Auch im Hobbybereich lohnt es sich, mal in die Demo/freien Teile einer
komerziellen IDE reinzuschauen, und sich ggf. einen günstigen Debugger
(z.B. JLink Edu) zuzulegen sowie ggf. in eine günstigere IDE /
Middleware zu investieren.
Random .. schrieb:> In meiner AVR Zeit habe ich mit Editor & makefiles entwickelt. Debuggen> per UART printf (langsam) und Pin-toggling/Oszi (high speed Probleme).>> Ab einer bestimmten Projektgrösse steigt aber der Gewinn komerzieller> Produkte und Debug Adapter gegenüber den komplett freien Sachen.>> Und:> - Einige Tools sind bis 32k frei, was z.B. für CM0 oder viele Projekte> bereits ausreicht, vor allem, wenn man ohne DriverLibrary arbeitet.
Dem steht aber
> Dabei sollen nur die freien Tools ohne Limitierung berücksichtigt> werden.
des OP entgegen.
> - Aktuelle Boards haben meisst einen Debugger mit on Board (CMSIS-DAP,> JLink, ST-Link), welche einige Möglichkeiten von High Speed Debuggern> bieten, z.B. langsames SWO (DWT, ITM).
Da der OP mit der STM32-Serie arbeitet, kann er auch den ST-Link + gcc +
GDB verwenden - klappt hier sehr gut. Mit printf muss man
glücklicherweise auch bei freien IDEs schon länger nicht mehr arbeiten
:-)
> Fazit:> Auch im Hobbybereich lohnt es sich, mal in die Demo/freien Teile einer> komerziellen IDE reinzuschauen, und sich ggf. einen günstigen Debugger> (z.B. JLink Edu) zuzulegen sowie ggf. in eine günstigere IDE /> Middleware zu investieren.
Für reines Hobby halte ich die üblichen dort aufgerufenen Preise für zu
hoch. Selbst für uns lohnen sich diese nicht, weil wir nicht täglich
µC-Programme schreiben müssen.
Letztendlich ist es auch oft der einfache "Wohlfühlfaktor", der einen
diese oder jene IDE bevorzugen lässt. Wenn man "seine" IDE beherrscht,
muss eine andere schon deutlich mehr bieten, um gleiche Produktivität zu
erzielen.
Ob man als Hobbyist bei der großen Auswahl an freien Paketen so viel
Geld nur für eine IDE ausgeben möchte? Vermutlich eher nicht.
ich habe mit Coocox und OpenSTM jetzt als freie IDE gute erfahrungen
gemacht
ebenso anfangs LPCexpresso
nachteil dieser IDEs ist halt das sie oft herstellergebunden sind.
wenn man aber zB nur STM verarbeitet ... ist OpenSTM oder coocox eine
gute wahl
Debugger sind quasi umsonst .. ( nucleo / discovery )
und das ganze printfgedöhns kann man sich schenken
1234567890 schrieb:> Eigene Makefiles zu schreiben ist genau das, was ich mir in Zukunft> sparen möchte, da die Projekte und damit auch die MakeFiles immer> umfangreicher werden. Bisher habe ich eigene Makefiles geschrieben,> möchte mir dies aber von eine IDE abnehmen lassen (Nicht weil eine IDE> es besser kann, sondern schneller). Zusätzlich finde ich die> Projektverwaltung ab einer gewissen Größe in einer IDE deutlich> einfacher, als dies manuell zu händeln.
Makefiles sind bei lange nicht so übel wie ihren Ruf. Das Gute an
Makefiles ist, wenn man es einmal richtig gemacht hat, kann man das
als Grundgerüst für allen kommenden Projekten wiederverwenden. Ich kann
da das Dokument "Recursive Makefiles considered harmful" empfehlen:
http://aegis.sourceforge.net/auug97.pdf
1234567890 schrieb:> ich suche eine freie IDE für STM32
Mit AVRs und STM32 habe ich z.Z. nichts zu tun. Vor einer Weile bin ich
auf Platformio (http://platformio.org) gestoßen. Das ist der Atom Editor
+ PlugIns. Klingt interessant, aber keine Ahnung wie gut/machtig die
Umgebung ist.
Mano W. schrieb:> Das ist der Atom Editor
Der Atom Editor ist die Kulmination, die höchste Vollendung, die Krönung
aller Bemühungen der letzten 25 Jahre beim Streben nach der maximal
möglichen Anhäufung von Ressourcenverschwendung, Ineffektivität,
Von-Hinten-Durch-Die-Brust-Ins-Auge-Engineering und
Wenn-Das-Einzige-Gelernte-Werkzeug-Javascript-Ist-Dann-Hat-Halt-Jede-App
-Einen-Chrome-Browser-Statisch-Gelinkt-Mentalität in einem einzigen(!)
Softwareprodukt.
Das Gegenteil davon wäre Sublime.
Nur das Werbevideo für Atom, das ist wirklich grandios, das muß ich
unumwunden eingestehen, da waren echte Profis am Werk. Aber auch das
macht diese bizarre Software-Monstrosität keinen Deut besser.
Aber beides sind keine IDEs sondern nur hybsch anzusehende
Hipster-Texteditoren mit Plugin-Unterstützung, nicht mehr, nicht
weniger.
Bernd K. schrieb:> Aber beides sind keine IDEs sondern nur hybsch anzusehende> Hipster-Texteditoren mit Plugin-Unterstützung, nicht mehr, nicht> weniger.
Ich benutze VSCode oft. Einfach nur als Editor, aber auch zum Debuggen
bei Python. Das basiert wie Atom auf Electron. Das VSCode
resourcenhungrig ist, wäre mir noch nicht aufgefallen. Atom habe ich
auch mal eine Zeit lang benutzt, aber VSCode hat mir besser gefallen.
Sublime benutze ich zu Gunsten von VSCode nicht mehr.
Vom Editor zur IDE fehlt es ja nicht viel. Auch wenn nicht alles in
einem Programm sondern auf mehreren Programmen aufgeteilt ist, würde ich
von einer IDE sprechen.
Von Google gibt's auch solchene Videos:
https://www.youtube.com/watch?v=iEAjvNRdZa0
Coocox ist übrigens down:
http://www.coocox.org/
Nachdem die Version 2 in eine völlig verkehrte Richtung abbog und
eigentlich alle bei der 1.78 geblieben sind, das Forum voller Spam war
und keiner sich mehr drum kümmerte, ist das Projekt jetzt wohl gänzlich
tot.
Also ich hab keine Probleme damit die cmsis Files in der Coocox IDE zu
editieren?
Werde aber auch auf Eclipse CDT + GNU ARM umsteigen da es Coocox für
Linux nicht gibt, bei mir Coocox 1.78 zu einem Absturtz von Win10 führt
(beim Scrollen oder mit dem Cursor moven fangen manchmal alle Fenster an
zu blinken und hinundwieder überlebt win10 das und manchmal ist nur noch
ein leerer Bildschirm mit dem Mauszeiger zu sehen), und ich somit Win10
los werden möchte.
