Forum: Compiler & IDEs Welchen Compiler/IDE benutzt ihr für uController?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Max M. (max_mueller)


Lesenswert?

Ich nutze schon ewig die von Mikroe, wie alle, haben die natürlich auch 
ihre Probleme, aber man kann damit arbeiten.
Ich liebäugle immer mal wieder mit CubeMX bzw der CubeIDe aufgrund ihrer 
"Vorteile", aber am Ende finde ich den erzeugten Code so unfassbar 
unübersichtlich, von der Hall ganz zu schweigen, das ich meist schon 
nach wenigen Minuten abgeschreckt bin.
Keil scheint auch ganz angenehm zu sein, ist aber für privat etwas teuer 
(Habe von mikroe die Lifetime Lizenzen)
IAR sieht auch super aus und kommt mikroe wohl am nächsten?
Aber was kostet der? Und wieso haben die keine festen Preise für 
Privatkunden? das schreckt komplett ab
CrossWorks?

Ich vermute mal, im Hobbybereich wird es wohl die CubeIDE sein?

: Bearbeitet durch User
von Andreas B. (bitverdreher)


Lesenswert?

MCUxpresso

von Andreas M. (amesser)


Lesenswert?

1
$ apt install gcc-arm-none-eabi

Dazu Editor der Wahl, z.B. Vim :-) Nee, ich benutze VSCode, aber mit dem 
Compiler oben. Ansonsten: Cross-Toolchain selber bauen ist kein 
Hexenwerk.

: Bearbeitet durch User
von Max M. (max_mueller)


Lesenswert?

Oh, ok, den kannte ich noch gar nicht.
Wieso nutzt du überhaupt NXP und nicht STM?

Andreas B. schrieb:
> MCUxpresso

: Bearbeitet durch User
von Andreas B. (bitverdreher)


Lesenswert?

Max M. schrieb:
> Oh, ok, wieso nutzt du überhaupt NXP?
>
Warum nicht?
Ich finde sie uebersichtlicher als  die STM.

von Max M. (max_mueller)


Lesenswert?

Einfach, weil ich den Eindruck habe, das alle Welt, also zumindest in D, 
auf STM setzt, ich selber auch, da ich dachte, das es da die meiste 
Vielfallt gibt und so

Andreas B. schrieb:
> Max M. schrieb:
>> Oh, ok, wieso nutzt du überhaupt NXP?
>>
> Warum nicht?
> Ich finde sie uebersichtlicher als  die STM.

von Vax W. (Gast)


Lesenswert?

Max M. schrieb:

> Aber was kostet der? Und wieso haben die keine festen Preise für
> Privatkunden? das schreckt komplett ab
> CrossWorks?
>

Weil Du keine Privatkunden im Business-Bereich haben willst. Eine 
Weiterentwicklung einer Software kannst Du heute (2023) eigentlich nur 
noch mit einem Miet-Modell stemmen. Der Bastler will natuerlich nicht 
jaehrlich zahlen, gleichzeitig muss der Software-Ersteller staendig 
Updates (allein wenn sich das Betriebssystem des Hosts aendert) liefern.

> Ich vermute mal, im Hobbybereich wird es wohl die CubeIDE sein?

Besser ausgedrueckt: OpenSource-Loesung. Eclipse ist Mah-Mah, ich bin 
ueber die Qualitaet von Visual Studio Code sehr beeindruckt. Sehr 
positiv ueberrascht (fuer ein Microsoft-Produkt).

von Markus M. (adrock)


Lesenswert?

Ich nehme Segger Embedded Studio.

Leider harmoniert es nicht mit CubeMX, die Projekte zu importieren ist 
immer ziemlich umständlich.

Ich verwende CubeMX inzwischen ganz gerne wenigstens für die 
CLock-Konfiguration/Initialisierung. Danach kann man mit 
selbstgestrickten Libs/Funktionen weitermachen wenn es nicht die HAL 
sein soll.

: Bearbeitet durch User
von Michael B. (laberkopp)


Lesenswert?

Max M. schrieb:
> Ich vermute mal, im Hobbybereich wird es wohl die CubeIDE sein?

Man nimmt das, was der Hersteller (Arduino bezeichne ich auch mal als 
Hersteller) gratis zur Verfügung stellt. Atmel/Microchip Studio, 
Arduino, HWB, MPLAB, ..

Ja, das ist pro Hersteller was anderes, aber man hat dabei die höchste 
Wahrscheinlichkeit, dass es funktioniert.

Multi-Cross-Plattform, dann auch noch von Fremdanbietern, geht meist in 
die Hose.

von J. S. (jojos)


Lesenswert?

