Hallo, ich bin gerade mal wieder über IAR erstaunt. Erstaunt darüber wie man es heute noch schafft mit einer 20-Jahre-rückständigen Software Geld zu verdienen. Es kommt Update um Update, man muss Ihnen Geld ohne Ende hinterherwerfen, aber von User Experience kann keine Rede sein. Können oder wollen die IAR Entwickler kein benutzerfreunliches Programmieren schaffen? Was ist das Problem mit der Implementierung einer Autovervollständigung-Funktion?!? Auch wenn es schön wäre, muss sie ja noch nichtmal intelligent wie in Visual Studio sein.
Das frage ich mich auch schon lange. Wie/Wo biste denn übern IAR gestolpert? v7 war zwar altbachen, aber funktionierte recht zuverlässig. v8 ist absolut unbrauchbar geworden. Wenn du einen Breakpoint hast und fügst darüber eine weitere Codezeile ein, dann wandert der nicht intelligent mit (in v7 ging das noch), sondern bleibt stur stehen. Wenn du also was weiter oben im Code Zeilen hinzufügst sind unten dann paar Breakpoints im Eimer. Sehr schön ist auch der Epillepsieanfall der IDE wenn eine Debugsession beginnt. Die Codesuche braucht auf 8 CPU Kernen 4-5min bei 1500 Dateien. grep(win) auf 1 Kern 4 Sekunden! Jedenfalls setz ich in der Abteilung grade alle Hebel in Bewegung, dass wir von dem Schrott wegkommen. Ein paar neueingestellte KOllegen waren ach direkt am rumfluchen was das für Crapware ist. Die Frage ist was die Alternativen sind.
Mw E. schrieb: > Wie/Wo biste denn übern IAR gestolpert? Ich bin an der Uni und habe eine Veranstaltung zur Einführung in die Mikrocontroller-Programmierung übernommen. Diese Veranstaltung hatte ich vor über 10 Jahren auch belegt und eben dort auch IAR EW kennengelernt. Mein Vorgänger und damaliger Dozent (63j, gutmütig, träge, Parkinson) war und ist sehr angetan von IAR. Und auch den Compiler an sich finde ich ganz gut. Aber die IDE... Nnch dem ersten Öffnen der Trial-Version in v8.5 bin ich erstmal vor die Tür, um zu schauen ob ich noch in 2020 bin oder zurück in den 90ern. Es hat sich einfach nichts geändert, außer dass die Ladezeiten eher länger als kürzer wurden. Aktuell bin ich wirklich der Überlegung diesen IAR quatsch zu entsorgen und auf Visual Code umzusteigen. Ein Freund von Eclipse bin ich nicht.
Und ich dachte immer daß Eclipse nervt... Mw E. schrieb: > Die Frage ist was die Alternativen sind. Ich krieg leider kein Geld dafür (ein JLink Edu würde mir ja aber schon reichen), dennoch: Schaut euch mal Embedded Studio an. Mir fehlen da zwar einige Dinge, die ich aus Netbeans 8 gewöhnt bin (und die auch nicht in der Original IDE, sondern als Plug-In mal von anderen Benutzern programmiert wurden), aber ansonsten funktioniert sie recht zuverlässig. Ich habe zwar nur sporadisch und gelegentlich damit gearbeitet und auch das ist schon zwei Jahre oder so her, aber an sich hat ES gut funktioniert, ist nicht zu überladen oder träge. Mw E. schrieb: > Sehr schön ist auch der Epillepsieanfall der IDE wenn eine Debugsession > beginnt. > Die Codesuche braucht auf 8 CPU Kernen 4-5min bei 1500 Dateien. > grep(win) auf 1 Kern 4 Sekunden! Autsch...das klingt als stammt der Code noch aus Zeiten, bevor man sich um Digne wie MVC Gedanken gemacht hat. Ich persönlich finde, solche Firmen haben ihre Daseinsberechtigung am Markt verloren. Es ist vollkommen in Ordnung einer Firma Geld für gutes Werkzeug zu geben. Man sollte aber keinen Firmen Geld geben deren Produkt soviel schlechter als Open Source Projekte ist. Dann sollte man das Geld lieber denen spenden.
Ja die Ladezeiten wurden länger. Richtig witzig ist es wenn du den IAR laufen hast und ihm "unterm *Arsch" per GIT die Codedateien und die Projektdatei erneuerst. Das bemerkt der von sich aus (der positive Aspekt). Dann kommt ein Fenster für die Subprojekte im Hauptprojekt. Ob man das grade angezeige Subprojekt neuladen will (yes) oder ein "yes for all", wenn du das klickst kommt die Meldung trotzdem für JEDES Subprojekt. Welcher Sepp hat das denn bitte vergeigt? Dominic schrieb: > Aktuell bin ich wirklich der Überlegung diesen IAR quatsch zu entsorgen > und auf Visual Code umzusteigen. Ein Freund von Eclipse bin ich nicht. Visual Code ist ja die Seuche am anderen Ende der Messlatte. Das ist eine Desktopanwendung in Javascript geschrieben... Eclipse ist zwar auch nicht meine lieblings IDE, aber allemal besser als IAR was die Zuverlässigkeit angeht. @Wühlhase: Die v7 hatte das nicht. In v8 wurde die IDE überarbeitet ein paar Icons sind anders und man kann die Fenster besser miteinander andocken. Das ist ja erstmal nicht schlecht, aber dabei wurde vieles anderes verhunzt. Unter der Haube hat sich also wohl einiges getan. Den Jlink edu kann ich dir empfehlen, den nutze ich privat Zuhause. Das Embedded Studio wäre sogar in der engeren Auswahl, da wir eh Jlink Plus nutzen, da ist die Lizenz schon mit bei. Jedenfalls hatte ich das mal Daheim aufm rechner mit dem Edu probiert und bin nicht so ganz warm damit geworden, aber nen Anlauf leg ich mal noch hin. Am Ende soll eigentlich alles Makefilebasiert werden. Der Hickhack dem IAR ordentliches Batchbuild beizubringen war auch der Horror pur. Noch ein IAR Schmankerl: Nach einem Compilevorgang geht die struct/class Autovervollständigung nicht. (Ja der IAR hat sowas in eingeschränkt!) Wenn du eine structvariable schreibst, dann schlägt er dir die member vor. (kekse->) Wenn du das nach einem Compilevorgang machst, dann kommt unten eine Nachricht, dass das erst wieder geht nachdem er den Code rescannt hat. Das dauert solange wie die Volltestsuche, also 4-5min. Das Feature klappt also erst nach 5min nachm Compile wieder, saugeil!
IAR 8 ist nicht nur unglaublich langsam, altbacken, verbuggt und wenig funktional, wir haben auch regelmäßig Probleme damit das IAR bei inkrementellen Builds kaputte Binaries erzeugt und diese damit nutzlos sind. Im Prinzip muss bei jeder Codeänderung ein Rebuild durchgeführt werden um sicher zu stellen, das da ein (hoffentlich) korrektes Binary erzeugt. Gerade bei größeren Projekten frisst das richtig Zeit und Geld. Natürlich, IAR kann auch manches garnicht so schlecht. Das debugging klappt recht gut. Allerdings ist IAR, wenn überhaupt, auch nur unwesentlich besser als andere Lösungen. Es ist für mich absolut unbegreiflich, wie sich so eine schlechte Software am Markt behaupten kann. Es ist wirklich die bei weitem schlechteste Software, mit der ich je in meinem Leben gearbeitet habe und ich kann wirklich nur jedem abraten diese Software einzusetzen.
Dominic schrieb: > mit einer 20-Jahre-rückständigen Software Auch in Eclipse 2020 ist der Support für Make Projekte immer noch im Status "experimentell"
Hallo, Wir haben uns in der Firma entschlossen, IAR über Board zu werfen, als es darum ging eine weitere Lizenz zu kaufen. Der Compiler/Debugger sind an für sich durchaus gut, aber der Rest machte einfach keinen Spaß mehr. Lange Ladezeiten (I7, 16GB und SSD) und das Umschalten von Editor zu Debugger dauert ewig. Das ganze System scheint zeitweise eingefroren zu sein. Auch habe ich hier kontinuierlich Abstürze, wenn ich ein Projekt schließe. Für das Geld, das man hinlegt (Lizenz ca 3500 Euro, jährliche Updates 1000 Euro) ist das, was man bekommt eine Unverschämtheit. Ich habe letztes jahr testweise ein Projekt mit Segger Embedded Studio umgesetzt und das läuft sehr performant und es macht Spaß, damit zu arbeiten. Vom Aufbau ist die IDE für den Laien auch nicht von IAR zu unterscheiden. Was noch etwas stört ist, daß es (noch?) nicht ganz so einfach ist, für einen beliebigen Prozessor ein Rumpfprogramm zu erzeugen. Ich mußte hier wenigstens bei den von mir gewählten Prozessoren Hand anlegen und die Interrupttabelle vervollständigen. SES ist übrigens für nichtkommerzielle Anwendungen ohne Einschränkungen kostenlos. Der Compiler basiert auf Clang/LLVM mit eigenen Optimierungen und einem eigenen Linker, der für embedded Anwendungen optimiert ist. Ich verstehe eigentlich bis heute nicht, warum diese IDE nicht von jedem Hobbyisten genutzt wird.
ich benutze den IAR für ARM schon sehr lange und bin damit sehr zufrieden, aber den Debugger von IAR habe ich noch nie benutzt. Ich benutze den JTagJet-ARM von Signum Systems mit eigener Debug-Oberfläche (Chameleon Debugger ). Leider wurde die Firma auch gekauft und auch noch von IAR. Ist aber kein Problem, der nimmt jeden ARM derzeit noch, muss man halt einstellen. Dazu habe ich noch den JTAGjet-Trace-4M, für besondere Fälle. Ich wollte nur sagen, man muss den Debugger von IAR nicht nutzen, man kann bei IAR auch nur den Compiler kaufen, also ohne Debugger. Es gibt ja noch einige Anbieter, bei denen ich mich derzeit umschaue: PLS Programmierbare Logik & Systeme GmbH Lauterbach GmbH Green Hills Software Viele Grüsse, Steffen
:
Bearbeitet durch User
Angehängte Dateien:
franz schrieb: > wir haben auch regelmäßig Probleme damit das IAR bei > inkrementellen Builds kaputte Binaries erzeugt und diese damit nutzlos > sind. Wie groß ist denn das Projekt? Bei uns hat sich der IAR Compiler bei größen structs (mbedTLS) in struct Offsets vertan! Beim Zugriff per Pointer und Dereferenizierung (->) war ein Offset anders als bei Direktzugriff (.). Dann wird natürlich nur Müll gelesen. Manchmal werden übrigens Änderungen in Headern nicht erkannt, aber nur manchmal! Da darfste bei jeder Änderung im Header auch aus Sicherheitsgründen ein Rebuild ausführen. S. W. schrieb: > Auch habe ich hier kontinuierlich Abstürze, wenn ich ein Projekt > schließe. Sehr schön ist wenn man auf Kompilieren klickt und sich das Ding nach "Updating Buildtree" mal wieder verhakt und weiter nix macht. IAR Über das Windowfenster X schließen geht nicht, dann kommt nen Fehlerfenster, dass er doch noch Kompiliere. Dann musste den Prozess im Taskmanager abwürgen und das passiert nicht selten. S. W. schrieb: > Der Compiler basiert auf Clang/LLVM mit eigenen Optimierungen > und einem eigenen Linker, der für embedded Anwendungen optimiert ist. Das ist jetzt ein kleiner Dämpfer beim Segger Embedded Studio. In der Firma kennt man sich dann eher von vorherigen Arbeitgebern und Hobbys beim gcc aus. Kann man den da reinbauen? Ist denn der eigene Linker so machtvoll wie der vom gcc oder clang? Der Linker vom IAR ist ja auch eine Zumutung, der kann im Vergleich zum gcc linker fast garnichts.
Bei SES oder auch dem original Crossworks kann man die Toolchain wählen: GCC oder LLVM https://www.segger.com/products/development-tools/embedded-studio/technology/compiler/
Mw E. schrieb: > Das ist jetzt ein kleiner Dämpfer beim Segger Embedded Studio. > In der Firma kennt man sich dann eher von vorherigen Arbeitgebern und > Hobbys beim gcc aus. > Kann man den da reinbauen? > Ist denn der eigene Linker so machtvoll wie der vom gcc oder clang? > Der Linker vom IAR ist ja auch eine Zumutung, der kann im Vergleich zum > gcc linker fast garnichts. Die Toolchain ist auswählbar. Man muss aber dazu sagen, CLANG/LLVM ja weitestgehend kompatibel sein sollen, was die Übergabeparameter angeht. Die Aussage von Segger zum eigenen Linker ist, daß dieser entwickelt wurde, um insbesondere den Anforderungen im Embeddedbereich gerecht zu werden. Der Linker erzeugt wohl deswegen kürzeren Code und ist in der Ausführungszeit auch schneller. Die Syntax erscheint mir erst einmal stimmig zu sein. Ich habe insbesondere den Eindruck, daß man dort recht offen ist, was die Implementierung neuer Features angeht.
Mw E. schrieb: > Das ist jetzt ein kleiner Dämpfer beim Segger Embedded Studio. > In der Firma kennt man sich dann eher von vorherigen Arbeitgebern und > Hobbys beim gcc aus. > Kann man den da reinbauen? Ja, du kannst auch weiterhin den GCC benutzen. Entweder mit dem GCC Linker oder auch dem SEGGER Linker. Mw E. schrieb: > Ist denn der eigene Linker so machtvoll wie der vom gcc oder clang? Sogar machtvoller ;-). Ansonsten hätten wir uns die Arbeit nicht gemacht :-). S. W. schrieb: > Ich habe insbesondere den Eindruck, daß man dort recht > offen ist, was die Implementierung neuer Features angeht. Ja klar, wir sind für alle Verbesserungsvorschläge offen. Letztlich bin ich auch Embedded Studio Kunde und wenn mir was nicht gefällt nerve ich die Kollegen damit. Nur so kann Software besser werden. Bei Fragen/Problemen/Verbesserungsvorschlägen immer gerne bei uns melden. Zum Beispiel bei uns im Forum: https://forum.segger.com/
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.