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
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/
Eclipse/CDT mit GNU-Arm-Plugin und die offizielle arm-none-eabi-gcc Toolchain.
>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.
Bernd K. schrieb: > Eclipse/CDT mit GNU-Arm-Plugin und die offizielle arm-none-eabi-gcc > Toolchain. +1
Cyblord -. schrieb: > Andreas R. schrieb: >> Ich benutze die Arduino IDE. > > Sie sind raus Hoecker Aber warum das den? ;-)
<flame war on> vim + ein paar nette plugins + arm-none-eabi-gcc <\flame war off>
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.
Dergute W. schrieb: > Cyblord -. schrieb: >> Andreas R. schrieb: >>> Ich benutze die Arduino IDE. >> >> Sie sind raus Hoecker > > Aber warum das den? ;-) Es schein wirklich Leute zu geben, die die Arduino IDE für solche Zwecke benutzen: https://www.youtube.com/watch?v=-zwGnytGT8M oder http://jeelabs.org/book/1545d/
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.
Hier gibt's auch eine umsonst: http://atollic.com/resources/downloads/?hsCtaTracking=a4f81bfa-02ac-48fb-8cab-6ec932b0c5cf%7C05ea686a-9880-401c-b418-cdd496ceb8fd
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.
Und ich nutze Ausschließlich Keine. Läuft Perfekt von M0-M7
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... ;-).
... schrieb: > <flame war on> > > vim + ein paar nette plugins + arm-none-eabi-gcc > > <\flame war off> an meinen Code lass ich nur vi und gcc ;-)
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.
:
Bearbeitet durch Moderator
> 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 :-)
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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.
schade die 1,78 war auch mine letzte version. die 2 hatte ich nie benutzt ....
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.
coocox geht wieder.. wurde aber ein opfer. http://www.coocox.org/forum/viewforum.php?f=1 mehr spam als eigentliche beiträge im forum. nunja
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.