Forum: Compiler & IDEs STM32: Umstieg von IAR auf den neuen CUBEIDE


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 H. R. (hacker_r)


Bewertung
0 lesenswert
nicht lesenswert
Hi
hat jemand mit der neuen CUBEIDE Version 1.5.1 Erfahrungen gemacht?
Lohnt es sich von IAR umzusteigen?

Soweit sehe ich dass wenn ich Variablen Werte im Live Expressions view 
während Runtime ändere, dass der Debuggere sich aufhängt.

Danke

von Sascha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
also ich würde beim IAR bleiben, da der gcc Compiler ja wohl nicht so 
optimal ist. Debuggen kanst du das Program ja mit verschiedenen 
Debuggern wenn du .elf File erstellst. Also ich wundere mich manchmal 
schon, was für ein Overhead aus dem gcc heraus kommt. Dafür kostet er 
nichts.

Gruß Sascha

von Blume (Gast)


Bewertung
0 lesenswert
nicht lesenswert
H. R. schrieb:
> Lohnt es sich von IAR umzusteigen?

A)
IAR hat ein wirklich guten Compiler. Produziert sehr selten in manchen 
Situationen fehlerhaften Code.

B)
Die IDE ist dagegen mehr als angestaubt.


wenn B) als wesentliches der Grund sein soll.


Beim Debuggen funktioniert auch der Segger JLink mit der Software Ozone 
von Segger. Den nehm ich auch dann immer wenn ich anspruchsvoller 
Debuggen will / muss.

Blume (kein AST)

Beitrag #6582191 wurde von einem Moderator gelöscht.
von Til S. (Firma: SEGGER) (til_s)


Bewertung
1 lesenswert
nicht lesenswert
H. R. schrieb:
> hat jemand mit der neuen CUBEIDE Version 1.5.1 Erfahrungen gemacht?
> Lohnt es sich von IAR umzusteigen?

Sowas ist pauschal immer schwer zu beantworten weil jeder andere 
Anforderungen hat. Wenn du aber das Geld bereits für die teure IAR 
Lizenz ausgegeben hast könnte man auch dabei bleiben. Alternativ gäbe es 
z.B. noch Keil MDK oder SEGGER Embedded Studio: 
https://www.segger.com/products/development-tools/embedded-studio/

Sascha schrieb:
> also ich würde beim IAR bleiben, da der gcc Compiler ja wohl nicht so
> optimal ist.

Die Unterschiede sind was die Compiler Optimierung angeht tatsächlich 
heutzutage gar nicht mehr so groß.

von sepp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> z.B. noch Keil MDK oder SEGGER Embedded Studio:

ja das ist doch nicht nur die Entwicklungsumgebung. Man legt sich ja 
auch mit dem Debugger I-Jet und I-Jet Trace fest. Der zweite kostet so 
um die 3000 EUR im vollen Ausbau. Bei segger müsste man dann schon 
wieder einen neuen kaufen, denke der kostet auch so in der Klasse. Bei 
Keil wird das auch so sein.
Leider steht bei Segger nicht, was für Debugger Hardware noch 
unterstützt wird, als ihre eigenen Teile.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
sepp schrieb:
> ja das ist doch nicht nur die Entwicklungsumgebung. Man legt sich ja
> auch mit dem Debugger I-Jet und I-Jet Trace fest.

Warum sollte man das tun?
i-jet sind die fürchterlich schlechten und langsamen debugger vom IAR 
selber.
Vergleich: 
https://www.segger.com/products/debug-probes/j-link/technology/flash-download/
Es waren mal relabelte j-links, aber die "neuen" kommen von einem 
anderen Hersteller. Wir hatten mal einen getestet und fast aus dem 
Fenster geworfen.

Zudem unterstützt der IAR auch j-link von segger.
Daher ist die Chance garnich so klein schon jlinks zu haben.

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


Bewertung
1 lesenswert
nicht lesenswert
sepp schrieb:
> Leider steht bei Segger nicht, was für Debugger Hardware noch
> unterstützt wird, als ihre eigenen Teile.

Kann sein dass es nicht so klar (oder gar nicht) auf der Embedded Studio 
Webseite erklärt wird weil wir lieber den J-Link verkaufen aber das geht 
schon: 
https://www.segger.com/news/segger-embedded-studio-adds-support-for-3rd-party-debug-probes-via-gdb-protocol/

sepp schrieb:
> Man legt sich ja
> auch mit dem Debugger I-Jet und I-Jet Trace fest. Der zweite kostet so
> um die 3000 EUR im vollen Ausbau.
Stolzer Preis, ein J-Link Plus kostet 498,- Euro und selbst ein J-Trace 
Pro Cortex-M "nur" 1390,- Euro (ok, der J-Trace Pro Cortex 1980,- Euro).
I-Jet und I-Jet Trace kann ich wahrscheinlich nur mit IAR EWARM 
benutzen.
J-Link wird von ein paar mehr IDEs unterstützt: 
https://www.segger.com/products/debug-probes/j-link/technology/ides/overview-of-supported-ides/ 
.

