Hallo, ein Kunde von mir möchte gerne Software mit dem IAR entwickelt haben. Ich bin mit der Kombination von GCC, GDB, CMake + Editor sehr zufrieden. Ich kenne den IAR überhaupt nicht. Welche Argumente sprechen eurer Meinung nach für oder gegen IAR? Vom ersten Blick auf deren Webseite fallen mir als Argumente gegen IAR ein: - Läuft scheinbar nur unter Windows - Kann kein C++11 mfg Torsten
Ein Grund dafuer : der Kunde will das so. Es genuegt ja, dass eine Software nur unter Windows laeuft. Nein ? Technische Entwicklungen macht man ausschliesslich auf einem PC. Weshalb muss man das neuste Feature auch implementiert haben ? Limitiert dich das in irgendeiner Weise ? Fuer Controller sind die Objekte eh nichts. Ein Grund dagegen waere allenfalls der stolze Preis. aber wenn der Kunde das so will ... und dir einen solchen Compiler hinstellt...
:
Bearbeitet durch User
Oder D. schrieb: > Ein Grund dafuer : der Kunde will das so. Nun, meine Aufgabe als Software-Entwickler ist es ja auch durchaus, Kunden, die nicht aus der Software-Entwicklung kommen, zu beraten. > Technische Entwicklungen macht man ausschliesslich auf einem PC. Selbst wenn ich Deine Ausschließlichkeit so nicht teilen würde, verstehe ich den Zusammenhang mit PC und Windows nicht. > Weshalb muss man das neuste Feature auch implementiert haben ? Limitiert > dich das in irgendeiner Weise ? Fuer Controller sind die Objekte eh > nichts. Das must Du schon mir überlassen. Gerade C++11 enthält sehr viele Neuerungen, die sich im Microcontroller-Umfeld hervorragend verwenden lassen. > > Ein Grund dagegen waere allenfalls der stolze Preis. aber wenn der Kunde > das so will ... und dir einen solchen Compiler hinstellt... Ich kenne den Preis nicht, kann mir aber vorstellen, dass das eher kein Argument sein wird. Schönen Dank für Deine Rückmeldung. mfg Torsten
Wenn ich Kunde wäre und alles mit IAR entwickelt hätte, und dann Projekte vergebe, will ich nachher nicht ein Sammelsurium an verschiedenen IDEs und Compilern pflegen müssen. Das allein reicht als Begründung. Windows ist in der Industrie Standard. Ist halt so. IAR hat sehr gute Compiler. Für AVR zB gibt es nichts besseres, denn IAR hat die AVR-Architektur mitentwickelt, so dass sie auf ihren Compiler optimal passt. IAR unterstützt MISRA. Du kennst MISRA nicht? Fehler, großer Fehler. Dabei geht es nicht darum, alle Features des Compilers und der Sprache auszunutzen, sondern gezielt Sprachelemente NICHT zu nutzen, die erfahrungsgemäß leicht zu Bugs führen. C++11 ist daher auch kein Thema. fchk
> Torsten R. schrieb: >> Welche Argumente sprechen eurer >> Meinung nach für oder gegen IAR? Cyblord -. schrieb im Beitrag #4363600: > Natürlich ist die IDE vom IAR nicht der Weisheit letzter Schluss (lange > nicht), aber man muss da nicht so ein Geschiss drum machen. Hallo Cyblord, tut mir leid, wenn Dich meine Nachricht gerade mit Verstopfung auf der Toilette erreicht hat. Wie ich ja oben selbst geschrieben habe, kenne ich den IAR nicht. Mir sind aber zwei Dinge aufgefallen, die mich bei der Arbeit stören würden. Du must ja meine Art zu arbeiten nicht mögen, aber muss man deswegen hier so austicken? Du tust ja fast so, als hätte ich Dich persönlich beleidigt. mfg Torsten
Die IAR-Umgebung selbst ist ein Krampf. Es gibt keine Hervorhebungen im Code (durch Markieren einer Variablen alle anderen Vorkommen auch hervorgehoben) und kaum Codevervollständigungen. Ich muss das auch aufgrund eines Kundenwunsches machen. Im Nachhinein hätte ich 100% mehr Geld verlangen sollen. Ein guter Punkt ist aber, dass es für Eclipse ein IAR Plugin gibt. Die Vorzüge von Eclipse lassen sich so mit dem IAR nutzen.
Torsten R. schrieb: > ein Kunde von mir möchte gerne Software mit dem IAR entwickelt haben. Grund genug. > Ich bin mit der Kombination von GCC, GDB, CMake + Editor sehr zufrieden. > Ich kenne den IAR überhaupt nicht. Welche Argumente sprechen eurer > Meinung nach für oder gegen IAR? Wir liefern Sourcecode. Unsere Kunden möchten diesen weiterentwickeln. Viele unserer Kunden haben Probleme gcc, gdb, cmake Umgebung aufzusetzen. Und IAR (oder eine andere Umgebung) läuft bereits. Außerdem macht es normalerweise für die Firmen keinen Sinn verschiedene Umgebungen einzusetzen. > Vom ersten Blick auf deren Webseite fallen mir als Argumente gegen IAR > ein: > - Läuft scheinbar nur unter Windows Möglich. Viele unserer Kunden nutzen Windows. > - Kann kein C++11 Erlauben die Codingstandards der jeweiligen Firma dessen Verwendung? Ich muss allerdings zugeben, dass wir die Entwicklung nicht auf der jeweiligen Umgebung durchführen. Jedoch erstellen wir entsprechende Projekte für den Kunden und testen die Software hiermit.
Frank K. schrieb: > Windows ist in der Industrie Standard. Ist halt so. Selbsterfüllende Prophezeiung oder auch Teufelskreis. Wenn nie jemand aus dem alten Muster ausgebrochen wäre, dann würde wir immernoch mit der Keule hinter nem Mammut herlaufen.... Frank K. schrieb: > Für AVR zB gibt es nichts besseres, denn IAR > hat die AVR-Architektur mitentwickelt, so dass sie auf ihren Compiler > optimal passt. Selbst Atmel presöhnlich setzt inzwischen auf einen (etwas verpatchten) GCC als ihren "Standart-AVR-Compiler". So überlegen kann IAR also nicht sein. Solange natürlich tausende Euros für Produkte rausgeworfen werden weil es "standard" ist ohne zu kucken ob die features das rechtfertigen, solange werden solche Produkte natürlich auch bestehen bleiben. M$ schafft es ja (zum Glück) zur Zeit massiv die Kundschaft zu vergraulen mit ihrer Spioniererei und den Zwangsupdates. Vlt. kommt so endlich mal etwas bewegung in den Lanschaft...
Max D. schrieb: > Frank K. schrieb: >> Windows ist in der Industrie Standard. Ist halt so. > > Selbsterfüllende Prophezeiung oder auch Teufelskreis. Der Kunde hat abgestimmt. Finde dich damit ab. Ist das so schwer zu verstehen? > Wenn nie jemand aus dem alten Muster ausgebrochen wäre, dann würde wir > immernoch mit der Keule hinter nem Mammut herlaufen.... Was damals Keule und Mammut war, ist heute die Kommandozeile unter Linux und die unsägliche Benutzerunfreundlichkeit. Fortschritt sehe ich da keinen. Aber das spielt auch keine Rolle. Wenn ein Kunde das will, warum bitte müsst ihr dann immer missionieren? Genau DAS ist das Problem mit euch. > Selbst Atmel presöhnlich setzt inzwischen auf einen (etwas verpatchten) > GCC als ihren "Standart-AVR-Compiler". So überlegen kann IAR also nicht > sein. Der GCC ist ebenfalls sehr gut für AVRs inzwischen. Trotzdem stimmt die Aussage mit IAR. > M$ Alles klar.
:
Bearbeitet durch User
Felix A. schrieb: > Die IAR-Umgebung selbst ist ein Krampf. Es gibt keine Hervorhebungen im > Code (durch Markieren einer Variablen alle anderen Vorkommen auch > hervorgehoben) und kaum Codevervollständigungen. Ich muss das auch > aufgrund eines Kundenwunsches machen. Im Nachhinein hätte ich 100% mehr > Geld verlangen sollen. Du beziehts Dich hier nur auf den Editor. Und da merkt es niemand, welchen du im Endeffekt verwendet hast. Bis auf die Zeilenendenproblematik. Die man aber ganz gut in den Griff bekommt.
Hallo Steffen, Steffen R. schrieb: > Und IAR (oder eine andere Umgebung) läuft bereits. Außerdem macht es > normalerweise für die Firmen keinen Sinn verschiedene Umgebungen > einzusetzen. ja, ich würde jetzt einem Kunden auch nicht aufschwatzen wollen, die Umgebung für bestehende Projekte zu ändern. GCC und CMake zu installieren ist aber auch kein Hexenwerk. Der gesamte Build ist dann mit CMake (oder von mir aus auch make) beschrieben und die Software kann sofort gebaut werden. Ich kennes es noch von Visual Studio, das man da von Version zu Version regelmäßig die Projekt-Files anpassen musste. Gibt es solche Probleme mit IAR nicht? >> - Kann kein C++11 > > Erlauben die Codingstandards der jeweiligen Firma dessen Verwendung? Es gibt Kunden, die die Vorteile von C++11/14 durchaus zu schätzen wissen. Ich habe einen Kunden da wird ein Großteil des Systemverhaltens deklarativ beschrieben und so zur Compiler-Zeit z.B. CAN-Bus-Telegram-Layouts bestimmt. > Ich muss allerdings zugeben, dass wir die Entwicklung nicht auf der > jeweiligen Umgebung durchführen. Jedoch erstellen wir entsprechende > Projekte für den Kunden und testen die Software hiermit. Das wäre natürlich auch ein Weg, man müsste sich dann halt auf die Einschränkungen des IAR-Compilers beschränken. mfg Torsten
Ein paar weitere Infos habe ich noch: -Kosten für eine Lizenz sollen bei etwa 4k€ liegen -Compiler erstellt ANGEBLICH den "optimalsten" Code, keine Ahnung ob das stimmt -Auch hier kommt es (habe das mit Version 6.x und der aktuellen 7.4? erlebt) zu leichten Unterschieden. Es wird zwar etwas angemerkt, aber ich weiß nicht, ob/wo es hakt. -Mit STM32CubeMX erstellter Code führt auch zu einer Meldung, die ich nicht zuordnen kann. Wohl weil noch nicht die aktuelleste IAR-Version unterstützt wird. Gilt aber nur bei der Nutzung von STM-Controllern. Sonst wird CubeMX nicht benutzt. Wenn du mit der Umgebung Probleme hast, sollte der Support helfen. Das tut er aber nur, wenn du die Software gekauft hast.
Steffen R. schrieb: >> - Läuft scheinbar nur unter Windows > > Möglich. Viele unserer Kunden nutzen Windows. Der Kunde selbst nutzt OS/X und lässt den IAR dem entsprechend in einer VM laufen. Eine Lösung, die sowohl unter OS/X als auch Windows läuft wäre eher ein Gewinn. Ich kann ja auch verstehen, dass man IDEs nicht für mehrere Plattformen Supporten möchte, aber dem Compiler sollte es doch (fast) egal sein, auf welchem Betriebssystem er läuft.
Torsten R. schrieb: > Steffen R. schrieb: >> Und IAR (oder eine andere Umgebung) läuft bereits. Außerdem macht es >> normalerweise für die Firmen keinen Sinn verschiedene Umgebungen >> einzusetzen. > > ja, ich würde jetzt einem Kunden auch nicht aufschwatzen wollen, die > Umgebung für bestehende Projekte zu ändern. GCC und CMake zu > installieren ist aber auch kein Hexenwerk. Der gesamte Build ist dann > mit CMake (oder von mir aus auch make) beschrieben und die Software kann > sofort gebaut werden. Unter Windows? Und es hört ja nicht mit der Installation auf. Wie gesagt, unsere Kunden wollen die Projekte weiterpflegen. Und warum beziehst du dich nur auf bestehende Projekte? Ist der Kunde gewillt für zukünftige Projekte komplett umzusteigen. Ansonsten hat er mehrere Umgebungen und dies ist aus meiner Sicht schlecht. > Ich kennes es noch von Visual Studio, das man da von Version zu Version > regelmäßig die Projekt-Files anpassen musste. Gibt es solche Probleme > mit IAR nicht? Klar gibt es die Probleme auch hier wie überall. Du must hierbei bedenken, dass die Kunden genauso eingearbeitet sind in die IAR Umgebung wie du in die Make Umgebung. Es fällt ihnen daher nicht so schwer wie dir ein neues IAR Projekt aufzusetzen. Torsten R. schrieb: >>> - Kann kein C++11 >> Erlauben die Codingstandards der jeweiligen Firma dessen Verwendung? > Es gibt Kunden, die die Vorteile von C++11/14 durchaus zu schätzen > wissen. Nur weil ich frage heißt dies nicht, dass ich es verneine. Da die angesprochene Firma jedoch auf IAR setzt, besteht zumindest die Möglichkeit, dass sie es bewußt oder unbewußt nicht einsetzen. Torsten R. schrieb: >> Ich muss allerdings zugeben, dass wir die Entwicklung nicht auf der >> jeweiligen Umgebung durchführen. Jedoch erstellen wir entsprechende >> Projekte für den Kunden und testen die Software hiermit. > > Das wäre natürlich auch ein Weg, man müsste sich dann halt auf die > Einschränkungen des IAR-Compilers beschränken. Genau. Deshalb auch bereits die entwicklungsbegleitenden Tests auf dem IAR System.
Hallo Felix, Felix A. schrieb: > Ein paar weitere Infos habe ich noch: > > -Kosten für eine Lizenz sollen bei etwa 4k€ liegen ups, ich hätte schlimmsten Falls mit der Hälfte gerechnet. Ich habe da vorhin mal eine Anfrage gestellt, mal gucken, was die Antworten. > -Compiler erstellt ANGEBLICH den "optimalsten" Code, keine Ahnung ob das > stimmt Ok, das kann natürlich sein, dass die da mehr Energie rein gesteckt haben. > Wenn du mit der Umgebung Probleme hast, sollte der Support helfen. Das > tut er aber nur, wenn du die Software gekauft hast. Ja, das ist auch immer wieder ein Argument, was das dann im Endeffekt taugt, erfährt man leider erst im Nachhinein. Bei 4TEUR wäre meine Erwartungshaltung schon recht groß. schönen Dank und mfg, Torsten
Hallo Steffen, Steffen R. schrieb: > Unter Windows? Ja, selbst unter Windows sollte sich GCC/CMake relativ einfach installieren lassen (< 2h; >> Klick auf setup.exe). Je nach Projektgröße reicht ein einfaches make natürlich auch aus. > Und warum beziehst du dich nur auf bestehende Projekte? Ist der Kunde > gewillt für zukünftige Projekte komplett umzusteigen. Ansonsten hat er > mehrere Umgebungen und dies ist aus meiner Sicht schlecht. Der Kunde selbst hat überhaupt keine SW-Entwicklung. Ich denke der wird vor allem die Gewissheit haben wollen, dass später andere Entwickler mit der aufgesetzten Toolchain (und dem Code) weiter arbeiten können. mfg Torsten
Torsten R. schrieb: > Steffen R. schrieb: >>> - Läuft scheinbar nur unter Windows >> >> Möglich. Viele unserer Kunden nutzen Windows. > > Der Kunde selbst nutzt OS/X und lässt den IAR dem entsprechend in einer > VM laufen. Eine Lösung, die sowohl unter OS/X als auch Windows läuft > wäre eher ein Gewinn. Ich kann ja auch verstehen, dass man IDEs nicht > für mehrere Plattformen Supporten möchte, aber dem Compiler sollte es > doch (fast) egal sein, auf welchem Betriebssystem er läuft. Ich kenne zwar mehr OS/X Kunden, die Windows in der VM laufen haben als Linux. Das ist aber keineswegs representativ. Unverständnis erntest Du von mir für deine Beschränkung auf den Compiler. Unsere Kunden entscheiden sich gerade wegen der IDE für die jeweilige Umgebung. Der Compiler darunter ist ihnen eigentlich egal. (Mein Eindruck) Und sie bleiben lange bei der gewählten Umgebung und sind wenig wechselbereit. Und die Möglichkeit direkten Support zu bekommen spielt auch einen Rolle. Allerdings habe ich weniger mit Entwicklern zu tun, welche zeitkritische Routinen schreiben müssen. Die werden hier natürlich eine andere Meinung dazu haben.
Torsten R. schrieb: > Vom ersten Blick auf deren Webseite fallen mir als Argumente gegen IAR > ein: Der Kunde möchte, dass seine Software mit Hilfe von IAR entwickelt wird. Wenn Ihr nicht bereit seid, dies zu tun, seid Ihr aus dem Rennen. Als Kunde würde ich mir an der Stelle einfach einen anderen Entwicklungspartner suchen. Vor einigen Jahren kam ein extrem windowszentrierter Geschäftspartner bei mir an, um sich von uns beraten zu lassen, weil sein Kunde für das neu zu entwickelnde System zwingend Linux verwenden wollte. Es gab auch sehr handfeste Gründe, die dafür sprachen. Wir berieten also unseren Geschäftsparner und machten einige Konzeptvorschläge. Etwas später kam der Geschäftspartner an: "Wir haben für den Kunden einen Demonstrator mit Windows aufgebaut und ihm damit gezeigt, dass man kein Linux verwenden muss!" Ich: "Und habt Ihr den Auftrag?" Er: "Nein, natürlich nicht, aber wir haben ihm gezeigt, dass Linux scheiße ist." Super...
Steffen R. schrieb: > Unverständnis erntest Du von mir für deine Beschränkung auf den > Compiler. Unsere Kunden entscheiden sich gerade wegen der IDE für die > jeweilige Umgebung. Der Compiler darunter ist ihnen eigentlich egal. > (Mein Eindruck) ich finde CMake vor allem auch deswegen ganz gut, weil es für verschiedene IDEs project files erzeugen kann (IAR ist leider nicht dabei). So kann jeder seine IDE verwenden, mit der er am schnellsten ist und am Ende wird das final binary auf dem build server mit make erzeugt. Spätestens wenn man mal continuous integration einführen möchte, ist es sehr hilfreich, wenn man die binaries von der Kommandozeile aus erzeugen kann. Kann man einen Build in IAR von der Kommandozeile aus starten? > Allerdings habe ich weniger mit Entwicklern zu tun, welche zeitkritische > Routinen schreiben müssen. Die werden hier natürlich eine andere Meinung > dazu haben. Ach, ich habe den Eindruck, das der Unterschied eher in der Ausbildung liegt. SW-Entwickler, die aus der Informatik kommen sind meiner Meinung nach eher gewillt / gewohnt, sich in die Feinheiten der entscheidenen Tools (Compiler-Schalter; Linker-Scripts) einzuarbeiten. Kollegen, die aus der E-Technik kommen haben meistens einen anderen Fokus. Das ist völlig wertfrei gemeint! mfg Torsten
Torsten R. schrieb: >> Wenn du mit der Umgebung Probleme hast, sollte der Support helfen. Das >> tut er aber nur, wenn du die Software gekauft hast. > > Ja, das ist auch immer wieder ein Argument, was das dann im Endeffekt > taugt, erfährt man leider erst im Nachhinein. Ich bin auch immer wieder verwundert, wie wenig Werbung ich von Firmen bekomme, die mir Support bei Problemen mit der gdb Umgebung geben können (gegen Geld). Ich glaube, die Sorge bei Problemen alleine dazustehen, ist die größte Angst der Firmen, die sich gegen gcc/gdb entscheiden.
> Welche Argumente sprechen eurer Meinung nach für oder gegen IAR? Der Kunde möchte das so. Wenn du damit nicht leben willst, kannst du den Auftrag auch ablehnen. Die Vertragsfreiheit lässt das durchaus zu. > > -Kosten für eine Lizenz sollen bei etwa 4k€ liegen > ups, ich hätte schlimmsten Falls mit der Hälfte gerechnet. Kommentar überflüssig.
Hallo Andreas, Andreas S. schrieb: > Der Kunde möchte, dass seine Software mit Hilfe von IAR entwickelt wird. Tut mir leid, mein eingehendes Statement war etwas ungenau: Der Kunde und ich möchten uns zusammen setzen und gucken, ob wir zusammen arbeiten möchten/können. Z.Z. setzt der Kunde IAR ein. Das kann für mich ein Grund sein, nicht mit dem Kunden zusammen zu arbeiten. Und ich würde den Kunden ggf. gerne davon überzeugen, bei zukünftigen Projekten auf IAR zu verzichten, es sei den ich höre Argumente, die ganz klar für IAR sprechen (einige wurden ja schon genannt). Ich war bei der Formulierung so ungenau, weil ich ja vor allem nach Argumenten pro/kontra IAR suche und irgend wie einen einleitenden Satz brauchte, um darzulegen, warum ich nach diesen Informationen suche. Entschuldigt bitte die Verwirrung. mfg Torsten
Torsten R. schrieb: > ich finde CMake vor allem auch deswegen ganz gut, weil es für > verschiedene IDEs project files erzeugen kann Du brauchst mich nicht agitieren. Ich versuche nur die Sichtweise unserer Kunden darzustellen. Torsten R. schrieb: > Kann man einen Build in IAR von der Kommandozeile aus starten? Lt. Doku ja (EWARM). Torsten R. schrieb: > Ach, ich habe den Eindruck, das der Unterschied eher in der Ausbildung > liegt. Unsere Studenten lernen keine C Programmierung/Embedded Programmierung an der Uni. Da gehts mehr um Java und Co.
Steffen R. schrieb: > > Ich bin auch immer wieder verwundert, wie wenig Werbung ich von Firmen > bekomme, die mir Support bei Problemen mit der gdb Umgebung geben können > (gegen Geld). Ich glaube, die Sorge bei Problemen alleine dazustehen, > ist die größte Angst der Firmen, die sich gegen gcc/gdb entscheiden. Vielleicht wäre ein vernünftiger Debugger in dem Umfeld auch eine gute Produkt-Idee ;-)
Steffen R. schrieb: > Du brauchst mich nicht agitieren. Ich versuche nur die Sichtweise > unserer Kunden darzustellen. das habe ich auch nicht anders verstanden.
Hallo Bürovorsteher, Bürovorsteher schrieb: >> Welche Argumente sprechen eurer Meinung nach für oder gegen IAR? > > Der Kunde möchte das so. Wenn du damit nicht leben willst, kannst du den > Auftrag auch ablehnen. Die Vertragsfreiheit lässt das durchaus zu. danke für den Hinweis. Meiner Meinung nach kommt man mit dieser Einstellung im Berufsleben aber nicht sehr weit. Du magst das anders sehen; das lässt Deine Meinungsfreiheit ja auch zu. > Kommentar überflüssig. Ach ja... mfg Torsten
Moin. Bei uns wird seit Urzeiten der IAR verwendet, praktisch ausschließlich für Prozessoren von NEC/Renesas. K4, K0, V850.. Aktuell sind die Geräte vornehmlich auf RX63ern unterwegs. Die Lizenzkosten sind in der Tat nicht ganz ohne, allerdings kommen wir bei ~15 Entwicklern mit 8 Floating-Lizenzen momentan prima aus. An wirkliche Probleme bei einem Versionsupdate kann ich mich nicht erinnern. Die Projektdateien wurden von der neuen Workbench beim ersten Aufruf geupdatet und gut. Ein oder zweimal hatten wir das "Glück", den IAR wohl mit als erste auf neu eingeführte Prozessoren loslassen zu dürfen. Oder wir waren die ersten, die einen dabei entdeckten Fehler gemeldet haben. Eine neue Version von IAR ließ dann aber auch nicht lange auf sich warten. (IIRC innerhalb von ein, zwei Tagen.). Build über Kommandozeile - ja. Wird nebenan von Kollegen derzeit (erstmals g) hochgezogen, da für deren Gerät nebst hex-File auch weitere Ausgaben benötigt. Binary für Updates, Verschlüsseln desselben über nachgezogenes Skrip. Nein, Build-Rechner existiert hier nicht. Habe ich zwar regelmäßig versucht, einzuführen - aber inzwischen resigniert :-/ Persönliche Meinung(en): - Ich komme mit dem IAR nun seit 10 Jahren gut klar. Die Anbindung der jeweiligen Debugger (NEC Minicube/Renesas E1 und E20) klappt prima, ohnehin empfinde ich die Debug-Möglichkeiten als sehr angenehm. - Die IDE selbst... vor einigen Jahren hätte ich mehr geschimpft. Das parallel andere Editoren (NP++/UltraEdit) genutzt werden (bzw. an anderen Standorten auch Eclipse vorhanden ist) kommt nicht von ungefähr. - In der aktuellen Version wechsle ich hingegen nur noch selten auf NP++. Ob's mehr an den erweiterten Funktionen des integrierten Editors liegt oder an meiner Gewöhnung, weiß ich nicht. (Und wenn doch, dank Keybinding und passendem Aufruf steht nach einem Tastendruck der Cursor dann im NP++ immerhin an der gleichen Stelle...) Nein, ein "nur noch mit'm IAR" gibt's von mir nicht. Dafür habe ich auch zu wenig Erfahrungen mit anderen Umgebungen. Vielleicht kannst du mit den Hinweisen ja dennoch etwas anfangen. Grüße, Markus
Hallo Markus, Markus T. schrieb: > Vielleicht kannst du mit > den Hinweisen ja dennoch etwas anfangen. auf jeden Fall, schönen Dank dafür! mfg Torsten
Torsten R. schrieb: > Und ich würde den > Kunden ggf. gerne davon überzeugen, bei zukünftigen Projekten auf IAR zu > verzichten, es sei den ich höre Argumente, die ganz klar für IAR > sprechen (einige wurden ja schon genannt). Und: > Ich kenne den IAR überhaupt nicht. Du bist also viel zu unflexibel, Dich auf die Kundenwünsche einzustellen. Du lehnst den Einsatz von Produkten ab, die Du überhaupt nicht kennst. > Ich war bei der Formulierung so ungenau, weil ich ja vor allem nach > Argumenten pro/kontra IAR suche Nein, Du willst nur Argumente kontra IAR hören, die in Dein Weltbild passen. Würdest Du ein Abweichen von Deiner bisherigen festgefahrenen Toolkette tolerieren, hättest Du komplett andere Fragen gestellt.
Andreas S. schrieb: > Du bist also viel zu unflexibel, Dich auf die Kundenwünsche > einzustellen. > Du lehnst den Einsatz von Produkten ab, die Du überhaupt > nicht kennst. > Nein, Du willst nur Argumente kontra IAR hören, die in Dein Weltbild > passen. Ich bin ja immer wieder erstaunt, über die Menge der hellseherischen Menschenkenntnisse in diesem Forum :-) > Würdest Du ein Abweichen von Deiner bisherigen festgefahrenen Toolkette > tolerieren, hättest Du komplett andere Fragen gestellt. Na, dann schieß mal los... Ich bin ganz Ohr!
Torsten R. schrieb: > Bürovorsteher schrieb: >> Der Kunde möchte das so. Wenn du damit nicht leben willst, kannst du den >> Auftrag auch ablehnen. Die Vertragsfreiheit lässt das durchaus zu. > > danke für den Hinweis. Meiner Meinung nach kommt man mit dieser > Einstellung im Berufsleben aber nicht sehr weit. Du magst das anders > sehen; das lässt Deine Meinungsfreiheit ja auch zu. Genau diese Einstellung vertrittst Du aber an anderer Stelle: > Z.Z. setzt der Kunde IAR ein. Das kann für mich ein > Grund sein, nicht mit dem Kunden zusammen zu arbeiten. Und wie schon zuvor geschrieben, stellst Du die falschen Fragen. Wärst Du wirklich daran interessiert, den Kunden unvoreingenommen zu beraten, würdest Du Dich auf die wesentlichen Punkte wie z.B. Zertifizierungsanforderungen, Homogenisierung von Entwicklungsumgebungen, Kompatibilität zu Drittsoftware (Bibliotheken, Tools, usw.) konzentrieren. Das willst Du aber nicht.
Andreas S. schrieb: > Torsten R. schrieb: >> Und ich würde den >> Kunden ggf. gerne davon überzeugen, bei zukünftigen Projekten auf IAR zu >> verzichten, es sei den ich höre Argumente, die ganz klar für IAR >> sprechen (einige wurden ja schon genannt). > > Und: >> Ich kenne den IAR überhaupt nicht. > > Du bist also viel zu unflexibel, Dich auf die Kundenwünsche > einzustellen. Du lehnst den Einsatz von Produkten ab, die Du überhaupt > nicht kennst. > Das hat erstmal nichts unflexibles an sich. Es ist eine Einschätzung, dass es viel mehr Zeit brauchen könnte als nötig. Außerdem macht die Nutzung des IAR auch abhängig. Wenn die Firma aus welchen Gründen auch immer mal aufgibt, gibt es den IAR nicht mehr. Sources sind nicht öffentlich und damit dann quasi tot. Das ist der Vorteil von OpenSource. Wird größtenteils von Usern für User entwickelt und gepflegt. Jeder kann die Tools nutzen (da kostenlos und im Einsatz unbegrenzt dank fehlender Kommerzwünsche). Und verschwinden werden die nicht. >> Ich war bei der Formulierung so ungenau, weil ich ja vor allem nach >> Argumenten pro/kontra IAR suche > > Nein, Du willst nur Argumente kontra IAR hören, die in Dein Weltbild > passen. > > Würdest Du ein Abweichen von Deiner bisherigen festgefahrenen Toolkette > tolerieren, hättest Du komplett andere Fragen gestellt. Es mag was anderes sein, wenn der kleinstmögliche Controller gewählt werden muss, wodurch der kleinste Code gebraucht wird. Aber in der heutigen Zeit ist das nur im Bereich Massenmarkt der Fall; wenn überhaupt, Flash kostet fast nix. Es hängt vom Projekt ab. Das kennt hier bis auf Torsten R. keiner. Diese aus dem Äther geholten Vorwürfe nerven.
Steffen R. schrieb: > Torsten R. schrieb: >> Kann man einen Build in IAR von der Kommandozeile aus starten? > > Lt. Doku ja (EWARM). Auch praktisch. Ist hier so in Verwendung (EWARM) IarBuild.exe <Projekt>.ewp "<Konfiguration>" Gemeinsam mit Hudson, SVN und GCC für automatische Unit-Tests (x86 Host)
Lieber Andreas, Andreas S. schrieb: > Wärst > Du wirklich daran interessiert, den Kunden unvoreingenommen zu beraten, > würdest Du Dich auf die wesentlichen Punkte wie z.B. ... > konzentrieren. woher nimmst Du bloß diese Weisheit? Möchtest Du ernsthaft, dass ich den Kunden einlade, diese Themen hier im Forum öffentlich mit Dir zusammen zu diskutieren, damit dokumentiert ist, dass ich nicht nur einen Aspekt beleuchte? Könntest Du evtl. mal von deiner "Alles Vollidioten ausser Papi"-Weltanschauung etwas Abstand nehmen und einfach mal annehmen, dass es auch noch andere Menschen gibt, die einfach mal zu einem bestimmten Aspekt Informationen suchen und diese Informationen später im Gesamtkontext durchaus einordnen können? > Das willst Du aber nicht. Du wirst das wissen müssen.. mfg Torsten
Hallo Maxx, Maxx schrieb: > Ist hier so in Verwendung (EWARM) > IarBuild.exe <Projekt>.ewp "<Konfiguration>" danke für die Info! mfg Torsten
Torsten R. schrieb: > Welche Argumente sprechen eurer Meinung nach für oder gegen IAR? Es ist grundsätzlich kein großes Problem, Code so zu schreiben, dass er sich mit beiden Compilern benutzen lässt (OK, auf C++11 musst du dann natürlich verzichten). Dass bisschen Compilerabhängigkeit bekommt man relativ gut in einem Headerfile abstrahiert. Allerdings sind die Kommandozeilen, die man für den IAR zusammenbauen muss, ein ziemlicher Krampf, und die notwendigen Kommandozeilenargumente können sich auch schon mal von einer Version zur nächsten ändern. Damit wird die Pflege einer entsprechenden Makefile-Hierarchie schon recht lästig. Eventuell dann doch eine duale Infrastruktur pflegen, CMake für GCC (kann $KUNDE ja dann auch direkt auf OSX laufen lassen) und das eben genannte IAR-Projektzeugs für diesen. IAR ist zweifellos ein guter Compiler, aber er ist auch zweifellos verdammt teuer. Ob du dir nun MISRA unbedingt antun musst, hängt von der Umgebung ab, die der Kunde so braucht. Manche der MISRA-Regeln sind nicht so arg unsinnig, andere wiederum sind mittlerweile eher von zweifelhaftem Wert.
Torsten R. schrieb: > Ich kenne den IAR überhaupt nicht. Was spricht dagegen die kostenfreie Kickstart Version zu installieren und zu testen. Die Laufzeit ist unbegrenzt hat nur 32K Codelimit. Das ist aber für die zahlreichen Beipielprojekte ausreichend. Positiv wären noch das Versionsmanagement und das State Machine Tool.
Der Kunde könnte, falls er nicht schon eine hat, eine IAR Lizenz kaufen und dir für die Entwicklung überlassen. Wenn Du fertig bist, dann gibst Du ihm die Lizenz zurück. Kosten für Dich - Null. Dennoch solltest Du etwas höhere Entwicklungskosten kalkulieren, da, wie schon oben geschrieben, die Editor Unterstützung nicht so ausgereift ist wie beispielsweise bei Eclipse.
:
Bearbeitet durch User
Hallo Lothar, Lothar schrieb: > Was spricht dagegen die kostenfreie Kickstart Version zu installieren > und zu testen. Die Laufzeit ist unbegrenzt hat nur 32K Codelimit. vor allem der Faktor Zeit. Wenn mir hier jemand in kürzester Zeit sagen kann dass der Compiler sehr guten Code erzeugt, dann muss ich da nicht erst eigene Tests für machen :-) Aber danke schön für den Hinweis auf die Test-Version. > Positiv wären noch das Versionsmanagement und das State Machine Tool. Kannst Du noch was zum "Versionsmanagement" sagen? mfg Torsten
Gründe für gcc/make: Für das Übersetzen der Firmware wird keine komplette IDE benötigt. Updates der IDE können sich nicht auf das Übersetzungs-Erbenis auswirken. Beim Erstellen einer neuen Release-Version wird der verwendete Compiler mit gesichert, und damit ist auch Jahre später eine Neu-Übersetzung unter exakt gleichen Umständen möglich. Wahrscheinlich ist ein ähnlichen Vorgehen auch mit dem IAR-Compiler möglich, aber dann entfällt eben der IDE-Komfort, den man sich eigendlich einkaufen möchte. Gruß, Stefan
Torsten R. schrieb: > Wenn mir hier jemand in kürzester Zeit sagen kann dass der Compiler sehr > guten Code erzeugt Ja, das macht er. Aber so grundlegend besser als der GCC, dass du nun vielleicht nur noch einen halb so großen Controller am Ende brauchst, ist er auch wieder nicht. Ich habe mal eine zeitlang Zugang zu einem IAR für AVR gehabt, die Optimierungsstrategien zwischen IAR und GCC sind an vielen Stellen so verdammt ähnlich, dass man schon fast denken könnte, einer schreibt manchmal vom anderen ab. ;-) Falls du irgendwo irgendwie mal Inline Assembler brauchst: da ist der GCC zwar kryptisch, aber unschlagbar flexibel. In dieser Richtung bietet der IAR nichts, was man auch nur ansatzweise vergleichen könnte. (Falls sich jetzt einer auf den Schlips getreten fühlt: ja, na klar hat auch der IAR das Feature als solches. Aber die Übergabe von Parametern aus der C-Umgebung an den Inline Assembler ist, abseits von der natürlich immer vorhandenen Möglichkeit des Zugriffs auf globale Variablen, praktisch nicht steuerbar. War sie zumindest, als ich ihn das letzte Mal in den Fingern hatte.)
Jörg W. schrieb: > Falls du irgendwo irgendwie mal Inline Assembler brauchst: da ist der > GCC zwar kryptisch, aber unschlagbar flexibel. In dieser Richtung > bietet der IAR nichts, was man auch nur ansatzweise vergleichen könnte. > (Falls sich jetzt einer auf den Schlips getreten fühlt: ja, na klar > hat auch der IAR das Feature als solches. Aber die Übergabe von > Parametern aus der C-Umgebung an den Inline Assembler ist, abseits > von der natürlich immer vorhandenen Möglichkeit des Zugriffs auf > globale Variablen, praktisch nicht steuerbar. War sie zumindest, als > ich ihn das letzte Mal in den Fingern hatte.) Mein Erlebnis mit dem IAR-Compiler, zugegeben schon 20 Jahre her, damals für den NEC 780034: Einige Routinen mussten in Assembler geschrieben werden. Zur Parameterübergabe waren vom IAR-Compiler (damals?) feste CPU-Register festgelegt. Irgendwann kam dann ein Compiler-Update. Nach dem nächsten Build ging nichts mehr. Nach langem Suchen kam dann heraus, daß die neue Compiler-Version andere Register zur Parameterübergabe verwendete. Natürlich nicht einstellbar. Irgendwo war das sogar dokumentiert, aber leider nicht in einem changes.log oder ähnlichen File. Das hat SICHER nichts mit dem aktuellen IAR-Compiler zu tun, prägt einen aber doch irgendwie. Gruß, Stefan
Torsten R. schrieb: > Wenn mir hier jemand in kürzester Zeit sagen > kann dass der Compiler sehr guten Code erzeugt, dann muss ich da nicht > erst eigene Tests für machen :-) Du hast bisher nicht deine Architektur erwähnt. Allgemein läßt sich das sicher nicht beantworten.
Steffen R. schrieb: > Allgemein läßt sich das sicher nicht beantworten. Eine exzellente Codegenerierung ist so ziemlich das Einzige, was ich dem IAR unabhängig von der Architektur eigentlich immer zutrauen würde. ;-)
Bei uns ist auch die Entscheidung für IAR für die LPC gefallen. Gründe waren MISRA, Support, Debugger und einfache Installation. Der Programmierer soll sich aufs Programmieren konzentrieren können und die Ergebnisse müssen stabil und reproduzierbar sein.
Steffen R. schrieb: > Du hast bisher nicht deine Architektur erwähnt. Allgemein läßt sich das > sicher nicht beantworten. Ich habe mit dem Kunden bis jetzt noch nicht gearbeitet. Die meisten Applikationen basieren wohl auf STM32 zusätzlich gibt es die Notwendigkeit hier und da mal Desktop GUIs zu bauen. Einige der Applikationen könnten Sicherheitskritisch sein. Ich treffe mich heute zum ersten mal mit Ihm und wollte im Vorweg eigentlich einfach nur mal kurz ein paar Informationen zum IAR ;-)
Hallo Peter, Peter D. schrieb: > ... und > die Ergebnisse müssen stabil und reproduzierbar sein. Bei der Reproduzierbarkeit finde ich IDEs im Allgemeinen meist nicht so vorteilhaft. Kann man bei IAR Projekten relativ einfach im Versionsmanagement erkennen, wenn jemand an einem Compiler-Schalter etwas geändert hat? Ist Dokumentiert, in welchen Datei die Bild-Regeln abgebildet sind, und in welchen Dateien bloß die Fenstergröße beim letzten Öffnen abgelegt sind? mfg Torsten
Felix A. schrieb: > Das hat erstmal nichts unflexibles an sich. Es ist eine Einschätzung, > dass es viel mehr Zeit brauchen könnte als nötig. Außerdem macht die > Nutzung des IAR auch abhängig. Wenn die Firma aus welchen Gründen auch > immer mal aufgibt, gibt es den IAR nicht mehr. Sources sind nicht > öffentlich und damit dann quasi tot. Keine Ahnung wie IAR das handhabt, ansonsten ist es üblich die Quelltexte und alle nötigen Tools inkl. Dokumention bei einem Notar oder darauf spezialisierten Software Escrow-Dienstleistern zu hinterlegen. > Das ist der Vorteil von OpenSource. Wird größtenteils von Usern für User > entwickelt und gepflegt. User ist nicht gleich User... Z.B. der Linux-Kernel: "The number of paid developers is on the rise, as companies aggressively recruit top Linux talent. More than 80 percent of kernel development is done by developers who are being paid for their work. Volunteer developers tend not to stay that way for long." http://www.linuxfoundation.org/news-media/announcements/2015/02/linux-foundation-releases-linux-development-report > Jeder kann die Tools nutzen (da kostenlos und > im Einsatz unbegrenzt dank fehlender Kommerzwünsche). Abhängig von der Lizenz... Ebenso kann die Frage was ein abgeleitetes Werk ist und die daraus resultierenden Offenlegungspflichten zum Problem werden bzw. werden OSS-Lizenzen von einigen Konzernen gerade deshalb eingesetzt, um sich Konkurrenz vom Leib halten. > Und verschwinden werden die nicht. Verschwinden nicht, aber u.U. unbrauchbar z.B. im Sinne von zu hohen Kosten, wenn der/die Hauptentwickler nicht mehr da sind oder der Konzern, der die Entwickler bezahlt hat, meint, dass die Kosten dafür zu hoch sind... Edit: Beitrag "Software Zertifizierung" wo es u.a. um GCC vs. kommerzielle Compiler für zertifizierte Software geht
:
Bearbeitet durch User
Arc N. schrieb: > Keine Ahnung wie IAR das handhabt, ansonsten ist es üblich die > Quelltexte und alle nötigen Tools inkl. Dokumention bei einem Notar oder > darauf spezialisierten Software Escrow-Dienstleistern zu hinterlegen. Davon hatte ich bisher nichts gehört. Danke für den Hinweis. >> Das ist der Vorteil von OpenSource. Wird größtenteils von Usern für User >> entwickelt und gepflegt. > > User ist nicht gleich User... Z.B. der Linux-Kernel: > "The number of paid developers is on the rise, as companies aggressively > recruit top Linux talent. More than 80 percent of kernel development is > done by developers who are being paid for their work. Volunteer > developers tend not to stay that way for long." > http://www.linuxfoundation.org/news-media/announcements/2015/02/linux-foundation-releases-linux-development-report Ja, das stimmt. Ich denke aber trotzdem, dass der überwiegende Teil Software von nicht bezahlten Entwicklern entsteht. Neben dem Linux-Kernel gibt es schließlich noch einen Riesenberg andere Software. > Edit: Beitrag "Software Zertifizierung" wo es u.a. um GCC vs. > kommerzielle Compiler für zertifizierte Software geht Den verfolge ich auch immer mal wieder, ist recht interessant.
IAR EW ist ein grauenhaftes Tool. - Kein syntax highlighting. - Keine Sysntax vervollständigung - Umständliche Suche nach referenzen - Nichtssagende Fehlermeldungen - Crashes wenn versucht die Projektstrucktur zu ändern - Komplett undurchsichtig woher die Sourcen angezogen werden - Miese, bzw. nicht existente Integration von code-Generatoren Ich benutzte viel lieber Atmel Studio bei AVRs, bzw. E2-Studio bei Renesas µC Beide eclipe-basierend..
Fabian F. schrieb: > > Ich benutzte viel lieber Atmel Studio bei AVRs, bzw. E2-Studio bei > Renesas µC > > Beide eclipe-basierend.. Also das Atmel Studio basiert auf MS Visual Studio und nicht auf Eclipse.
Fabian F. schrieb: > IAR EW ist ein grauenhaftes Tool. Muss man aber nicht unbedingt benutzen, der Compiler läuft wie jeder andere Compiler auch auf der Kommandozeile, und das Tool, um ihn auf eine komplette Projektdatei anzuwenden, wurde ja oben schon genannt. Den GUI-Krams kann man ja initial einmal benutzen, um sich die Projektdatei generieren zu lassen. Danach kann man die auch nebenbei mit der Hand editieren, wenn man wirklich mal neue Dateien aufnehmen muss. Die IAR-Projekte sind einfach gestrickte XML-Dateien. Versionierung würde ich wohl auch separat machen, git, Mercurial, SVN, was auch immer einem am meisten liegt.
Angehängte Dateien:
-
Green_Hills.jpg
25 KB
Jörg W. schrieb: > IAR ist zweifellos ein guter Compiler, aber er ist auch zweifellos > verdammt teuer. Ach, das ist ziemlich relativ. Naja - den Keil gibt es auch nicht für umsonst und soweit ich gehört habe, sind die Compiler von Green Hills noch ein ganzes Stück teurer. Deren Selbstdarstellung als Anlage.. ;-) (siehe "http://www.ghs.com/products/compiler.html";) Allerdings hätte ich durchaus ganz gern mal deren Arm-Compiler zwischen den Fingern... (wenigstens als Demo) Was bitte all die Diskutierer hier mal beachten sollte, ist der Umstand, daß es Keil, IAR, Green Hills schon seit Jahren gibt und daß sie deshalb ganz offensichtlich so viele Compiler und andere SW verkaufen, daß es sie immer noch gibt und daß sie ihren Leuten vermutlich immer noch das monatliche Salär zahlen können. Was hier nervt und auch der ganze Grund ist für den ellenlangen Streit um des Kaisers Bart ist die Diskrepanz in den Sichtweisen der Leute. Das geht schon aus der Eröffnung hervor: Torsten R. schrieb: > ein Kunde von mir möchte gerne Software mit dem IAR entwickelt haben. > Ich bin mit der Kombination von GCC, GDB, CMake + Editor sehr zufrieden. > Ich kenne den IAR überhaupt nicht. Welche Argumente sprechen eurer > Meinung nach für oder gegen IAR? 1. Kunde will IAR 2. Torsten kennt nur GCC und will auch nix anderes wissen 3. Torsten sucht Argumente zu seiner Selbstbestätigung. Jaja! ohne sowas hätte der Torsten sich einfach ne Demoversion heruntergeladen und ausprobiert, fertig. Aber nein, er fragt hier, weil er sich dieser Mühe nicht unterziehen will. OK, da hängen Welten dran: Wer kein Windows auf seinem PC hat, tut sich schwer, eine SW für Windows ausprobieren zu wollen. Kunde will aber - was nun? Sachlich gesehen, sind Compiler wie IAR, Keil, Green Hills dem GCC elleweil haushoch überlegen. Ich denke grad an die Wrapper-Akrobatik in Assembler, die nötig ist, um sowas wie SVC's bei Verwendung des GCC zu hinzukriegen. Dabei ist das eines der grundlegenden Features der ARM-Prozessorfamilie. Ist nur ein Beispiel, aber deren gibt es mehrere. Auch sachlich gesehen haben alle renommierten Hersteller die Nase vorn, wenn es um Zulassungen oder anderweitige Rechtsdinge geht. IAR oder Keil oder Green Hills sind geschäftsfähig, sie können Garantien und Zusagen geben - und wo ist jemand, der sowas für den GCC tun kann? So einen gibt es nicht. Der Unterschied in den Sichtweisen zeigt sich an genau diesen Stellen. Das GCC-Lager kann sich ganz offensichtlich all die kommerziell relevant sein könnenden Gründe nicht vorstellen - oder sowas wird als zu unbedeutend abgetan. Ich hab weiter oben sogar sowas gelesen "was tun, wenn IAR mal Pleite geht?" - was offensichtlicher Unsinn ist, denn dann hätte man ja immer noch die bereits in Benutzung befindlichen Tools, die nicht welken oder verderben wie Frischgemüse. Naja, und daß kommerzielle Tools eben Geld kosten, sollte akzeptiert werden. Die Tools kosten deutlich weniger als das Firmenauto oder die Büro-Einrichtung oder ne mehrwöchige Krankheit eines MA. Jaja - ich weiß, da unterscheiden sich die Sphären der Bastler und Amateure von denen der Firmen. Aber genau DAS haben wir an allen Stellen: nicht nur bei Software, sonden auch beim Bauelemente-Einkauf, bei Leiterplattenbestellungen, und so weiter. W.S.
W.S. schrieb: > Torsten sucht Argumente zu seiner Selbstbestätigung Wenn du auch nur etwas mehr vom Thread als das Eingangsposting gelesen hättest, könntest du dir diese unsachliche Unterstellung sparen, und große Teile deiner darauf aufbauenden Argumentationskette.
Jörg W. schrieb: > W.S. schrieb: >> Torsten sucht Argumente zu seiner Selbstbestätigung > > Wenn du auch nur etwas mehr vom Thread als das Eingangsposting gelesen > hättest, könntest du dir diese unsachliche Unterstellung sparen, und > große Teile deiner darauf aufbauenden Argumentationskette. Er hat leider völlig recht. Du lieber Jörg, bist leider auf der gleichen Linux-Spur wie der TE, und darum siehst du das offensichtliche nicht.
W.S. schrieb: > Torsten R. schrieb: >> ein Kunde von mir möchte gerne Software mit dem IAR entwickelt haben. >> Ich bin mit der Kombination von GCC, GDB, CMake + Editor sehr zufrieden. >> Ich kenne den IAR überhaupt nicht. Welche Argumente sprechen eurer >> Meinung nach für oder gegen IAR? > > 1. Kunde will IAR > 2. Torsten kennt nur GCC und will auch nix anderes wissen > 3. Torsten sucht Argumente zu seiner Selbstbestätigung. > Jaja! ohne sowas hätte der Torsten sich einfach ne Demoversion > heruntergeladen und ausprobiert, fertig. Aber nein, er fragt hier, weil > er sich dieser Mühe nicht unterziehen will. OK, da hängen Welten dran: > Wer kein Windows auf seinem PC hat, tut sich schwer, eine SW für Windows > ausprobieren zu wollen. Kunde will aber - was nun? Er hat nach Gründen dafür und dagegen gesucht. Wieso versuchen hier ständig Leute, eine eindeutige Ablehnung daraus zu machen?
:
Bearbeitet durch User
W.S. schrieb: > Allerdings hätte ich durchaus ganz gern mal deren Arm-Compiler zwischen > den Fingern... (wenigstens als Demo) Der ist wohl so schlecht, dass die jetzt auf LLVM wechseln: http://ds.arm.com/ds-5/build/arm-compiler-6/ (wohl mit einem eigenen Backend)
Cyblord -. schrieb: > Du lieber Jörg, bist leider auf der gleichen Linux-Spur wie der TE, und > darum siehst du das offensichtliche nicht. Du, lieber Cyblord, bist auf der gleichen „Linux-ist-Mist“-Spur wie unser berüchtigter W.S., daher siehst du gar nicht, dass der TE nach deutlich mehr an Nuancen gefragt hatte. Wenn du mich auch nur ansatzweise kennen würdest, wüsstest du übrigens, dass ich alles andere als „mit Linux verheiratet“ bin. Jetzt bitte wieder zurück zu sachlichen Argumenten. (Da hatte W.S. wenigstens ein paar drin.)
:
Bearbeitet durch Moderator
Lieber Fremder, W.S. schrieb: > 2. Torsten kennt nur GCC und will auch nix anderes wissen > 3. Torsten sucht Argumente zu seiner Selbstbestätigung. wie kommst Du darauf? > Jaja! ohne sowas hätte der Torsten sich einfach ne Demoversion > heruntergeladen und ausprobiert, fertig. Ganz ehrlich: Um die Vor- und Nachteile eines Tools wirklich kennen zu lernen, braucht es deutlich mehr Zeit, als eben mal setup.exe anzuklicken, blinky.prj zu laden und F9 zu drücken. Warum sollte ich Deiner Meinung nach nicht von den Erfahrungen, die andere Entwickler bereits gemacht haben, profitieren dürfen? > Aber nein, er fragt hier, weil > er sich dieser Mühe nicht unterziehen will. Stimmt, meiner Meinung nach unterschätzt Du den Aufwand, einer Evaluation, die ein eigenes Urteil zulässt. > Wer kein Windows auf seinem PC hat, tut sich schwer, eine SW für Windows > ausprobieren zu wollen. Das wäre nicht das Problem. > Kunde will aber - was nun? s.o. > Ich denke grad an die Wrapper-Akrobatik in Assembler... > Dabei ist das eines der grundlegenden Features der > ARM-Prozessorfamilie. Ist nur ein Beispiel, aber deren gibt es mehrere. Danke für den Hinweis (auch wenn ich das Problem noch nicht hatte). > Naja, und daß kommerzielle Tools eben Geld kosten, sollte akzeptiert werden. Danke für den Hinweis, habe ich auch überhaupt kein Problem mit. mfg Torsten
W.S. schrieb: > Torsten R. schrieb: >> ein Kunde von mir möchte gerne Software mit dem IAR entwickelt haben. >> Ich bin mit der Kombination von GCC, GDB, CMake + Editor sehr zufrieden. >> Ich kenne den IAR überhaupt nicht. Welche Argumente sprechen eurer >> Meinung nach für oder gegen IAR? > > 1. Kunde will IAR > 2. Torsten kennt nur GCC und will auch nix anderes wissen > 3. Torsten sucht Argumente zu seiner Selbstbestätigung. Die letzten beiden Behauptungen sind reine Unterstellungen Deinerseits, und sie erwecken nicht den Eindruck von Gutwilligkeit. Tatsächlich fragt Torsten nämlich gerade deswegen nach dem IAR, weil er diesen nicht kennt und deswegen wissen will, welche Vor- und Nachteile er hat, so daß Deine Behauptungen zu 2b. und 3. offensichtlich Blödsinn sind. Mindestens. Von einem Profi, der zu sein Du so gerne behauptest, könnte man übrigens die Fähigkeit zur Kommunikation ohne derlei böswillige Unterstellungen und blödsinnige Pöbeleien erwarten. Ein wirklicher Profi würde auch wissen, daß der "Ratschlag"... > ohne sowas hätte der Torsten sich einfach ne Demoversion > heruntergeladen und ausprobiert ...so überflüssig und unklug ist wie nur irgendwas. Denn so lernt man im allerbesten Fall ein wenig über die Usability der GUI des Werkzeugs, aber überhaupt gar nichts über die besonders bei kommerziellen Entwicklungen wichtigen Fragen: Qualität, Kontinuität, ... solche Dinge weiß nur jemand, der langjährige Erfahrungen mit dem betreffenden Produkt hat. > Ich hab weiter oben sogar sowas gelesen "was tun, > wenn IAR mal Pleite geht?" - was offensichtlicher Unsinn ist, denn dann > hätte man ja immer noch die bereits in Benutzung befindlichen Tools, die > nicht welken oder verderben wie Frischgemüse. Ach, irgendwann kommt die nächste Windows-Version, dann die übernächste, und ehe Du Dich versiehst, stellt $Werkzeug den Dienst ein oder braucht irgendwelche hahnebüchenen Workarounds, um weiter zu funktionieren. Und wenn Du Dich mit Deiner ganzen Entwicklung von diesem einen Hersteller abhängig gemacht hast, dann hast Du ein echtes Problem. Die Grundsätze ordentlicher Geschäftsführung beinhalten nämlich, solche Abhängigkeiten und die daraus entstehenden Risiken wo möglich zu minimieren.
Cyblord -. schrieb: > Er hat leider völlig recht. Du lieber Jörg, bist leider auf der gleichen > Linux-Spur wie der TE, und darum siehst du das offensichtliche nicht. Soweit ich weiß, ist Jörg auf der FreeBSD-Spur. Aber das macht für elaborierte %Irgendwas%-Fanatiker vermutlich keinen Unterschied.
Sheeva P. schrieb: > Cyblord -. schrieb: >> Er hat leider völlig recht. Du lieber Jörg, bist leider auf der gleichen >> Linux-Spur wie der TE, und darum siehst du das offensichtliche nicht. > > Soweit ich weiß, ist Jörg auf der FreeBSD-Spur. Aber das macht für > elaborierte %Irgendwas%-Fanatiker vermutlich keinen Unterschied. Und der TE setzt auch kein Linux ein :-)
Max D. schrieb: > Selbst Atmel presöhnlich setzt inzwischen auf einen (etwas verpatchten) > GCC als ihren "Standart-AVR-Compiler". So überlegen kann IAR also nicht > sein. Ist er aber. Wenn der für lau wäre, könnte selbst ich mir an vielen Stellen die Entwicklung in Asm sparen... Der Vorteil aus der Sicht von Atmel bei der Benutzung von gcc ist einfach nur: der ist für lau und für viele Zwecke gut genug. Und: wo er suboptimal ist, kann Atmel als direkte Folge größere (und teurere) Units verkaufen. Aus Sicht von Atmel ist der gcc die ultimative Win-Win-Situation. Atmel kann hier nix falsch machen. Für die Befreiung von der OSS-Freiheit und ein gewisses Grundmass an vendor-lockin sorgen dann eben diese komischen Patches... So einfach ist das zu erklären... Man muß schon ziemlich doof sein und sowas von garnix davon verstehen, wie der Hase läuft, um das nicht selber unmittelbar aus der Sachlage ableiten zu können... Kurzfassung: du weißt nix und du kannst nix, bist aber ofensichtlich ganz glücklich damit. Möge es dir gegeben sein, nicht allzu schnell allzu unsanft aus deinem Traum geweckt zu werden...
Nightly-Builds via Buildbot und automatisierte Unit- und Hardware-in-the-Loop-Tests lassen sich mit der GNU-Toolchain sehr leicht bauen. So machen wir das bei größeren Embedded-Projekten wenn viele Leute gleichzeitig am Code arbeiten. Keine Ahnung wie gut man aktuelle IAR bzw. Keil Compiler in solche Umgebungen einbauen kann. Zumindest mit Cygwin/Mingw & Co sollten sich diese Tools halbwegs professionell unter Windows verwenden lassen. Wobei das bei kleinen Projekten und/oder nur einem Entwickler am Projekt natürlich nicht mehr so wichtig ist...
Anton schrieb: > Keine Ahnung wie gut man aktuelle IAR bzw. Keil Compiler in solche > Umgebungen einbauen kann. Geht schon auch, aber wenn du parallelisieren willst, musst du noch mehr $$$ investieren für alle Instanzen, die parallel laufen können sollen. Am Ende ist auch so'n IAR weiter nichts als der Aufruf eines Kommandos, welche eine C-Datei als Input bekommt und eien Objektdatei als Output generiert.
Cyblord -. schrieb im Beitrag #4363600: > Natürlich ist die IDE vom IAR nicht der Weisheit letzter Schluss (lange > nicht), aber man muss da nicht so ein Geschiss drum machen. Ich muss > auch manchmal IAR nutzen. Manchmal GCC. Manchmal was ganz anderes So ist > das halt. Wohl die beste Aussage im ganzen Thread. Wenn der Kunde gute Gründe (IAR schon im Haus, andere Entwickler arbeiten damit, nachfragen!) für den IAR hat, warum nicht?!? Ich durfte mal in einer Abteilung arbeiten, in der fast jeder Entwickler andere Tools zum editieren verwendet hat. Gut, der Compiler war überall gleich und kompiliert wurde mit großen .bat Dateien. Ok, das war um die Jahrtausendwende rum. Das schlimmste war damals EasyCase, das hat den Code der anderen Entwickler auch mit Formatierungskomentaren zerhackstückselt. Die anderen Entwickler hatten schon Tools geschrieben, um den "Käse" wieder rauszufiltern. Hier wäre mal eine einheitliche Enwicklungsumgebung sinnvoll gewesen. Und wenn der Kunde Entwicklung unter Windows will, dann bekommt er das auch. Man muss halt als Entwickler flexibel sein. Aber nachfragen würde ich schon, ob diese "guten Gründe" vorliegen. Nicht, das irgend ein Vertriebler dem "Entscheider" was aufgeschwatzt hat. Blöd wäre halt, wenn du nicht beim Kunden arbeitest und du dir selbst den IAR kaufen müsstest. Dann musst du halt einen Preiszuschlag aushandeln oder du lässt das Projekt sein. Im Übrigen halte ich den gcc sehr wohl für ein professionelles Produkt. Gibt ja auch für die ARM Version einen schönen Installer https://launchpad.net/gcc-arm-embedded. Ein Softwareentwickler sollte schon die Grundprinzipien von Make-Dateien Verstanden haben, zumal viele IDEs intern mit Makedateien arbeiten. Ein Entwickler, der Makedateien ablehnt ist genauso wenig professionell wie deiner, der nur den gcc unter Linux verwenden möchte.
c-hater schrieb: > Atmel > kann hier nix falsch machen. Für die Befreiung von der OSS-Freiheit und > ein gewisses Grundmass an vendor-lockin sorgen dann eben diese komischen > Patches... Der gepatchte gcc ist genauso offen und frei wie der aus dem er ursprünglich hervorging. Wo soll da "vendor lock in" sein, bzw was hätte Atmel davon? Die verkaufen in erster Linie MCUs und keine überteuerten Compiler und je stressfreier der Kunde die MCUs benutzen kann desto besser fürs Geschäft.
Nochwas: Das Grausame an den Makefiles ist, wenn ein Entwickler viele absolute Pfade einbaut. Würde man alles über ein Basisverzeichnis kodieren und Realpath einbauen (sowas: BASEDIR = $(realpath ..)" dann kann man das Makefile sogar UNVERÄNDERT unter Linux und Windows verwenden, völlig egal, wo man das Quellverzeichnis hin kopiert, wenn die Tools (arm-none-eabi-gcc usw.) im Pfad sind.
Bernd K. schrieb: > Die verkaufen in erster Linie MCUs und keine überteuerten Compiler und > je stressfreier der Kunde die MCUs benutzen kann desto besser fürs > Geschäft. Sie haben übrigens ziemlich lange gebraucht, bis sie den AVR-GCC als vollwertig genug für sich akzeptiert haben. Durch ihre Wurzeln, die mit einer Zusammenarbeit mit IAR begannen (und die innerhalb von Atmel jedem eine kostenlose IAR-Lizenz beschert haben), haben sie in ihren Appnotes über viele Jahre nur Code für den IAR abgegeben. Teils waren es übrigens durchaus ihre Kunden (und auch und vor allem aus Kostengründen, Stichwort nightly builds wurde ja schon genannt), die dann auf den AVR-GCC gedrängt haben. Nein, das waren keine kleinen Kunden, sonst hätte sich da kein FAE (Field Application Engineer) drum kümmern müssen, der wird erst ab einem nicht ganz kleinen Jahresumsatz aktiv.
klausro schrieb: > Nochwas: Das Grausame an den Makefiles ist, wenn ein Entwickler > viele absolute Pfade einbaut. Das gleiche Problem hast Du auch, wenn Du so etwas in den Project-Files einer IDE einträgst. Das gilt generell für build Prozesse.
:
Bearbeitet durch User
Torsten R. schrieb: > Das gleiche Problem hast Du auch, wenn Du so etwas in den Project-Files > einer IDE einträgst. Nur dass es dort leider so ziemlich Standard ist, das so zu machen.
Ich hab mal IAR verwenden dürfen. Version 4 und 5 Editor war grausam. VS 6 war damals noch besser. Voralllem wenn man noch Java mit eclips verwendet, oder mit einem aktuelles VS vergleicht ... Ich ham mal die IDE reproduzierbar zum Absturz gebracht durch eine include loop. Der IAR Compiler hat wenigstens gemekert. Die IAR IDE hat sich nur verabschiedet. Absolute Pfade hab ich manuell beheben dürfen. Die Projekt Dateien waren zum glück Text Dateien. Die Stabilität unter W7 ist bescheiden! IAR hat damals mit USB dongels gearbeitet. IAR hat damals auf j-link als debug prob gesetzt. Der läuft auch mit dem GCC. Im Gegensatz zum u-link von Keil.
In einer Sache kommt nur wenig/nichts an den GCC ran. Ich kann die selbe Toolchain sowohl für x86, als auch für alles vom AVR, ARM über MSP430 bis RL78 verwenden. Einmal Toolchain lernen, immer anwenden. Letztens für RL78: vorhandene Makefile für ARM hergenommen, compiler-optionen angepasst, Linkerskript, startup-dateien, etc aus Beispiel-Projekt kopiert, läuft. Keine neue IDE, keine neue Toolchain. Für die Fraktion, die GCC als "Hobby-Compiler" in die Ecke stellt: Ratet mal, mit was der Kernel (und einiges mehr) auf eurem Android-Handy gebaut ist. GCC. Ein Projekt vom Umfang des Linux-Kernels zu bauen können wohl weder IAR noch Keil von sich behaupten.
Lukas K. schrieb: > Ein Projekt vom Umfang des Linux-Kernels zu bauen können wohl weder IAR > noch Keil von sich behaupten. Warum nicht? Ist ja nicht so, dass ein Compiler irgendwie nach 10000 Zeilen Quellcode seinen Dienst verweigern würde.
Lukas K. schrieb: > In einer Sache kommt nur wenig/nichts an den GCC ran. Ich kann die selbe > Toolchain sowohl für x86, als auch für alles vom AVR, ARM über MSP430 > bis RL78 verwenden. Einmal Toolchain lernen, immer anwenden. Ist bei IAR auch nicht anders. Schau Dir mal die Liste der unterstützten Architekturen an. Die ist auch nicht kurz. Und IAR für MSP430 funktioniert genauso wie IAR für dsPIC. > Für die Fraktion, die GCC als "Hobby-Compiler" in die Ecke stellt: Ratet > mal, mit was der Kernel (und einiges mehr) auf eurem Android-Handy > gebaut ist. GCC. Ein Projekt vom Umfang des Linux-Kernels zu bauen > können wohl weder IAR noch Keil von sich behaupten. Wenn ich mir anschaue, was inzwischen in der Automobilindustrie abgeht, wäre ich mir da nicht so sicher. IAR ist dort quasi Branchenstandard. fchk
Frank K. schrieb: > Schau Dir mal die Liste der unterstützten Architekturen an. Dass x86 dabei ist, wäre mir neu. Ansonsten ist das natürlich richtig, die unterstützen alles Mögliche. Allerdings muss man für jede Architektur neu Geld hinlegen. Was mich bei AVR-IAR immer genervt hat ist, dass es nicht geschafft haben, da endlich mal den ELF-Standard zu unterstützen, obwohl sie ELF natürlich für viele andere Architekturen anbieten. Damit hat man außerhalb ihrer Toolchain keine Chance auf irgendein Postprocessing.
Lukas K. schrieb: > Für die Fraktion, die GCC als "Hobby-Compiler" in die Ecke stellt: Ratet > mal, mit was der Kernel (und einiges mehr) auf eurem Android-Handy > gebaut ist. GCC. Ein Projekt vom Umfang des Linux-Kernels zu bauen > können wohl weder IAR noch Keil von sich behaupten. Natürlich können die das. Der ARMCC hat schon vor 10 Jahren Projekte mit mehreren 100MB grossen Images zusammengebaut. Das war z.b. Firmware für Feature Phones. Ist aber kein Qualitätsmerkmal. Der GCC ist ein völlig überfrachtetes Projekt und wird sicher bald vom LLVM beerbt. Die Frage die sich mir aufdrängt ist eher: wer repariert deinen Compiler wenn er mal aufgibt? Postest du dann deinen Kundencode in einen öffentlichen Bugtracker? Und wie testest du vernünftig? Gibt der GDB inzwischen mehr her als rudimentäres Debugging? Am Ende sollte ich vielleicht zu nicht-kommerziellen Tools in der Auftragsentwicklung raten. Dann bleiben mehr Aufträge für die die pragmatisch entscheiden und weniger aus eigenem Glauben.
Mr M. schrieb: > Und wie testest du vernünftig? Ich kann mir ehrlich gesagt nicht vorstellen, wie man mit einem Debugger vernünftig testen sollte.
Jörg W. schrieb: > Lukas K. schrieb: >> Ein Projekt vom Umfang des Linux-Kernels zu bauen können wohl weder IAR >> noch Keil von sich behaupten. > > Warum nicht? > > Ist ja nicht so, dass ein Compiler irgendwie nach 10000 Zeilen Quellcode > seinen Dienst verweigern würde. Klar, aber wenn ein Compiler den Linux-Kernel und auch sonst >90% an Software, die auf meinem System läuft schafft, dann wird's auch für meine Anwendungen tun. Trifft bei RL78 ehr weniger zu, aber vom nicht-Architekturspezifischen Teil weiß ich's schonmal. Frank K. schrieb: > Lukas K. schrieb: >> In einer Sache kommt nur wenig/nichts an den GCC ran. Ich kann die selbe >> Toolchain sowohl für x86, als auch für alles vom AVR, ARM über MSP430 >> bis RL78 verwenden. Einmal Toolchain lernen, immer anwenden. > > Ist bei IAR auch nicht anders. Die Unterscheidung Embedded-Compiler / Anwendungs-Compiler will mir nicht so recht einleuchten. Am Ende vom Tag machen beide das selbe. Weshalb also nicht die gleiche Infrastruktur nutzen?
Mr M. schrieb: > wer repariert deinen Compiler wenn er mal aufgibt? Postest du dann > deinen Kundencode in einen öffentlichen Bugtracker? Wenn du sensitiven Code hast, würdest du den denn einem Hersteller in die Hand drücken? Ich nicht. Ich würde eine heruntergebrochene Version eines Beispiels einreichen, mit dem das Problem ausreichend nachgestellt werden kann. Das hält das IP bei mir, und erleichtert es dem Hersteller sowieso, sich aufs Wesentliche zu konzentrieren. Für mehrere tausend Euro sollte man durchaus auch im GCC-Umfeld einen Contractor finden, wenn man mal ein ernsthaft dringendes Problem hat. > Der GCC ist ein völlig überfrachtetes Projekt und wird sicher bald vom > LLVM beerbt. Ja, das kann gut passieren. Wo ist dabei das Argument für (oder gegen) IAR? Dieser Thread ist ja nicht überschrieben: „Gründe gegen GCC“.
Jörg W. schrieb: > Wenn du sensitiven Code hast, würdest du den denn einem Hersteller > in die Hand drücken? Ja, das kommt schon mal vor. In den letzten 15 Jahren hab ich häufiger Probleme gesehen die nur im Gesamtkontext auftreten (vor allem Linkerprobleme). Dann wird eben ein NDA mit dem Hersteller geschlossen (wofür hat man denn eine Rechtsabteilung). > Ich nicht. Ich würde eine heruntergebrochene Version eines Beispiels > einreichen, mit dem das Problem ausreichend nachgestellt werden kann. > Das hält das IP bei mir, und erleichtert es dem Hersteller sowieso, > sich aufs Wesentliche zu konzentrieren. Gut. Wenn das geht. Schlecht wenn nicht. Und der Liefertermin naherückt. > Für mehrere tausend Euro sollte man durchaus auch im GCC-Umfeld einen > Contractor finden, wenn man mal ein ernsthaft dringendes Problem hat. Richtig, das ist der Punkt. Service kostet immer Geld. Richtig spannend wird es sicher wenn das Projekt auch noch ISO26262 oder ähnliche Stempel braucht. Da rücken die Lizenzkosten auf jeden Fall in den Hintergrund.
Mr M. schrieb: > Richtig spannend wird es sicher wenn das Projekt auch noch ISO26262 oder > ähnliche Stempel braucht. Da rücken die Lizenzkosten auf jeden Fall in > den Hintergrund. Ja, das bestreitet ja wohl auch keiner. Aber das ist eben in vielen Fällen nicht das Thema, und dafür ist es doch völlig OK, wenn der TE sich mal über das Für und Wider erkundigt, damit er mit dem Kunden einen für beide sinnvollen Weg findet. Ich mein', wenn der Kunde dem Entwickler extra eine IAR-Lizenz für 4000 spendieren müsste, die aber eigentlich zur Lösung seines Problems nicht zwingend erforderlich ist, dann kann er den Entwickler alternativ eine Woche länger beschäftigen und zusätzliche Gimmicks dafür bekommen.
Jörg W. schrieb: > Aber das ist eben in vielen Fällen nicht das Thema, und dafür ist es > doch völlig OK, wenn der TE sich mal über das Für und Wider erkundigt, > damit er mit dem Kunden einen für beide sinnvollen Weg findet. Ich hatte ein wenig den Eindruck er hat seine Entscheidung schon gefällt und möchte nur wissen wie er sich dem Kundenwunsch jetzt nicht anpassen muss. Der Kunde hat aber eben evtl. ganz andere Gründe wie unter anderem die Betriebssicherheit für sich als wichtig erklärt.
Mr M. schrieb: > Ich hatte ein wenig den Eindruck er hat seine Entscheidung schon gefällt > und möchte nur wissen wie er sich dem Kundenwunsch jetzt nicht anpassen > muss. Noch einer, der nicht den ganzen Thread sondern nur das Eingangsposting gelesen hat?
Lukas K. schrieb: > Die Unterscheidung Embedded-Compiler / Anwendungs-Compiler will mir > nicht so recht einleuchten. Am Ende vom Tag machen beide das selbe. > Weshalb also nicht die gleiche Infrastruktur nutzen? Unterschiedliche Anforderungen? MISRA? Funktionale Sicherheit mit SIL-irgendwas-Zertifizierungen? OSEK-Support? Besserer Code für spezielle Architekturen? etc. Wer nur einen Hammer hat, für den sieht alles wie ein Nagel aus. fchk
Frank K. schrieb: > Lukas K. schrieb: > >> Die Unterscheidung Embedded-Compiler / Anwendungs-Compiler will mir >> nicht so recht einleuchten. Am Ende vom Tag machen beide das selbe. >> Weshalb also nicht die gleiche Infrastruktur nutzen? > > Unterschiedliche Anforderungen? Inwiefern? Optimale und korrekte Umsetzung von C auf die jeweilige Maschine ist doch auf dem PC genauso gewünscht wie im Embedded-Bereich? Oder darf der C-Compiler für den PC schlampen? > MISRA? Sind ja erstmal nur Coding-Regeln. An die kannst du dich auf dem PC genauso halten (und es scheint nicht wenige Coding Standards zu geben, die das auch dort fordern). Ist also auch keine Sache, die man nur im Embedded-Bereich braucht. > Funktionale Sicherheit mit > SIL-irgendwas-Zertifizierungen? OSEK-Support? OK, sind sicher wirklich Dinge, für die im PC-Bereich keiner Geld in die Hand nehmen würde. Musst du aber auch beim IAR wohl extra bezahlen (ist natürlich da, wo man's braucht, ein wesentliches Argument, keine Frage). > Besserer Code für > spezielle Architekturen? Totschlagargument? „Meiner ist länger als deiner!“? Es wird wohl immer das Ziel der Compilerbauer sein, dass sie jeweils für ihre Zielarchitektur das beste rausholen. Da unterscheiden sich Keil, IAR, Green Hills, GCC und LLVM nicht. Wie nah jeder an dieses Ziel herankommt, ist immer noch eine andere Sache, aber auch da sind sie alle nicht so weit voneinander entfernt. Das Argument mit den Zertifizierungen ist ja völlig OK, die machste nicht einfach so für ein Opensource-Projekt, als Firma leistet man sich sowas dann, wenn man weiß, dass es einem die Kunden dann auch zurückzahlen werden. Schon beim Support wird es dünner, gibt's prinzipiell bei Opensource auch, und zumindest für das Standardprodukt bekommst du auch von IAR keine Zusage, in welchem Zeitrahmen sie einen Fehler reparieren werden (der dich zwar vielleicht nervt, aber eben nur dich und bei anderen nicht reproduzierbar ist). Für solche Garantien musst du auch dort nochmal extra Geld in die Hand nehmen. Was du als Garantie bekommst, ist eine Erstreaktion innerhalb einer bestimmten Zeit. Aber die kann auch darauf hinauslaufen, dass sie den Fehler einfach als solchen akzeptieren, wenn es denn einer ist, und dass sie ihn im Laufe der Zeit irgendwann mal reparieren werden.
:
Bearbeitet durch Moderator
Lukas K. schrieb: > Die Unterscheidung Embedded-Compiler / Anwendungs-Compiler will mir > nicht so recht einleuchten. Am Ende vom Tag machen beide das selbe. > Weshalb also nicht die gleiche Infrastruktur nutzen? Dann leuchte ich dir: Bei einem typischen µC-Projekt kommt am Schluß irgend eine Firmware heraus, die in den µC gebrannt wird und dort eben ihren Dienst tut. Nach welchen Kriterien innerhalb dieser Firmware die Kommunikation abläuft, also was da an binärer Interface-Gestaltung stattfindet, geht niemanden was an, hauptsache, es funktioniert, ist hinreichend optimiert und ist innerhalb der Firmware konsistent. Beim Schreiben von Anwendungen für oder Teilen von Betriebssystemen sieht das jedoch völlig anders aus, da müssen Konventionen eingehalten werden, die völlig außerhalb der verwendeten Toolchaines definiert wurden. Da muß die Toolchain auf ansonsten sinnvoll anwendbare Optimierungen pfeifen und im übrigen muß sie das gesamte binäre Layout der Anwendung dem Ziel-OS angepaßt liefern. Sonst wird da nix draus. Kurzum, OS oder Firmware sind zwei so unterschiedliche Paar Schuhe, daß es einfach NICHT sinnvoll ist, Programmiererkraft darauf zu verschwenden, beide unter einen Hut kriegen zu wollen. Jörg W. schrieb: > Ich mein', wenn der Kunde dem Entwickler extra eine IAR-Lizenz für > 4000 spendieren müsste, die aber eigentlich zur Lösung seines Problems > nicht zwingend erforderlich ist, dann kann er den Entwickler alternativ > eine Woche länger beschäftigen und zusätzliche Gimmicks dafür bekommen. Jörg, diese ganze Thread lebt NUR davon, daß der TO nur einen vermutlich kleinen Auszug aus den nur ihm bekannten Randbedingungen gepostet hat. Abgesehen davon mag es auch so sein, daß auch sein Kunde ihm nur das gesagt hat, was er für nötig gehalten hat. Woher sollen wir hier wissen, was dort tatsächlich im Busche ist!!!??? Jetzt den TO darin zu bestärken, gegen den dedizierten Wunsch seines Kunden zu argumentieren, würde ich deshalb für völlig fehl am Platze halten. Der einzige sinnvolle Rat an ihn ist: "Guck dir den IAR selber an, damit du ein Gefühl dafür kriegst, worauf du dich einlassen mußt, wenn du die Sache annimmst." Ich hätte an Torstens Stelle hier überhaupt keinen Thread aufgemacht, sondern mir nen IAR als Demo gezogen, ausprobiert und dann dem Kunden ein vernünftiges Angebot gemacht, wo eben auch der IAR sinnvoll mit eingebunden ist. Entweder vom Kunden gestellt oder auf Kunden's Kosten gekauft und nach Abschluß der Arbeiten mit übergeben oder sonstwie - wird ja wohl möglich sein, nen vernünftigen Vertrag zustande zu kriegen. W.S.
W.S. schrieb: > Ich hätte an Torstens Stelle hier überhaupt keinen Thread aufgemacht, > sondern mir nen IAR als Demo gezogen, ausprobiert Nochmal (auch für dich): mit einem bissel Demo lernst du keinen Compiler kennen. Darum hat er gefragt, um die Meinung von Leuten zu hören, die ihn schon besser kennen.
Frank K. schrieb: > Funktionale Sicherheit mit > SIL-irgendwas-Zertifizierungen? Bwahaha. Und du glaubst ernsthaft, dass die Zertifizierung eines Compilers auch nur irgendeinen Beitrag zur Sicherheit leistet? Die einschlägige Normenreihe zum Thema (61508, 62061) ist doch hinsichtlich allem, was nicht klappert oder mit Druckluft funktioniert, sowas von steinzeitlich. Jeder einigermaßen zeitgemäße Compiler ist doch bei seiner Komplexität davon sowas von meilenweit weg, dass jegliche Zertifizierung praktisch nur Augenwischerei und Abzocke ist. Das ist doch ähnlich wie bei MISRA-C: Stupides Anwenden von Regeln hat noch nie zu besserer (Code-)Qualität geführt.
Nase schrieb: > Und du glaubst ernsthaft, dass die Zertifizierung eines Compilers auch > nur irgendeinen Beitrag zur Sicherheit leistet? Die Zertifizierung hat nur einen geringen Einfluss auf die technische Sicherheit des Produktes. Wenn es jedoch für den Entwickler oder Hersteller um eine juristische Auseinandersetzung geht, hilft es ungemein, für möglichst viele eingesetzte Ressourcen (Material, Werkzeuge, Personal) irgendwelche Phantasiezertifikate aus der Schublade ziehen zu können. Ein Richter wird keine inhaltliche Prüfung einer Produktentwicklung durchführen können, aber wenn man ihm einen Haufen Papier vorlegt, auf dem ersichtlich ist, dass man sich vor und während der Produktentwicklung viele Gedanken gemacht hat, schindet das Eindruck. Ggf. kann man auf diese Art und Weise sogar den Schwarzen Peter in Haftungsfragen an Dritte weitergeben. Gerade in Großunternehmen schindet man als Entscheider eher Eindruck, wenn man (für den jeweiligen Anwendungsfall völlig überteuerte) Produkte oder Leistungen einkauft, für die Zertifizierungen vorliegen oder durch den Anbieter zumindest zugesagt sind. Das gilt als professionell. Benötigt man viele teure Werkzeuge, steigt dadurch das benötigte Budget. Bei der nächsten Verhandlung über Gehalt und Zielvereinbarung kann man als Mitarbeiter dann wiederum auf die hohe Budgetverantwortung verweisen und hierfür mehr Gehalt verlangen. Bedient man sich hingegen nur kostenloser oder schon im Hause befindlicher Ressourcen, fehlt die hohe Budgetverantwortung, obwohl man eigentlich sogar sehr im Sinne des Unternehmens gehandelt hat. Ich stimme allerdings völlig zu, dass man bei vielen Zertifizierungen als Techniker nur den Kopf schütteln kann.
Moment, es gibt noch Leute, die den GCC als "Hobbycompiler" ansehen? Es gibt doch von vielen Firmen zusammengeschnürte Pakete für komplette Entwicklungsumgebungen auf Basis des GCC (z.B. Rowley CrossWorks). Inklusive Support mit Hotfixes bei kritischen Bugs und Ähnlichem. Zum Thema Zertifizierungen weiß ich nichts Genaues, aber das gibt es sicher auch, wenn man genug Geld auf den Tisch legt. LLVM/clang entwickelt sich schnell, aber im Bereich der eingebetteten Systeme scheint mir der GCC noch die Nase vorn zu haben.
Jörg W. schrieb: > Nochmal (auch für dich): mit einem bissel Demo lernst du keinen > Compiler kennen. Nochmal ausdrücklich für dich: Das ist hier dediziert NICHT das Thema. Lies den Eröffnungsthread nochmal gründlich und leg zuvor mal deine BSD-Sichtweise ein wenig zur Seite. Abgesehen davon ist die IAR-Demo für 30 Tage oder so ähnlich komplett die Vollversion und wer kein Volltrottel ist, weiß binnen dieser Zeit sehr wohl, worauf er sich da einläßt. W.S.
Andreas S. schrieb: > Nase schrieb: >> Und du glaubst ernsthaft, dass die Zertifizierung eines Compilers auch >> nur irgendeinen Beitrag zur Sicherheit leistet? > > Die Zertifizierung hat nur einen geringen Einfluss auf die technische > Sicherheit des Produktes. [...] Und dieser Trend ist äußerst bedenklich. Nach dem ganzen Ärger mit diversen Sicherheitssteuerungen namhafter Hersteller weiß ich nichtmal mehr, ob ich so genau wissen möchte, wie die da programmieren. Noch viel schlimmer ist der Gedanke, auf welchen Schrott an Software man sich da möglicherweise verlässt, wenn man in die Maschine greift.
Nase schrieb: > Nach dem ganzen Ärger mit diversen Sicherheitssteuerungen namhafter > Hersteller weiß ich nichtmal mehr, ob ich so genau wissen möchte, /wie/ > die da programmieren. Etwas älter (2013) und dreht sich um PKWs bzw. u.a. um ein Gerichtsverfahren in den USA bei dem auch der Quelltext untersucht wurde... http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code "possible bit flips, task deaths that would disable the failsafes, memory corruption, single-point failures, inadequate protections against stack overflow and buffer overflow, single-fault containment regions, thousands of global variables." "Barr checked the source code against MISRA’s 2004 edition and found 81,514 violations." "watchdog supervisor “is incapable of ever detecting the death of a major task. That's its whole job. It doesn't do it. It's not designed to do it.”" usw. usf.
Torsten R. schrieb: > Kann man bei IAR Projekten relativ einfach im Versionsmanagement > erkennen, wenn jemand an einem Compiler-Schalter etwas geändert hat? Ist > Dokumentiert, in welchen Datei die Bild-Regeln abgebildet sind, und in > welchen Dateien bloß die Fenstergröße beim letzten Öffnen abgelegt sind? Die Projektdateien sind im XML-Format, also durchaus lesbar, wenn auch XML-typisch verbose. fchk
Frank K. schrieb: > Die Projektdateien sind im XML-Format, also durchaus lesbar, wenn auch > XML-typisch verbose. Etwas verwirrend ist, dass sie derer gleich mal drei Stück brauchen (deren Aufgabentrennung mir nicht völlig transparent ist). Auf die Schnelle habe ich dabei keine gefunden, in der Dinge wie die Fenstergröße stünden. Aber ansonsten: ja, Build-Optionen etc. sind drin. Typisch für solche Dateien aber, und da macht auch IAR keine Ausnahme, beim nächsten Versions-Upgrade ändern sie sich so gut wie immer.
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.