Man kann CubeMX Projekte auch in VSC übernehmen, da gibt es mittlerweile 
eine Extension dafür.
HAL (nicht Hall) oder LL generierter Code bleibt da aber auch wie er 
ist. Und wenn man nachträglich Änderungen an der Konfiguration in CubeMX 
vornimmt weiss ich nicht wie gut sich das wieder in die VSC 
Konfiguration übernehmen lässt.
Der Debugger in der CubeIDE ist sehr gut, auch wenn man mehrere Targets 
gleichzeitig debuggen muss. LiveView gibt es auch oder FreeRTOS 
Unterstützung. Die Cortex-Debug Extension für VSC ist aber auch nicht 
schlecht, die hinkte anfangs etwas hinterher, kennt jetzt auch 
verschiedene RTOS.
MCUXPresso ist ja das Gleiche in grün, bzw. das alte Eclipse für NXP. 
Das war auch schon immer gut, aber die Hersteller unterstützen natürlich 
nur ihre eigenen Produkte, obwohl das Eclipse darunter gleich ist.
VSC gefällt da mir bisher am Besten, für eigene Projekte nehme ich das. 
Und immer noch mit Mbed, jetzt aus dem CE Fork.

: Bearbeitet durch User
von Ada J. Quiroz (inschnier)


Lesenswert?

Diejenige, die vom Hersteller zur Verfügung gestellt wird.

von Steve van de Grens (roehrmond)


Lesenswert?

Die Cube IDE zwingt dich nicht dazu, Cube MX oder die HAL zu verwenden. 
Sie unterstützt auch Projekte ohne dieses Framework.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

Michael B. schrieb:
> Multi-Cross-Plattform, dann auch noch von Fremdanbietern, geht meist in
> die Hose.

Kann ich so nicht bestätigen. Wir machen das für ein knappes Dutzend 
Architekturen (Linux, Windows, bare Metal, ARM926, Cortex-A (7, 9 und 
35), Cortex-M (0+, 3, 4, 33), ein alter 16 bitter, x86, x86-64). Alles 
handgeklöpelte Makefiles mit ein paar Scripts außenrum. Editiert wird 
das alles nach langen Jahren Eclipse mittlerweile unter VSCode. Diverses 
Windows-only Zeug lassen wir mit Wine unter Linux im Bauprozess auch 
noch laufen. Steckt aber auch viel Setup Zeit drin was für das Hobby 
natürlich eher hinderlich ist.

von Hans-Georg L. (h-g-l)


Lesenswert?

J. S. schrieb:
> Man kann CubeMX Projekte auch in VSC übernehmen, da gibt es mittlerweile
> eine Extension dafür.

CubeMX kann makefiles generieren und die funktionieren problemlos mit 
VSC.

von Peter (pittyj)


Lesenswert?

Nialz schrieb:
> Diejenige, die vom Hersteller zur Verfügung gestellt wird.

Das mache ich auch.
Für STM nehme ich CubeIDE, für NXP den MCUxpresso.

Wobei ich Compiler, Startup-Libraries, Linker-Files etc extrahiert habe, 
und dann alles nur noch über make aufrufe.
Dann muss ich nicht meinen Lieblings-Editor wechseln.

von Rudolph R. (rudolph)


Lesenswert?

Im Job bekomme ich die Build-Umgebung normalerweise zur Verfügung 
gestellt, auf Basis von makefiles.
Als Editor benutze ich VSCode.

Privat nutze ich vorzugsweise VSCode mit PlatformIO.
Und wenn PlatformIO nicht verwendbar ist, trotz support für fast 2000 
"boards", dann nehme ich die IDE vom Hersteller.
Die "platforms" "Atmel AVR" und "Atmel SAM" zum Beispiel unterstützen 
nur das "framework" "Arduino" bzw. "Arduino" und "Zephyr RTOS", also 
Bare-Metall ist nicht vorgesehen.
-> Microchip Studio

Die "platform" "ST STM32" unterstützt aktuell die "frameworks": 
"Arduino", "CMSIS", "libopencm3", "Mbed", "Standard Peripheral Library", 
"STM32Cube" und "Zephyr RTOS".
Aber auch damit konnte ich z.B. das Nucleo-C031C6 und das Nucleo-H503RB 
bisher nicht verwenden.

Und ich mache zwar nicht viel mit STM32, vor allem da es praktisch keine 
STM32 gibt die ich tatsächlich benutzen könnte, aber zumindest eine 
Platine habe ich mit Hilfe der STM32CubeIDE erfolgreich geplant.
Und die initiale Test-Software für die Platine war zum Teil mit 
STM32CubeIDE generiert.

