Forum: Mikrocontroller und Digitale Elektronik ATSTAME70 - Linux-IDE-Empfehlungen?


von Andreas F. (andgset)


Lesenswert?

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

von pegel (Gast)


Lesenswert?

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.

von Andreas F. (andgset)


Lesenswert?

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...

von pegel (Gast)


Lesenswert?

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.

von neuer PIC Freund (Gast)


Lesenswert?

Wie wäre es mit NetBeans und gmake?

Ist erste Empfehlung vom Hersteller.

von jemand (Gast)


Lesenswert?

Empfehlen die nicht Mplab X? Das gibt's auch für Linux.

von jemand (Gast)


Lesenswert?

Also hier empfehlen sie dick Mplab X. Das habe ich schon selbst unter 
Linux genutzt.
https://www.microchip.com/wwwproducts/en/ATSAME70Q21

von Andreas F. (andgset)


Lesenswert?

jemand schrieb:
> Das habe ich schon selbst unter
> Linux genutzt.

Ich installier es gerade. Was hälst du von der IDE?

von jemand (Gast)


Lesenswert?

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.

von jemand (Gast)


Lesenswert?

Fazit: ich finde die ganz in Ordnung

von Marco H. (damarco)


Lesenswert?

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ß.

von Andreas F. (andgset)


Lesenswert?

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.

von min (Gast)


Lesenswert?

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.

von min (Gast)


Lesenswert?

avrdude heisst das Kommandozeilenprogramm unter Linux.
gibt es in jedem Repository

von Andreas F. (andgset)


Lesenswert?

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.

von Johannes K. (krjdev)


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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/

von Andreas F. (andgset)


Lesenswert?

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/

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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.

von Andreas F. (andgset)


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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

von Johannes K. (krjdev)


Lesenswert?

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
Noch kein Account? Hier anmelden.