Hallo, ich habe Fragen zu Eclipse. Und zwar vor dem Hintergrund, dass ich zum einen in die ARM Programmierung einsteigen will/muss und zum anderen gerne aber auch noch zukünftig das eine oder andere Projekt mit AVR Controllern umsetzen möchte. Mir ist bekannt, dass es für Eclipse entsprechende Plugins gibt. Bei meiner Recherche bin ich z.B. auf das hier gestoßen: https://gnu-mcu-eclipse.github.io/ Das sieht für mich erst mal so aus, als würde das ein Eclipse mit ARM/GNU-GCC Plugin sein. Doch es scheint mir so, als wären da noch mehr Anpassungen dabei. Oder täuscht das? Kann ich auch ein "standard-" Eclipse nehmen und dann die entsprechenden Plugins nachinstallieren? Ist es möglich das Eclipse von "https://gnu-mcu-eclipse.github.io/"; zu nehmen und da dann auch noch das AVR Plugin "rein hängen", oder ist zu erwarten dass sich das "beißt"? Schön wäre eben, dass ich mit einer Eclipse Installation für ARMs wie auch AVRs Entwickeln kann. Und bevor jemand fragt...Ja ich befasse mich zum aller ersten Mal mit ARM. Aber irgendwo muss man ja mal anfangen. Habe mir für diesen Zweck mal schon vor einiger Zeit von Olimex das STM32-H103 und den ARM-USB-OCD geholt. Nette Grüße
GNU MCU ist ein Eclipse Plugin. Also ja, man kann ein "Standard" Eclipse nehemen und das bequem dazu installieren. Prinzipiell ist Eclipse dafür konzipiert eine IDE für alles zu sein. Alternativ gibt es derzeit direkt von ST noch die STM32CubeIDE die mehr oder weniger ein Eclipse + der für ST relevante Teil von GNU MCU + ein paar Extras ist. Wie der Name vermuten lässt ist hier etwa bereits STM32Cube integriert, sofern du das nutzen möchtest.
Ich hänge mich mal in diesen Thread Ich würde gerne statt STM32CubeIDE das normale Eclipse benutzen (weil ich Eclipse ohnehin brauche). Die meisten Anleitungen zur Integration eines CubeMX-Projektes in Eclipse sind leider ziemlich kompliziert, z.B. http://www.raspberry-pi-geek.de/Magazin/2016/06/STM32-Entwicklung-mit-CubeMX-und-Eclipse/(offset)/2 Zu der Zeit konnte CubeMX allerdings auch noch keine Makefile exportieren. 1. Lassen sich CubeMX-Makefile-Projekte auf einfache Weise in Eclipse integrieren? Die betreffenden Projekte sind so generiert, dass sie bereits alle benötigten Firmware-Dateien in Unterordnern enthalten. 2. Ist es eigentlich so, dass die Cube-Firmware-Dateien zwangsweise Teil des Eclipse-Plugins sind (wäre für meine Zwecke überflüssiger Overhead)? Das war z.B. hier zu lesen (der Beitrag ist allerdings ziemlich alt): https://www.carminenoviello.com/2014/12/28/setting-gcceclipse-toolchain-stm32nucleo-part-1/ 3. Klappt das Debuggen mit dem OpenOCD-Plugin? 4. Gehen damit irgendwelche wichtigen Sachen nicht, die mit STM32CubeIDE funtkionieren?
Ich hab CubeIDE problemlos um AVR-Unterstützung erweitert. Auch bei CubeIDE kann man praktisch alle Eclipse-Plugins nutzen und hat bereits ein fertiges System für STM32 als Basis.
Fragender schrieb: > Ich würde gerne statt STM32CubeIDE das normale Eclipse benutzen Sobald du Plugins installiert, hast du kein normales Eclipse mehr. Da es oft Inkompatibilitäten zwischen Plugins und Eclipse Versionen gibt würde ich dir dringend raten, die Idee "Eine IDE für alles" aufzugeben. Die STM32Cube IDE ist gut, also verwende sie. Für AVR kannst du gerne eine andere Eclipse Variante nutzen. Ich persönlich bevorzuge QT Creator.
Nach diversen Problemen bei gleichzeitiger Installation von AVR und ARM Plugins in Eclipse CDT bin ich auf zwei getrennt Eclipse umgestiegen. Besser als sich gegenseitige beeinflussende Plugins ISR das allemal.
Ich entwickle mittlerweile AVR mit Eclipse ohne das "AVR-Eclipse"-Plugin. Da es schon seit langer Zeit nicht mehr weiterentwickelt wird, und nur noch Probleme macht. Stattdessen binde ich den AVR-GCC einfach über das "Cross GCC"-Plugin ein. (Compiler Einstellungen und Programmer Einbindung muss dann von Hand erledigt werden) Gleichzeitig entwickle ich auch für STM32, und habe das "GNU MCU Eclipse"-Plugin drin. Funktioniert zusammen ohne Probleme. Ich muss aber sagen, dass die Einrichtung am Anfang schon etwas aufwendig ist. Für Newbies ist Eclipse vielleicht nicht der beste Einstieg, wenn mit der Microcontroller Entwicklung angefangen wird. Da ich aber in den Hersteller eigenen IDEs (die eventuell auch auf Eclipse basieren) viele Komfortfunktionen vermisse und nicht nachrüsten kann. Tue ich mir den Aufwand an, dies alles in Eclipse zu integrieren.
Fragender schrieb: > Ich würde gerne statt STM32CubeIDE das normale Eclipse benutzen (weil > ich Eclipse ohnehin brauche). > > Die meisten Anleitungen zur Integration eines CubeMX-Projektes in > Eclipse sind leider ziemlich kompliziert, z.B. Besteht hier evtl. der Irrtum, dass man die STM32CubeIDE ausschließlich nur mit CubeMX nutzen kann? Dem ist nicht so. Ich programmiere in der IDE ohne CubeMX und programmiere in C++. Einfach ein Projekt anlegen, Code ohne Anpassungen in CubeMX generieren und die CubeMX Datei entsorgen. Wenn C++ verwendet werden soll, diese Dateien einfach in .cpp umbenennen. Zusätzlich würde ich auch HAL entsorgen und nur CMSIS verwenden. Startup Code .s und die Linkerscripte kann man behalten. Dann braucht man sich damit nicht mehr herumärgen, hat eine Eclipse IDE für z.B. STM32 ohne lästiges Plugin Gebastel.
Christian K. schrieb: > Ich muss aber sagen, dass die Einrichtung am Anfang schon etwas > aufwendig ist. Deswegen mag ich QT Creator. Das war von Anfang an für Cross-Compiling mit gcc ausgelegt und das merkt man deutlich.
Curby23523 N. schrieb: > Einfach ein Projekt anlegen, Code ohne Anpassungen in CubeMX generieren > und die CubeMX Datei entsorgen. Man kann neue Projekte auch ganz ohne Cube Kram anlegen, dann muss ma Curby23523 N. schrieb: > Einfach ein Projekt anlegen, Code ohne Anpassungen in CubeMX generieren > und die CubeMX Datei entsorgen... Zusätzlich würde ich auch HAL > entsorgen und nur CMSIS verwenden. In diesem Fall kannst du alternativ ein leeres Projekt anlegen und die CMSIS Dateien manuell dazu kopieren. Ich habe alle CMSIS Core Header mal aus den Cube-HAL Paketen extrahiert: http://stefanfrings.de/stm32/CMSIS-STM32.zip
Stefan F. schrieb: > In diesem Fall kannst du alternativ ein leeres Projekt anlegen und die > CMSIS Dateien manuell dazu kopieren. Ich habe alle CMSIS Core Header mal > aus den Cube-HAL Paketen extrahiert: Geht auch klar. Aber den anderen Weg finde ich einfacher. Das ist jedem überlassen.
Stefan F. schrieb: > Man kann neue Projekte auch ganz ohne Cube Kram anlegen, dann muss ma klar, für ein Blinky reicht das. Aber steigt man dafür von AVR auf ARM um? Was machst du wenn du ein grösseres Gerät/Controller bauen möchtest mit Display, USB, Ethernet, SD Card, diversen Schnittstellen? Klar, Datenblatt lesen. Dann liegt der Kram nach 2 Wochen wieder in der Schublade. Oder du schaffst es, aber es sind zwei Sommer und Winter vergangen. Cube hilft schonmal, aber was machst du wenn dein F103 nicht mehr reicht? Wie portierst du dein Programm auf einen grösseren F4/F7? Oder gar NXP oder Nordic (andere Mütter haben auch schöne Töchter)? Für einen anderen STM32 in der Familie kann man wieder den Cube rollen lassen, aber wenn man BLE haben möchte und es gibt die schönen kleinen nRF52xx Module? Man kann Alternativ Software auch in wiederverwendbaren Modulen entwickeln, sogar auf µC...
Curby23523 N. schrieb: > Geht auch klar. Aber den anderen Weg finde ich einfacher. Das ist jedem > überlassen. Hauptsache man muss nicht auch noch das Linkerscript und den Startup-Code selber schreiben. Damit wäre ich überfordert.
Christian K. schrieb: > Gleichzeitig entwickle ich auch für STM32, und habe das "GNU MCU > Eclipse"-Plugin drin. > Funktioniert zusammen ohne Probleme. Entwickelst Du dann die Projekte in Eclipse direkt? Oder hast Du auch Erfahrungen bzgl. des Einbindens von Makefile-CubeMX-Prokjekte? Ich frage mich, ob man dann in dem Fall das "GNU MCU Eclipse" überhaupt braucht, denn ein Makefile-Projekt ist ja (bis auf den GCC-Compiler und die GNU-Tools, die aber bereits auf dem System vorhanden sind und in Eclipse eingebunden werden müssten) unabhängig von weiteren Dateien. Bzgl. des "openOCD Debug"-Plugin habe ich Verständnisprobleme: In https://gnu-mcu-eclipse.github.io/debug/openocd/ ist als "GNU MCU Eclipse OpenOCD debugging plug-in" diese Seite verlinkt: https://gnu-mcu-eclipse.github.io/openocd/download/ Dort ist aber explizit nicht von einem Plug-in die Rede, sondern von openOCD-Binaries (die auch mittlerweile woanders gehostet sind): "Please note that the OpenOCD debugging plug-ins are not included in these packages, and need to be installed as usual." Wo gibt es denn dann das besagte "GNU MCU Eclipse OpenOCD debugging plug-in"? Curby23523 N. schrieb: > Besteht hier evtl. der Irrtum, dass man die STM32CubeIDE ausschließlich > nur mit CubeMX nutzen kann? Dem ist nicht so. Ich programmiere in der > IDE ohne CubeMX und programmiere in C++. Aber hat man dann nicht dieselben von Stefan F. und Carl D. erwähnten Kompatibilitätsprobleme, die oben. Z.B. würde ich ein gerne ein Plugin zum Konfigurieren von openPowerlink-Gerätedateien benutzen. Ist die Frage, ob das dann in der STM32CubeIDE richtig läuft.
Johannes S. schrieb: > Display, USB, Ethernet, SD Card, diversen Schnittstellen Ab einer gewissen Komplexität kann man für vereinzelte Peripherie auf HAL zurückgreifen. Aber nicht für Clocks, GPIOs, RTC, DMA, ADC, DAC, USART, SPI,... die sind nicht wesentlich komplexer als bei einem AVR.
Hallo, als ich damals für STM32 programmiert habe, hat mir die folgende 3-teilige Anleitung sehr gut geholfen da sie sehr ausführlich und verständlich ist: https://www.carminenoviello.com/2015/06/04/stm32-applications-eclipse-gcc-stcube/ https://www.carminenoviello.com/2015/01/07/setting-gcceclipse-toolchain-stm32nucleo-part-2/ // Debugging einrichten: https://www.carminenoviello.com/2015/01/16/setting-gcceclipse-toolchain-stm32nucleo-part-iii/
Fragender schrieb: > Wo gibt es denn dann das besagte "GNU MCU Eclipse OpenOCD debugging > plug-in"? Das weiss ich nicht. Allerdings nutze ich gerne die auf Eclipse basierte "System Workbench for STM32", wo OpenOCD samt Plugin funktionsfähig vorkonfiguriert sind.
Fragender schrieb: > Entwickelst Du dann die Projekte in Eclipse direkt? > Oder hast Du auch Erfahrungen bzgl. des Einbindens von > Makefile-CubeMX-Prokjekte? > Ich frage mich, ob man dann in dem Fall das "GNU MCU Eclipse" überhaupt > braucht, denn ein Makefile-Projekt ist ja (bis auf den GCC-Compiler und > die GNU-Tools, die aber bereits auf dem System vorhanden sind und in > Eclipse eingebunden werden müssten) unabhängig von weiteren Dateien. Ich entwickle komplett in Eclipse. CubeMX habe ich für meine STM32 Projekte noch nie verwendet. Auch die HAL versuche ich wenn möglich zu vermeiden. "GNU MCU Eclipse" bringt für die STM32 F-Serien in C-Geschriebenen Startup-Code mit. die S-Dateien von CubeMX werden nicht benötigt. Auch verwende ich immer den Interne Builder, gehe also nicht über Make-Files. Fragender schrieb: > Bzgl. des "openOCD Debug"-Plugin habe ich Verständnisprobleme: > In https://gnu-mcu-eclipse.github.io/debug/openocd/ > ist als "GNU MCU Eclipse OpenOCD debugging plug-in" > diese Seite verlinkt: > https://gnu-mcu-eclipse.github.io/openocd/download/ > Dort ist aber explizit nicht von einem Plug-in die Rede, sondern von > openOCD-Binaries (die auch mittlerweile woanders gehostet sind): > "Please note that the OpenOCD debugging plug-ins are not included in > these packages, and need to be installed as usual." > Wo gibt es denn dann das besagte "GNU MCU Eclipse OpenOCD debugging > plug-in"? Für das Programmieren und debuggen mittels OpenOCD wird in Eclipse nur das Plugin "C/C++ GDB Hardware Debugging" benötigt. Die OpenOCD.exe starte ich manuell. Eclipse (bzw. der GDB) verbindet sich über TCP mit OpenOCD. (kann auch auf einem anderen Rechner laufen) Das "OpenOCD"-Plugin hilf einen nur die OpenOCD.exe automatisch zu starten wenn man das nicht manuell machen will.
derjaeger schrieb: > als ich damals für STM32 programmiert habe, hat mir die folgende > 3-teilige Anleitung sehr gut geholfen da sie sehr ausführlich und > verständlich ist Ja, danke. Die hatte ich auch schon gelesen. Sind allerdings schon älter (2014/2015). Dort ist kein eigenes 'Eclipse Debug plug-in' erwähnt. Nach dem Screenshot aus Teil 1 http://www.carminenoviello.com/wp-content/uploads/2014/12/Schermata-2014-12-20-alle-17.44.45.png scheint das "GNU MCU Eclipse OpenOCD" dann Teil des "GNU MCU Eclipse" zu sein (jedenfalls damals) Funktioniert(e) bei Dir Debuggen über SWD korrekt? "Unfortunately SWD support in the current OpenOCD version (0.8.x) is not that great" https://gnu-mcu-eclipse.github.io/debug/openocd/ Christian K. schrieb: > Auch verwende ich immer den Interne Builder, gehe also nicht über > Make-Files. Geht das denn Deines Wissens nach, Makefile-Projekte zu benutzen (Grund für Makefile siehe unten)? Stefan F. schrieb: > Allerdings nutze ich gerne die auf Eclipse basierte > "System Workbench for STM32", wo OpenOCD samt Plugin funktionsfähig > vorkonfiguriert sind. Lassen sich denn in SW4STM32 und/oder STM2CubeIDE CubeMX-Makefile-Projekte einbinden, kompilieren und debuggen? Das Makefile-Projekt wird zur Weiterverarbeitung an anderer Stelle benötigt und ich möchte nicht für ein Projekt zwei Projektarten pflegen müssen.
Fragender schrieb: > Lassen sich denn in SW4STM32 und/oder STM2CubeIDE > CubeMX-Makefile-Projekte einbinden, kompilieren und debuggen? Cube MX kann Projekte für die System Workbench anlegen. Bevor ST Atollic kaufte, empfahl ST diese IDE als kostenlose Alternative. Die STM32 Cube IDE kann Projekte von der System Workbench öffnen (und dabei konvertieren). Kompilieren und Debuggen geht in beiden Fällen.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.