Wobei mich Eclipse ganz allgemein eher ankotzt, was aber dran liegt, 
dass die meisten IDEs die Eclipse nutzen nicht so gut benutzbar sind wie 
STM32CubeIDE.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Max M. schrieb:

> Ich liebäugle immer mal wieder mit CubeMX bzw der CubeIDe aufgrund ihrer
> "Vorteile", aber am Ende finde ich den erzeugten Code so unfassbar
> unübersichtlich, von der Hall ganz zu schweigen, das ich meist schon
> nach wenigen Minuten abgeschreckt bin.

Man muss sich einfach auch mal in den generierten Code einlesen (auch in 
die tieferen Ebenen). OK, einige Design-Entscheidungen finde ich im 
Detail auch eher fragwürdig, aber im Großen und Ganzen ist das Zeug 
durchaus logisch.

Richtig fies finde ich einfach nur dieses völlig nutzlose Umbenennen von 
Registerbits, was ja teilweise sogar bis zu drei Mal durch die 
verschiedenen Schichten hindurch erfolgt. Wäre akzeptabel, wenn 
wenigstens der Namenskern immer erhalten bliebe. Das ist aber leider 
sehr oft nicht der Fall.

> Keil scheint auch ganz angenehm zu sein, ist aber für privat etwas teuer
> (Habe von mikroe die Lifetime Lizenzen)
> IAR sieht auch super aus und kommt mikroe wohl am nächsten?

Das hat doch mit den verwendeten Compilern nix zu schaffen! Das ist eine 
ganz andere Spielwiese. Idealerweise sollte es sogar überhaupt keine 
Rolle spielen, mit welchem Compiler der Kram am Ende übersetzt wird.

von Wilhelm M. (wimalopaan)


Lesenswert?

QtCreator + gcc + makefiles für ARM und AVR

von Dirk F. (dirkf)


Lesenswert?

MPLABX von Microchip.
Kostenlos und professionell.

Das Geld verdienen die mit dem Verkauf der Chips.

von Thomas T. (runout)


Lesenswert?

VS2019 mit VisualGDB, schlank und schnell, mit allen Vorteilen von 
VisualStudio.

Die Frage ist doch wohl eher Eclipse oder nicht.

Wie oben schon genannt: (bei STM)
Ein Projekt mit CubeMx generieren und dann
in die Lieblings-Toolchain importieren (z.B. VGDB)
ist schon ganz angenehm.

Runout

von Oliver S. (oliverso)


Lesenswert?

Thomas T. schrieb:
> VS2019 mit VisualGDB, schlank und schnell

Die Begriffe Visual Studio und schlank und schnell in einem Satz sieht 
man allerdings sehr, sehr selten.

Oliver

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

SEGGER Embedded Studio...weil ich recht günstig an die Lizenz komme ;-).
https://www.segger.com/products/development-tools/embedded-studio/

Ist aber auch für nicht kommerziell interessant wegen der SFL, 
https://www.segger.com/purchase/licensing/license-sfl/.

Ansonsten zum Debuggen kann ich Ozone empfehlen, 
https://www.segger.com/products/development-tools/ozone-j-link-debugger/.

Dann kann man mit dem Setup seiner Wahl sein Projekt verwalten und bauen 
und mit Ozone IDE unabhängig debuggen.

von Vanye R. (vanye_rijan)


Lesenswert?

> Einfach, weil ich den Eindruck habe, das alle Welt, also zumindest in D,
> auf STM setzt, ich selber auch, da ich dachte, das es da die meiste
> Vielfallt gibt und so

Das ist nur bei Bastlern so weil die immer voneinander abschreiben.

In Firmen wird der Controller nach ganz anderen Kriterien ausgewaehlt
und der Compiler und die Umgebung ebenfalls. Ich hab in den letzten
12Monaten an Controllern von ST, Silabs, TI, Renesas und NXP 
programmiert.

Privat nehme ich dann gerne was neues/cooles/anderes. (z.B Nordic oder 
RP2040) Damit es nicht langweilig wird.

Vanye

von Vanye R. (vanye_rijan)


Lesenswert?

> SEGGER Embedded Studio...weil ich recht günstig an die Lizenz komme ;-).

Hab ich mir vor einem Jahr mal angekuckt. War aber ziemlich kacke
weil man keine make/makefile Projekte erzeugen/nutzen konnte.
Kam mir ziemlich unprofessionell vor. Ist das mittlerweile besser
geworden oder hab ich da was uebersehen?

In der Firma sowieso nicht, aber auch privat will ich keine Projekte
haben die irgendwann von einer bestimmten Oberflaeche oder gar
einem Versionsstand abhaengig sind.
Einfach auschecken und einmal make muss immer funktionieren!

