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
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
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.
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ß.
> 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.
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.
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/ .
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
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
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"
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
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.
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 ;)
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.