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