Vanye

von Crazy H. (crazy_h)


Lesenswert?

AVRCo-Pascal und Mega-/XMega-Controller

Falls jemand jetzt aufschnauft "teuer", ja das war einmal.

Rolf, der Entwickler des AVRCo-Compilers, ist vor kurzem verstorben :-( 
und der Compiler wurde mit der Version 6 (nicht die Version 5.x!) zur 
Freeware erklärt. Es ist kein Programmiergerät als Dongle mehr 
erforderlich und es gibt keine Codegrößenbeschränkung mehr.

Ich habe Rolf persönlich kennen und schätzen gelernt und bin immer noch 
sehr traurig.

https://www.e-lab.de/downloads/

: Bearbeitet durch User
von Max M. (max_mueller)


Lesenswert?

Oh, das tut mir leid. Ich war damals aber so verärgert wie mit den 
Anfänger im Forum umgegangen wurde, dass ich mir inzwischen mehrere 
Programme von Mikroe gekauft habe (Also Pascal und C für Arm und AVR, 
Lebenslange Lizenzen.

Aber dennoch ist es natürlich schade, dass zu lesen.
Gibt es denn jemanden der es weiter entwickelt?
Ich werde das mal im Freepascal Forum anregen oder ob es ins Freepascal 
integriert werden könnte etc.
Ich denke das wäre eine sehr schöne Möglichkeit, das System noch lange 
weiter zu nutzen, besser als es alleine als eigenständiges System weiter 
zu entwickeln, wo es kaum  Beachtung erfahren würde.
Und bevor es so lange brach liegt, das niemand mehr Lust hat es 
fortzusetzen um aktuelle AVR Nachfolger zu ergänzen z.B.

: Bearbeitet durch User
von Vax W. (Gast)


Lesenswert?

Max M. schrieb:

> Gibt es denn jemanden der es weiter entwickelt?
> Ich werde das mal im Freepascal Forum anregen oder ob es ins Freepascal
> integriert werden könnte etc.
> Ich denke das wäre eine sehr schöne Möglichkeit, das System noch lange
> weiter zu nutzen, besser als es alleine als eigenständiges System weiter
> zu entwickeln, wo es kaum  Beachtung erfahren würde.

Da die Quellen und das Build-System nicht veroeffentlicht sind, ist die 
Wahrscheinlichkeit sehr hoch, dass dieses System in den Orcus wandert.

Die Quellen unter einer OpenSource Lizenz zu Lebzeiten veroeffentlichen 
hatte geholfen. Jetzt geht es nicht mehr.

von Max M. (max_mueller)


Lesenswert?

Naja, noch ist ja nicht alles verloren, wenn Angehörige dem zustimmen 
würden.
Aber ansonsten hast du Recht. Dann ist es in Kürze Bedeutungslos, da 
keine nachfolgenden Controller mehr aktualisiert werden.
Aber wenn ich mir die Diskussion im Forum ansehe, bedeutet es wohl das 
Ende von AVRco:-(
Auch wenn ich es schon ewig nicht mehr nutze, ist es dennoch sehr 
schade.
Zum Glück bleibt Mikroe

: Bearbeitet durch User
von Crazy H. (crazy_h)


Lesenswert?

Ich kann mit der Version, wie sie jetzt ist, besser gesagt mit der 
letzten verdongelten, leben. Ich hab ca. 650 Megas/XMegas vorrätig und 
die sollten bis zur Kiste reichen.
Schade ist, daß aktuell Dinge eingebaut werden sollen, die keiner 
braucht, anstatt die letzten Schönheitsfehler zu beseitigen und 
Codeoptimierung zu betreiben.
Leider war und bin ich seit Turbo Pascal 7 da raus, ansonsten hätte ich 
vielleicht Rolfs Angebot, mir den Compiler zu überlassen, angenommen.

von Max M. (max_mueller)


Lesenswert?

Freepascal unterstützt ja auch AVR, von daher wäre es evtl eine 
Alternative da mal drüber zu schielen:-)
Freepascal ist sehr mächtig und deutlich weiter als AVRco
Hier eine Liste der Unterstützen AVRs
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/compiler/avr/cpuinfo.pas?ref_type=heads#L58

: Bearbeitet durch User
von Crazy H. (crazy_h)


Lesenswert?

Danke wußte ich nicht. Mit XMegas geht aber noch nichts? Gibt es eine 
Liste der Funktionen, die auf AVRs verfügbar sind?

von Max M. (max_mueller)


Lesenswert?

Frag da mal direkt im Freepascal Forum nach, entweder im Deutschen oder 
am besten im großen
https://forum.lazarus.freepascal.org/index.php
Die Community ist extrem freundlich und helfen sofort gerne mit 
ausführlichen Infos etc.
Der Umgangston ist nicht mit dem hier oder im AVRco Forum vergleichbar.

https://wiki.freepascal.org/AVR_Embedded_Tutorials/de

Und das beste, es wird auch ARM unterstützt, man muss sich also nicht 
mal umgewöhnen
https://wiki.freepascal.org/ARM_Embedded_Tutorials


Hier die benötigte FreePascal Deluxe Version
https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/v2.4.0a


Anbei das Manual
https://castle-engine.io/fpcupdeluxe

: Bearbeitet durch User
von Max M. (max_mueller)


Angehängte Dateien:

Lesenswert?

ICh sehe gerade, der Xmega wird wohl auch schon unterstützt

https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

: Bearbeitet durch User
Beitrag #7513203 wurde vom Autor gelöscht.
von Til S. (Firma: SEGGER) (til_s)


Angehängte Dateien:

Lesenswert?

Vanye R. schrieb:
> Hab ich mir vor einem Jahr mal angekuckt. War aber ziemlich kacke
> weil man keine make/makefile Projekte erzeugen/nutzen konnte.

Im Kontextmenü des Projektes findest du "Export Makefile" (siehe
Anhang).

von Vanye R. (vanye_rijan)


Lesenswert?

> Im Kontextmenü des Projektes findest du "Export Makefile" (siehe
> Anhang).

Ist das neu? Wie gesagt, so vor 1-2Jahren konnte ich nichts finden
wie ich da ein Makefile eines vorhanden Projektes importieren.

Vanye

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Ab GCC v13 wird Modula-2 unterstützt.  Hat das schon mal jemand 
ausprobiert?

> Support for the language Modula-2 has been added.  This includes support
> for the ISO/IEC 10514-1, PIM2, PIM3, PIM4 dialects together with a
> complete set of ISO/IEC 10514-1 and PIM libraries.

https://gcc.gnu.org/gcc-13/changes.html#modula2

von D. F. (Firma: EDF) (derdan)


Lesenswert?

Als IDE benutze ich JetBrain CLion. als Build System verwende ich CMake 
was ja von Clion auch direkt unterstütz wird. Als Compiler kommen damit 
alle Compiler in Frage welche sich mit make/Cmake ansteuern lassen:

ich nutze dabei

* GCC für Arm und für den PC
* Microsoft Visual Studio Compiler

Clion ist leider nicht kostenlos. Aber danach wurde auch nicht gefragt.

Von Jetbrain nutze ich zusätzlich noch
* PyCharm (Python)
* Rider (C#)
* IntelliJ IDEA (Java, Kotlin)

mit dem Vorteil das die IDE ziemlich identisch sind.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Crazy H. schrieb:

> und der Compiler wurde mit der Version 6 (nicht die Version 5.x!) zur
> Freeware erklärt.

Sources? Ohne Sources wäre die Benutzung quasi "Russisch-Roulette".

> Ich habe Rolf persönlich kennen und schätzen gelernt und bin immer noch
> sehr traurig.

Nun, es ist immer traurig, wenn jemand stirbt, den man mag.

Das ändert aber nichts am technischen Sachverhalt. Insbesondere nicht 
für alle, die den Autor halt nicht kannten und insbesondere auch nicht 
die Erben und deren zukünftiges Verhalten.

Allein die Tatsache, dass V5 nicht freigegeben wurde, läßt darauf 
schließen, dass den Erben die Intention des ursprünglichen Autors mehr 
oder weniger egal ist oder dass es auch schon dessen Intention war, den 
Gewinn zu maximieren.

Dagegen ist prinzipiell nichts einzuwenden. Es ist ja schließlich 
absolut legitim, mit der eigenen Arbeit Geld verdienen zu wollen. Es ist 
sogar legitim, dass auch die Erben das wollen (auch wenn sie selber 
nicht an der Sache gearbeitet haben).

Aber: jeder Benutzer der Sache sollte sich klarmachen, dass er nunmehr 
allein vom Wohlwollen der Erben abhängt. Die vermutlich nichtmal eine 
Ahnung davon haben, was sie da verwalten.

Ich (obwohl Pascal eher zugeneigt) würde mich jedenfalls nicht darauf 
einlassen.

von Andi B. (andi_b2)


Lesenswert?

Rowley Crossworks.

Zum Code schreiben aber meist mit externem Editor Slickedit. Da drinnen 
wird dann auch üblicherweise auch mit Tastendruck gebaut/build errors 
korrigiert (crossbuild.exe).

von Mi N. (msx)


Lesenswert?

Bislang war meine Empfehlung für kleine ARM-Projekte EWARM von IAR. Bis 
32 kB Code waren zeitlich unbegrenzt möglich und reichten für viele 
Spielereien aus. Der Debugger ist richtig gut!
Genialerweise wurde die Zeit zum Ausprobieren auf 14 Tage und 12 kB 
verkürzt: Das ist ein schlechter Scherz!

Das "Segger Embedded Studio for ARM" bietet sich als Alternative an.
Die aktuelle Version 7.32 bietet auch einen guten Einstieg für den 
RP2040, indem Basis-Projekte inkl. Bootloader zur Verfügung stehen.

Leider funktioniert der Import von IAR EWARM-Spielereien nicht so, wie 
es bei Vorgängerversionen war. Oder ich habe es noch nicht begriffen.
Nacharbeit ist auf jeden Fall notwendig.
Auch ein Beispielprogramm läßt sich zwar compilieren und via JLink-mini 
auf dem Pico-Board die LED blinken, der Versuch es mit Ozone zu starten, 
endet mit intransparenten Fehlermeldungen. Ohne Zeitzwang warte ich 
einfach neuere Versionen ab.

von Max M. (max_mueller)


Lesenswert?

Genau sowas war für mich ein Punkt gleich mehrere Mikroe Compiler (C und 
Pascal für Arm und AVR) zu kaufen, da es damals Lifetime Lizenzen gab 
und ich damit jetzt ausreichend CPUs bis ins Alter abgedeckt habe:-)
Nur neu AVR kann ich halt nicht mehr nutzen und bald sicher auch keine 
neuen ARm..aber so viele Arm die jetzt unterstützt werden, sind da 
sicher auch in 20-30 Jahren, noch welche von verfügbar:-)

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

> Leider funktioniert der Import von IAR EWARM-Spielereien nicht so, wie
> es bei Vorgängerversionen war. Oder ich habe es noch nicht begriffen.
> Nacharbeit ist auf jeden Fall notwendig.

Vielleicht hilft das hier:
https://wiki.segger.com/Port_Projects_from_IAR_Embedded_Workbench_to_Embedded_Studio

> Auch ein Beispielprogramm läßt sich zwar compilieren und via JLink-mini
> auf dem Pico-Board die LED blinken, der Versuch es mit Ozone zu starten,
> endet mit intransparenten Fehlermeldungen. Ohne Zeitzwang warte ich
> einfach neuere Versionen ab.

Nichtssagende Fehlermeldungen sollte es natürlich nicht geben. Was war 
es denn? Dann gebe ich das gerne weiter.

Ich habe das gerade mal mit dem RP2040 Board Support Package im embOS 
Cortex-M ES ausprobiert und konnte Ozone aus dem Embedded Studio heraus 
starten und die App dann laufen lassen.
https://www.segger.com/downloads/embos/embOS_CortexM_EmbeddedStudio_Trial

Was ich nicht probiert habe, ist ein neues ES Projekt zu generieren und 
damit Ozone zu starten. Kann ich aber im Zweifelsfall auch gerne nochmal 
testen. D.h. prinzipiell sollte Ozone aus ES heraus starten kein Problem 
sein. Alternativ kannst du natürlich auch direkt Ozone starten und ein 
neues Ozone Projekt anlegen.

https://wiki.segger.com/Ozone

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Ich habe mir das mit dem RP2040 doch gerade noch einmal mit ES V7.32 und 
Ozone 3.30c angeschaut. Das Problem ist der Bootloader im RP2040:
https://wiki.segger.com/Debug_on_a_Target_with_Bootloader#ROM_bootloader

Am besten so vorgehen:
1. ES Projekt für den RP2040 generieren und bauen.
2. Ozone aus ES heraus starten und das Ozone Projekt speichern. Ozone 
beenden.
3. Die Ozone Projektdatei wie im Wiki Artikel beschrieben bearbeiten.
4. Ozone über die Projektdatei öffnen und Debug Session starten. Jetzt 
sollte man ganz normal debuggen können.

Solange Ozone noch offen ist, kannst man einfach nach ES wechseln, neu 
compilieren, und zurück zu Ozone wechseln. Ozone erkennt dann, dass das 
ELF sich geändert hat und bietet an, es erneut zu laden.

von Mi N. (msx)


Lesenswert?

Til S. schrieb:
> Vielleicht hilft das hier:
> 
https://wiki.segger.com/Port_Projects_from_IAR_Embedded_Workbench_to_Embedded_Studio

Hallo Til,
der Artikel bezieht sich auf V5.32a und der Import läuft bei mir auch 
mit V5.70a. Bei V7.32 passiert jedoch nichts; schon die Meldung, daß 
Dateien importiert wurden, erscheint nicht.
Das scheint ein spezielles Problem bei RP2040-Projekten zu sein. Mit 
STM32-Projekten läuft der Import wie erwartet.

Mit dem verfügbaren RP2040-Beispielprogramm (main.c und bsp.c) blinkt 
die LED, wenn das Programm auf das Pico-Board gespielt wurde. Wird Ozone 
aufgerufen, gibt es einen Hardfault-Error. Der PC wackelt zwischen 0x30 
und 0x32. Das ist wohl im RP2040 internen Speicher. Mit dem doppelten 
Bootloader ist der RP2040 eh ekelig zu debuggen, aber das ist ein 
anderes Thema.

Bei anderen Versuchen bekam ich Fehlermeldungen auf rotem Feld, die den 
J-Link betreffen. Verbindungsfehler, fehlende Script-Datei (wie, wo, 
was?), obwohl der J-Link beim Laden und Ausführen der Programme 
einwandfrei lief.
Noch ein Punkt: wenn man morgens das ES neu startet, hängt es fest und 
zeigt in der obersten Zeile .... (Building) an und hängt voll in den 
Seilen. Man muß zunächst J-Link entfernen, bevor sich das Programm dafür 
bedankt, daß man es benutzt ;-)