von Michael F. (Firma: IAR Systems) (michael_iar)


Bewertung
0 lesenswert
nicht lesenswert
Til S. schrieb:
> Die Unterschiede sind was die Compiler Optimierung angeht tatsächlich
> heutzutage gar nicht mehr so groß.

Hallo Til,

gibt es zu "tatsächlich heutzutage gar nicht mehr so groß" auch 
belastbare Zahlen? CoreMark-Scores für den STM32F417 eurer IDE könnten 
da ein Anfang sein, da es für diese MCU auf der Website von CoreMark 
bereits Werte für Keil MDK, GreenHills und IAR gibt und man dann nicht 
Äpfel mit Birnen vergleicht.


Til S. schrieb:
> Stolzer Preis, ein J-Link Plus kostet 498,- Euro und selbst ein J-Trace
> Pro Cortex-M "nur" 1390,- Euro (ok, der J-Trace Pro Cortex 1980,- Euro).
> I-Jet und I-Jet Trace kann ich wahrscheinlich nur mit IAR EWARM
> benutzen.

Der genannte I-jet Trace A/R/M für ~3k€ bietet ein bis zu 16-bit breites 
ETM Interface und bis zu 350MHz Trace-Clock:
https://www.iar.com/iar-embedded-workbench/add-ons-and-integrations/in-circuit-debugging-probes/#!?currentTab=specifications

Die Spezifikation auf eurer Website legt nahe, dass die Hardware des 
J-Trace PRO Cortex-M und des J-Trace PRO Cortex identisch ist und in 
beiden Fällen nur 4-bit ETM unterstützt. Falls das so korrekt ist, 
sollte dann nicht der I-jet Trace-CM die vergleichbare Probe von IAR 
sein? Liegt preislich zwischen euren beiden Probes und kann auch mit 
Cortex-R und Cortex-A umgehen, sofern die Performance des 
Trace-Interfaces ausreichend ist.

Gruß,
Michael

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


Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

Michael F. schrieb:
> gibt es zu "tatsächlich heutzutage gar nicht mehr so groß" auch
> belastbare Zahlen? CoreMark-Scores für den STM32F417 eurer IDE könnten
> da ein Anfang sein, da es für diese MCU auf der Website von CoreMark
> bereits Werte für Keil MDK, GreenHills und IAR gibt und man dann nicht
> Äpfel mit Birnen vergleicht.

Finde ich eine gute Idee, sollte man mal machen.
Vielleicht auch im Gegenzug die 100-Byte Blinky Challenge?
https://blog.segger.com/every-byte-counts-the-100-byte-blinky-challenge/

Davon abgesehn ist der IAR Compiler schon ziemlich gut und auch wenn 
manche Leute die IDE als altbacken bezeichnen arbeite ich immer noch 
lieber damit als mit vielen anderen IDEs. Aber das ist natürlich nur 
mein persönlicher Geschmack.

Michael F. schrieb:
> Der genannte I-jet Trace A/R/M für ~3k€ bietet ein bis zu 16-bit breites
> ETM Interface und bis zu 350MHz Trace-Clock:

Ich bin in dem Thema absolut nicht drin. Daher bitte mich nicht 
steinigen wenn ich da falsch liege. Aber gibt es überhaupt viele 
Device/Boards, die das unterstützen? Meines Wissens gibt es zumindest 
bei Cortex-M nur das 4-Bit Interface und auch bei Cortex A/R nur wenige 
Device/Boards bei denen man so viele Pins für Trace spendiert hat.
Ich habe hier noch etwas gefunden zu der 350MHz Trace-Clock:
https://blog.segger.com/current-state-of-the-trace-market/

Gruß,
Til

von m.n. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Til S. schrieb:
> Vielleicht auch im Gegenzug die 100-Byte Blinky Challenge?
> https://blog.segger.com/every-byte-counts-the-100-byte-blinky-challenge/

Mal ganz ehrlich?
Das finde ich albern!

Til S. schrieb:
> Davon abgesehn ist der IAR Compiler schon ziemlich gut und auch wenn
> manche Leute die IDE als altbacken bezeichnen arbeite ich immer noch
> lieber damit als mit vielen anderen IDEs.

Das finde ich interessant ;-)


@ Michael F.
Und auf eine Stellungnahme zu diesem Beitrag bin ich neugierig.
Beitrag "Re: Empfehlung IDE für ARM Cortex"

von Michael F. (Firma: IAR Systems) (michael_iar)


Bewertung
-2 lesenswert
nicht lesenswert
Til S. schrieb:
> Finde ich eine gute Idee, sollte man mal machen.
> Vielleicht auch im Gegenzug die 100-Byte Blinky Challenge?
> https://blog.segger.com/every-byte-counts-the-100-byte-blinky-challenge/

Ein nicht ganz unerheblicher Teil der Challenge besteht aus 
handgestricktem Assembler-Code und da ist es fraglich, in wie weit man 
damit die Qualität, bzw. Effizienz von C-Compilern vergleichen kann.

