Guten Morgen, für die Programmierung des ATSAME70 empfiehlt Microchip ja das Atmel-Studio. Was wäre eine gute Alternative für Linux-Systeme? Eclipse-CDT? Aber mit welchen Plugins? Finde es schade dass es von Atmel/Microchip nix Eclipse-basiertes wie bei TI oder ST gibt :-( Grüße und Danke für die hoffentlich kommenden Tipps, Andreas
Wenn es nichts entsprechendes für eclipse gibt, lohnt der Aufwand nicht da was zu erfinden. Nimm Virtualbox mit nem Win drin. Mache ich auch so. Auch für ein paar andere Win only Programme.
pegel schrieb: > Nimm Virtualbox mit nem Win drin. > > Mache ich auch so. Auch für ein paar andere Win only Programme. Mache ich mit Solidworks auch so, aber noch hoffe ich dass sich was findet, weils mit VB doch etwas ein Krampf ist...
Andreas F. schrieb: > weils mit VB doch etwas ein Krampf ist... Nur mal so aus Interesse. Wieso? Habe das ganze Atmel und Xilinx Zeug in VB, ohne Probleme.
Wie wäre es mit NetBeans und gmake? Ist erste Empfehlung vom Hersteller.
Also hier empfehlen sie dick Mplab X. Das habe ich schon selbst unter Linux genutzt. https://www.microchip.com/wwwproducts/en/ATSAME70Q21
jemand schrieb: > Das habe ich schon selbst unter > Linux genutzt. Ich installier es gerade. Was hälst du von der IDE?
Wenn ich mich nicht irre, ist das ein modifiziertes NetBeans. Ich bin andere IDEs gewohnt (IntelliJ, Vim), aber Mplab macht für mich auch dass, was es soll. Der MCC (bzw das entsprechende Harmony-Äquivalent) scheint ganz brauchbar. Aber ich habe auch keine exzessive Erfahrung mit der IDE. Sie generiert übrigens Makefiles, man kann das Projekt also auch ohne die IDE kompilieren. Ich weiß allerdings noch nicht, was ich davon halten soll, dass die Compiler von Microchip inzwischen eine Bezahlversion hat.
Mit etwas Arbeit funktioniert das Atmel Framework auch mit Ecipse. Das Framework lässt sich ja getrennt von der IDE herunterladen. Als Anfänger ist dies nicht zu empfehlen, da man sich das Projekt zum Device selbst zusammen bauen muss. In einer Virtuellen Maschine laufen zu lassen, macht aufgrund der enormen Ressourcen von der IDE keinen Spaß.
Marco H. schrieb: > Mit etwas Arbeit funktioniert das Atmel Framework auch mit Ecipse. Soviel Arbeit wars garnicht. Microchip hat sogar eine schöne Anleitung geschrieben um zumindest deren Beispielprojekte lauffähig zu machen, siehe https://microchipdeveloper.com/atstart:eclipse.
Meine Handyflasherfahrungen mit Linux, Virtualbox unter WinXP sind hervorragend. USB 2.0 wird dort voll untertützt. Meine MicrochipPICs habe ich auch über MPLAB geflasht. Die Alternative das ganze bei Atmels über die Linux-Kommmandozeile zu machen finde ich aber wesentlich bequemer. Ansonsten verwende ich den Windows-Sch...... nur noch für mein Hantek-Oszilloskop. Ich empfehle aber auch Eclipse und Linux, da es umfangreiche Unterstützung für die meisten Atmel-Prozessoren bietet. Wem das zuviel ist, dem reicht vielleicht auch das Arduino-Konzept.
avrdude heisst das Kommandozeilenprogramm unter Linux. gibt es in jedem Repository
min schrieb: > dem reicht vielleicht auch das Arduino-Konzept. Bitte vermeiden Sie das böse "A"-Wort! Tatsächlich bin ich jetzt mit der Eclipse-Lösung voll zufrieden. Das Eclipse Embedded C/C++ Plugin bietet guten Embedded-Support und Debug-Möglichkeiten mit z.B. J-Links und das EmbSysRegView-Plugin bietet scheinbar sogar Registerzugriff.
Hat ein ATSTAME70 nicht einen ARM Prozessor? Weil generell würde ich jetzt behaupten, auch wenn jetzt mein Beitrag als nicht empfehlenswert markiert wird, dass man unter Linux keine IDE verwenden sollte. Eine kurze Anekdote: Vor langer Zeit, wie ich mit dem Programmieren angefangen habe wollte ich immer eine IDE benutzen. Auch als ich 2007 auf Linux umgestiegen bin. Ich suchte tatsächlich einen Ersatz für Visual Studio. :) Leider wusste ich nicht, da ich nur mit IDE's programmiert habe, wie man GCC bedient. Sprich ich konnte ein simples Hello World Programm nicht auf der Kommandozeile kompilieren, wusste weder was Makefiles sind, geschweige was ein Linker Script ist. Nicht falsch verstehen, IDE's nehmen einen viel ab. Allerdings sollte man sich wirklich mit den oben genannten Basics einmal auseinander setzen und nicht immer der IDE vertrauen. Klar, man muss eventuell viel Zeit investieren, aber es lohnt sich. Jetzt verwende ich unter Linux lediglich einen Texteditor (natürlich mit Syntaxhighlighting - bin ja nicht ganz verrückt), GIT und GCC.
Andreas F. schrieb: > Was wäre eine gute Alternative für Linux-Systeme? > Eclipse-CDT? Aber mit welchen Plugins? Eclipse-CDT + GnuARM + OpenOCD + GDB verwende ich immer mit STM32. Gibt eine ganze Eclipse-Distribution, in der schon alles enthalten ist: https://projects.eclipse.org/projects/iot.embed-cdt/downloads/
Johannes K. schrieb: > Jetzt verwende ich unter Linux lediglich einen Texteditor (natürlich mit > Syntaxhighlighting - bin ja nicht ganz verrückt), GIT und GCC. Wie debuggst Du dann oder hälst z.B. das Programm an um die Timer-Register auszulesen weil die Peripherie mal wieder nicht will wie du willst? Alles über printf? Finde den Ansatz zwar erstrebenswert aber für Embedded nicht so realistisch. Mampf F. schrieb: > Eclipse-CDT + GnuARM + OpenOCD + GDB verwende ich immer mit STM32. Warum nicht die Cube IDE von ST? Für Arch- oder Manjaro-Nutzer gibt es mit dem eclipse-arm Paket übrigens bereits eine Eclipse-CDT die das GnuARM schon onboard hat: https://aur.archlinux.org/packages/eclipse-arm/
Andreas F. schrieb: > Mampf F. schrieb: >> Eclipse-CDT + GnuARM + OpenOCD + GDB verwende ich immer mit STM32. > > Warum nicht die Cube IDE von ST? Mein Setup entspringt noch der Zeit, als es die Cube IDE nicht gab. Zwischenzeitlich hatte ich Cube IDE mal ausprobiert (ist ja fast identisch), aber bei STMicro scheint die Software immer nur zu funktionieren, wenn sie neu ist. Letztens hatte ich eine neuere Version von Cube IDE installiert und hatte nur Probleme mit diesem Mistding. Die konnte auch nicht mehr die .loc-Dateien von CubeMX lesen (obwohl die auch mit der neuesten Version erzeugt wurden). Ach und kompilieren ging auch nicht mehr. Eine ältere Version funktionierte problemlos. (CubeMX kann neuerdings keine Cube-IDE Projekt mehr fehlerfrei erzeugen ... STMicros Software ist zum Kotzen ...) Naja, dann hab ich den Mist wieder gelöscht und bin mit meinem bewährten Setup unterwegs, bei dem schon immer alles bestens funktioniert.
Mampf F. schrieb: > Letztens hatte ich eine neuere Version von Cube IDE installiert und > hatte nur Probleme mit diesem Mistding. Die konnte auch nicht mehr die > .loc-Dateien von CubeMX lesen (obwohl die auch mit der neuesten Version > erzeugt wurden). Das ist beruhigend zu hören, zumal ich mich unlängst gefragt habe in wieweit Cube und die ST32 HAL im professionellen Umfeld eingesetzt werden. Fazit: Besser garnicht.
Andreas F. schrieb: > Mampf F. schrieb: >> Letztens hatte ich eine neuere Version von Cube IDE installiert und >> hatte nur Probleme mit diesem Mistding. Die konnte auch nicht mehr die >> .loc-Dateien von CubeMX lesen (obwohl die auch mit der neuesten Version >> erzeugt wurden). > > Das ist beruhigend zu hören, zumal ich mich unlängst gefragt habe in > wieweit Cube und die ST32 HAL im professionellen Umfeld eingesetzt > werden. Fazit: Besser garnicht. Meine Erfahrungen hatte ich hier geschildert: Beitrag "STM32 HAL Hass-Thread ;-)" duckundweg
Andreas F. schrieb: > Johannes K. schrieb: >> Jetzt verwende ich unter Linux lediglich einen Texteditor (natürlich mit >> Syntaxhighlighting - bin ja nicht ganz verrückt), GIT und GCC. > > Wie debuggst Du dann oder hälst z.B. das Programm an um die > Timer-Register auszulesen weil die Peripherie mal wieder nicht will wie > du willst? Alles über printf? Finde den Ansatz zwar erstrebenswert aber > für Embedded nicht so realistisch. Ich muss zugeben, die meiste Zeit verwende ich wirklich nur printf(). Allerdings kommt es ganz auf den Code drauf an. Zum Beispiel Algorithmen, die an keine Architektur gebunden sind - also in reinem C/C++ gehalten sind - debugge ich auf dem Hostsystem mit GDB. Lass ich also zuerst nicht auf der Zielarchitektur laufen. Wo ich einen Debugger für die Zielarchitektur manchmal benötige ist, ist wenn ich Teile in Assembler schreibe und hier etwas nicht nach meinen Vorstellungen läuft. Ein größeres Embedded-Projekt wo ich schon mal einen Patch veröffentlicht habe ist U-Boot. Kbuild und Make. (Ganz stolz auf mich bin, dass der Patch angenommen wurde.) Gut, ich muss zugegen, dass ich für meine Projekte keine Deadline habe. Somit kann ich mir das erlauben.
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.