Im Projekt-Manager gibt es die beschriebene Möglichkeit - Import von 
Dateien - irgendwie nicht. Bei RP2040-Projekten hängt ja im Hintergrund 
teilweise das Pico-SDK. Für mich ein "widerliches Zeug", wo man den Wald 
vor lauter Bäumen nicht sieht. Meine Idee war, nur die notwendigen 
Dateien aus dem Dateibaum ins Projektverzeichnis zu bekommen, daß man 
den unbenutzen Rest entfernen kann. Das Projekt würde dadurch kompakt. 
Man kennt das ja von CubeMX, wo optional nur die benutzen Dateien ins 
Projekt eingebunden werden: alles bleibt gut übersichtlich.
Es gäbe noch mehr zu berichten, es würde jedoch zu lang werden.

Noch habe ich meine IAR-Möglichkeit, dessen Ergebnisse ich abschließend 
als ES-Projekte zusammenkopieren kann, sofern ich diese öffentlich 
zugänglich machen möchte. Der Anwender soll dadurch in der Lage sein, 
ohne großen Aufwand Änderungen am Programm vorzunehmen. Mit den neuen 
Einschränkungen von IAR ist das nicht mehr möglich.
Gerade in Bezug auf den günstigen RP2040 ist ES auch eine gute 
Alternative zu der Pico-SDK IDE. Selber bin ich zu blöd, das auf Windows 
mit CMAKE und was auch immer zu installiern. PIOASM kann man mit ein 
wenig Kopfarbeit auch ersetzen.

