ATSTAME70 - Linux-IDE-Empfehlungen?

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

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

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

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.

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.