Ein reines C-Project wäre da m.M.n. sinnvoller. Eventuell als Library 
gebaut, um Einflüsse von Startup- und Exit-Routinen auszuschließen.


Til S. schrieb:
> Ich bin in dem Thema absolut nicht drin. Daher bitte mich nicht
> steinigen wenn ich da falsch liege. Aber gibt es überhaupt viele
> Device/Boards, die das unterstützen? Meines Wissens gibt es zumindest
> bei Cortex-M nur das 4-Bit Interface und auch bei Cortex A/R nur wenige
> Device/Boards bei denen man so viele Pins für Trace spendiert hat.
> Ich habe hier noch etwas gefunden zu der 350MHz Trace-Clock:
> https://blog.segger.com/current-state-of-the-trace-market/

Wer Äpfel mit Birnen vergleicht muss sich nicht wundern, wenn er am Ende 
mit eben diesen Äpfeln (oder Birnen) beworfen wird ;-)

In der Cortex-M Welt ist mir auch aktuell nur ein maximal 4-bit breites 
ETM Interface (meist über MIPI-20) bekannt, weshalb der I-jet Trace CM 
auch diese Verwendung als Empfehlung im Produktnamen trägt.

Für Cortex-A gibt es Boards, die den MICTOR-38 für das Debug-Interface 
nutzen, welcher beim I-jet Trace A/R/M vorhanden ist. z.B. das Intel 
FPGA Cyclone V-SoC Dev-Kit mit 8-bit ETM:
https://www.intel.de/content/www/de/de/programmable/products/boards_and_kits/dev-kits/altera/kit-cyclone-v-soc.html

TI hat dem TMS570LC43x HDK (Cortex-R) sogar 32-bit ETM (über MIPI-60) 
spendiert...


m.n. schrieb:
> @ Michael F.
> Und auf eine Stellungnahme zu diesem Beitrag bin ich neugierig.
> Beitrag "Re: Empfehlung IDE für ARM Cortex"

Eine "Stellungnahme" kling recht offiziell und die müsstest Du über 
unsere Presseabteilung anfragen ;-)

Im verlinkten Thread wird pauschal von v7 und v8 gesprochen und damit 
ist eine sinnvolle Aussage schwierig, da es schon einen Unterschied 
macht, welche Versionen aus dem 7er und 8er Major-Release man 
miteinander vergleicht.

Gruß,
Michael

von m.n. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Michael F. schrieb:
> Im verlinkten Thread wird pauschal von v7 und v8 gesprochen und damit
> ist eine sinnvolle Aussage schwierig, da es schon einen Unterschied
> macht, welche Versionen aus dem 7er und 8er Major-Release man
> miteinander vergleicht.

Komisch. Als ich das mit den verschobenen Breakpoints gelesen habe, 
wusste ich sofort, was gemeint ist, ohne eine Pressestelle zu befragen.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Die Aussagen find ich jetzt auch befremdlich.
Wieso sollte man da zur Pressestelle? Da sitzt doch keiner mit Ahnung 
vom Thema Breakpoints und Debugging.

In v7 ist das Problem eben nie aufgetreten.
Da weis ich doch jetzt nicht mehr welche v7 Subversionen wir da genau 
genutzt haben.
Also sag ich mal in sämtlichen v7 ist es nicht aufgetreten.
Die gleiche Projektdatei, die in v7 noch ordentlich lief, wurde mit dem 
Update auf IAR v8 auch geupdatet.
Also irgendeine mit Absicht geänderte Einstellung kanns auch ned sein.

Benutzte v8:
8.1
8.3
8.50.4
8.50.5
Es gibt sicher schon ne neuere Version, aber ab da haben wir erstmal 
aufgehört zu Updaten.
Bei jedem Update wurden zwar ein paar fuckups der GUI gefixt, aber es 
kamen auch wieder weitere hinzu.
Vor allem ist son Update immer mit Aufwand verbunden in der 
Softwarebateilung.
Jeder muss erstmal auf nen halbwegs fertigen Stand kommen, damit alle 
gleichzeitig Updaten können.
Denn die Projektfiles sind nicht rückwärtskompatibel.
Auch nicht von 8.50.5 nach 8.50.4.

Im Anhang mal das Problem anhand einer kleinen Funktion.
Mal gucken ob er sich nochmal meldet ;)

von Michael F. (Firma: IAR Systems) (michael_iar)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Im Anhang mal das Problem anhand einer kleinen Funktion.
> Mal gucken ob er sich nochmal meldet ;)

Ja, er meldet sich wieder und vielen Dank für die ausführliche 
Beschreibung :-)

Das sonderbare Verhalten der Breakpoints in IDE Version v8 habe ich 
gestern selbst nachgestellt und an den Support weitergegeben.

Da ich meist nur Code-Fragmente zur Analyse erhalte und dann auf Basis 
der List-Files schauen darf, was da eventuell falsch läuft ist mir das 
Verhalten des Editors / Debuggers bisher noch nicht aufgefallen.

Gruß,
Michael

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.