Til S. schrieb:
> Ich habe mir das mit dem RP2040 doch gerade noch einmal mit ES V7.32 und
> Ozone 3.30c angeschaut. Das Problem ist der Bootloader im RP2040:

Das kam jetzt, während ich meine Antwort geschrieben habe. Ich sehe es 
mir an.
Noch etwas: Beim Programmlauf ohne Ozone werden zwar die PC-Adressen 
angezeigt, aber der Binär-Code ist "dummy".
Egal, alles braucht seine Zeit.

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Mi N. schrieb:
> Wird Ozone aufgerufen, gibt es einen Hardfault-Error.
Ja, genau, in dem Fall ist PC und SP wegen des Bootloaders nicht korrekt 
gesetzt und man landet im HardFault.

Mi N. schrieb:
> Bei anderen Versuchen bekam ich Fehlermeldungen auf rotem Feld, die den
> J-Link betreffen. Verbindungsfehler, fehlende Script-Datei (wie, wo,
> was?), obwohl der J-Link beim Laden und Ausführen der Programme
> einwandfrei lief.
> Noch ein Punkt: wenn man morgens das ES neu startet, hängt es fest und
> zeigt in der obersten Zeile .... (Building) an und hängt voll in den
> Seilen. Man muß zunächst J-Link entfernen, bevor sich das Programm dafür
> bedankt, daß man es benutzt ;-)
Das hatte ich so beides noch nicht. Passiert das auch mit der neuesten 
ES und J-Link Version?

Wenn du andere IAR Projekte importieren kannst, vermute ich das an dem 
RP2040 IAR Projekt irgendwas IAR spezifisch neu/anders ist, was dann ES 
vielleicht noch nicht kennt. Ist nur ein educated guess.
Am besten bei uns Forum melden, dann können evtl. die ES Kollegen 
weiterhelfen.

Mi N. schrieb:
> Noch etwas: Beim Programmlauf ohne Ozone werden zwar die PC-Adressen
> angezeigt, aber der Binär-Code ist "dummy".
Meinst du das Disassembly im ES?

Ich schicke dir ansonsten auch gleich mal meine Emailadresse per PN.

von Max M. (max_mueller)


Lesenswert?

Vielleicht macht ihr einen extra Thread dafür auf?

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Ja, sorry, deswegen der Vorschlag mit unserem Forum und ich habe ihm 
meine Emailadresse per PN geschickt. Wir klären dann auf dem Weg alles 
weitere :-).

von Joerg W. (joergwolfram)


Lesenswert?

IDE benutze ich eigentlich gar keine, als Editor meist den vom Midnight 
Commander. Als Compiler für die meisten Architekturen den GCC in einer 
gut abgehangenen 4.92er Version, für MCS51, HCS08 und STM8 den SDCC, für 
PICs bin ich mittlerweise vom SDCC auf den XC8 umgestiegen.
Dazu automatisch generierte Makefiles, Linkerscripts, Includes, 
Startup-Code sowie eine inzwischen teilweise über 2000 Funktionen 
enthaltene "Universal-Library", die gleichzeitig als HAL dient. Das 
Ganze ist dann noch auf meinen Universalprogrammer zugeschnitten, wo die 
Architektur es zulässt, kann man auch für Tests kleinere Programme im 
RAM starten. Ansonsten reicht ein "make prog".

Inzwischen nutze ich das auch beruflich, um "mal schnell" kleine 
Testprogramme zur Überprüfung der Baugruppenfunktionalität zu schreiben.

Jörg

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Joerg W. schrieb:
> über 2000 Funktionen
> enthaltene "Universal-Library",

Wo kann ich die Library bestaunen und re-use machen?!

von Joerg W. (joergwolfram)


Lesenswert?

> Wo kann ich die Library bestaunen und re-use machen?!

Über eine Veröffentlichung habe ich mir auch schon Gedanken gemacht, bin 
aber da noch zu keinem gescheiten Konzept gekommen. Von den Lizenzen 
sollte es eigentlich passen, wenn ich die Lib unter GPL/LGPL stelle, bei 
manchen Sourcefiles müssten aber die wohl die originalen Kommentare oben 
rein, da die anfangs beim automatischen Erstellen der Header-Datei 
gestört hatten bzw. angepasst werden mussten.

Zum Einem ist das Ganze inzwischen so automatisiert, dass man den zum 
Bauen notwendigen "Tool-Zoo" (mit fest eincodierten Pfaden ;-) auch mit 
veröffentlichen, anpassen und dokumentieren müsste.  Dann sind die 
Sources sämtlicher "Highlevel-Funktionen" von einem zentralen 
Verzeichnis per Symlinks in die Source-Bäume der einzelnen 
Controller-Familien gemappt, die ließen sich zur Not beim Packen 
auflösen. Aber damit wird das halt nur eine Art "Snapshot". Meine eigene 
Versionsverwaltung auf Subversion oder Git zu portieren habe ich im 
Laufe der Jahre nicht nur einmal versucht, habe es aber jedes mal wieder 
aufgegeben, weil es mir letztendlich keinen Nutzen gebracht hat.

Bis auf reine Berechnungsfunktionen, die sich sowieso alle irgendwo im 
Internet finden lassen sollten, baut alles andere auf 
controllerspezifischen Low-level Funktionen auf. Und die wiederum auf 
den controllerspezifischen Headerfiles, die ich zum Großteil selbst 
erstellt habe und oftmals auch nur die von mir genutzten 
Registerdefinitionen und jede Menge Konstanten enthalten.

Ein Kompromiss wäre, "Pakete" für verschiedene Controller 
bereitzustellen (mache ich intern auch schon), die dann schon alle 
notwendigen Dateien nebst einem Rumpf-Projekt enthalten. Und davon 
getrennt die ganzen Sourcen, aber ohne die Tools und weiteren Kontext. 
Denn schon allein die Dokumentation der ganzen Funktionen würde einen 
Riesenaufwand bedeuten.
Beispiele kann ich in der Zwischenzeit aber schon zur Verfügung stellen.

Jörg

PS: Durch einen Fehler in einem Generierungs-Script sind wohl globale 
Variablen mit als Funktionen gezählt worden, so dass sich die Anzahl der 
Funktionen auf ca. 1100-1300 reduziert. Bei den PICs noch weniger, da 
ich dort nur das Nötigste implementiert habe.

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.