Hallo zusammen, was ist denn die landläufige Meinung dazu, welcher kommerzielle C Compiler für den AVR eine vernünftige Wahl ist? Die Frage nach dem AVR-GCC stellt sich nicht, also Bitte auf Beiträge der Form "Nimm doch GCC" verzichten, Danke sehr. Auf den ersten Blick fand ich folgende Compiler von: IAR Imagecraft Rowley Crossworks Codevision Gibt es hier Leute die mit einem dieser Compiler arbeiten, damit brauchbare, und vor allem verlässliche, Ergebnisse erhalten und kurz dazu berichten können? Die alten Beiträge hierzu habe ich größtenteils gelesen, jedoch interessiert mich mal ein Stand 2010/2011, da so ein Compiler ja eine laufende Entwicklung ist. Grüße, Jan
Jan S. schrieb: > Die alten Beiträge hierzu habe ich größtenteils gelesen, jedoch > interessiert mich mal ein Stand 2010/2011, da so ein Compiler ja eine > laufende Entwicklung ist. Meiner ist aus den 90er Jahren. Warum sollte ich eine neuere Version verwenden, wenn mir die alte reicht und ich neuere AVRs selber definieren kann? Ich leide nicht an Featureritis.
>Die Frage nach dem AVR-GCC stellt sich nicht Wieso nicht? Es wäre noch wichtig zu wissen was Dir am AVR-GCC nicht gefällt um hier gut beraten zu werden! Ist er zu preiswert? >Gibt es hier Leute die mit einem dieser Compiler arbeiten, damit >brauchbare, und vor allem verlässliche, Ergebnisse erhalten und kurz >dazu berichten können? Ob man brauchbare und zuverlässige Ergebnisse erhällt liegt zu 99.99% beim Programmierer selber und nur zu 0.01% beim Compiler. (Zumindest beim GCC! Ob die anderen Compiler auch so gut sind weiss ich nicht! ;o) Es gibt natürlich auch schlechte Compiler, aber diejenigen die Du auflistest, sind vermutlich alle ähnlich gut!)
Peter schrieb: > Wieso nicht? Es wäre noch wichtig zu wissen was Dir am AVR-GCC nicht > gefällt um hier gut beraten zu werden! Ist er zu preiswert? Im kommerziellen Umfeld ist u.a. auch Support und gelieferte Sicherheiten des Herstellers eine nicht zu unterschätztender Faktor. Da hat der gcc leider wenig bis garnichts zu bieten. Auf den "Guten Willen" sollte man sich da nicht verlassen ...
Peter schrieb: > Wieso nicht? Es wäre noch wichtig zu wissen was Dir am AVR-GCC nicht > gefällt um hier gut beraten zu werden! Ist er zu preiswert? Atmi schrieb: > Im kommerziellen Umfeld ist u.a. auch Support und gelieferte > Sicherheiten des Herstellers eine nicht zu unterschätztender Faktor. Da > hat der gcc leider wenig bis garnichts zu bieten. Auf den "Guten Willen" > sollte man sich da nicht verlassen ... Das trifft es relativ genau aus kommerzieller Sicht. Aus persönlicher Sicht halte ich nicht viel davon ein so mächtiges System wie GCC auf einen AVR loszulassen. Alleine das die Optimierungen des GCC bei AVRs öfters mal nach hinten losgehen, ist ein recht deutliches Indiz dafür, das ein AVR nicht dem Hauptentwicklungsziel des GCC entspricht. Ein kommerzieller Compiler wird dann doch recht häufig, für deutlich weniger Platformen entwickelt.
Peter schrieb: > Wieso nicht? Es wäre noch wichtig zu wissen was Dir am AVR-GCC nicht > gefällt um hier gut beraten zu werden! Ist er zu preiswert? Es gibt z.B. Anwendungen im Security Bereich, wo die gesamte Toolchain von einem Sicherheitsgutachter zertifiziert werden muß. Diese Toolchain muß dann zwingend verwendet werden, ansonsten wird eine langwierige und teure Neuzertifizierung nötig. Da kann man mal nicht so einfach den Rat befolgen: "Nimm halt Version xyz, da ist Dein Fehler behoben." Es geht dabei nicht um Gefallen, der Hobbybastler hat einfach nicht die Probleme die sich in einigen professionellen Bereichen ergeben und kennt sie auch nicht. Daher kann ich Jan verstehen. Am Ende zählt immer der Projekterfolg und da ist "kostenlos" nicht immer ein guter Rat.
Ich habe früher Imagecraft und Codevision verwendet, benutze aber nun seit über 5 Jahren fast auschliesslich den AVR-GCC (WinAVR mit Eclipse) Ich hatte eigentlich nie ein Problem, bei dem ich via Forum schlechter bedient wurde als über den Support kommerzieller Compiler. Updates waren zudem immer gratis, aber die Kosten steht bei Dir ja nicht im Vordergrund. Vieles findest Du sogar im Forum hier (leider auch zu viele möchtegern Besserwisser die bloss Lästern, Spotten, Streiten und Blödsinn verzapfen) Als qualitativ viel besseres Forum empfehle ich: www.afrfreaks.net >Alleine das die Optimierungen des GCC bei AVRs öfters mal nach hinten >losgehen, ist ein recht deutliches Indiz dafür, das ein AVR nicht dem >Hauptentwicklungsziel des GCC entspricht. Im Vergleich (Codegrösse/Geschwindigkeit) kann der AVR-GCC aber mit den anderen Compiler trotzem ganz gut mithalten! Zurück zur Ursprünglichen Frage: Alle Compiler die Du aufgelistet hast sind gut, es ist eher eine persönliche Geschmacksache, was einem am besten liegt, dafür bieten ja alle Demoversionen an. Imagecraft + Codevision halten sich leider nicht an ANSI-C, IAR hingegen ist ein sehr vollumfänglicher ANSI-C Compiler. IAR ist verutlich der "beste" Compiler, aber auch mit Abstand der teuerste.
>Es gibt z.B. Anwendungen im Security Bereich, wo die gesamte Toolchain >von einem Sicherheitsgutachter zertifiziert werden muß. So sprechen Papiergläube Q-Leute! Auf Papier kann man alles mögliche schreiben, unterzeichnen und zertifizieren, heisst aber noch lange nicht, dass es dann auch so ist! Ich benutze den GCC sogar für militärische Anwendung. 1.) Beim GCC liegt der vollständige Sourcode offen (Compiler, Libs, Binutils, Patches) und jeder Q-Fachman kann von mir aus die vollständigen Sourcen auditieren und prüfen ob er Schwachstellen und Fehler findet! Verlange sowas von IAR! 2.) Der GCC gehört zu den meist verwendeten Compiler und ist somit auch einer der durch die vielen Benutzer am besten getestet wird!
Ich habe GCC auch schon häufig für AVRs eingesetzt, und bin auch kein GCC oder Opensource Gegner, eher im Gegenteil. Aber im kommerziellen Bereich würde ich mich aber darauf ganz einfach nicht verlassen wollen. Ich habe keinerlei Ansprüche gegenüber der GCC oder avr-libc Community, und kann auch nicht, durch Leistung der Community gegenüber, für entsprechenden Ausgleich sorgen. Der Rest hat tatsächlich auch viel mit "Gefallen" zu tun, aber der Hauptgrund ist ein gewisser Supportanspruch gegenüber dem Hersteller eines kommerziellen Compilers. Auf diesen möchte ich im "Nicht-Hobby" Bereich einfach nicht verzichten. Die Forderung ANSI-C Kompatibilität, würde ich dabei nicht einmal unbedingt stellen, in Fällen in denen diese zum Tragen kommt(Compiler- oder Entwicklerwechsel), stellt sie aus meiner Sicht das geringere Problem dar. ;-)
Peter schrieb: > Vieles findest Du sogar im Forum hier (leider auch zu viele möchtegern > Besserwisser die bloss Lästern, Spotten, Streiten und Blödsinn > verzapfen) Was, meiner Meinung nach, zu einem grossen Prozenzsatz daran liegt, dass hier schlcihtweg jeder ohne Anmeldung, quasi anonym, posten kann. Die Hemmschwelle liegt dadurch sehr niedrig. Sehr schade das. Peter schrieb: > Als qualitativ viel besseres Forum empfehle ich: www.afrfreaks.net Ja kenne ich, evtl. sollte ich dort nochmal aktiv werden. Hier war ich halt gerade mal wieder etwas aktiv und dachte es kann nicht schaden.
Ich denke mal auch, der IAR dürfte der beste sein, wenn Geld keine Rolle spielt. Er hat sogar 64Bit-float, was ich beim GCC vermisse. Man kann ja ne 4kB-Version downloaden und testen. Was mich bei kommerziellen Tools immer abschreckt, ist die Nutzergängelung. Man arbeitet ja heutzutage nicht mehr nur auf einem PC, d.h. selbst als Einzelnutzer müßte man mehrere Lizenzen kaufen. Peter
Peter Dannegger schrieb: > Ich denke mal auch, der IAR dürfte der beste sein, wenn Geld keine Rolle > spielt. Geld spielt immer eine Rolle, mein letzter Stand beim IAR waren irgendwas um die 4T€. Die würde ich nur ungern ausgeben, wenn andere Compiler dem IAR ebenbürtig sind. Daher meine Frage nach Erfahrungswerten.
Hallo Jan, nun die 4K€ sind Dir bekannt. Also, wir haben beruflich die Erfahrung gemacht, dass kommerziell nicht unbedingt besser ist. Diese Hersteller wollen Dir häufig auch noch Maintenance verkaufen. Weil Sie genau wissen, dass ihr Produkt fehlerhaft ist. Wenn Du nicht auf Grund äußerer Zwänge darauf angewiesen bist, ein Qualitätsmanagement vorzuhalten, dann kann ich Deine Geringschätzigkeit gegenüber dem GCC nur als Überheblichkeit werten. Denk einmal darüber nach, wie viele Leute einen kommerziellen Compiler nutzen und wie hoch die Fehleraufdeckungsrate durch den User bei diesen ist. Dieses Ergebnis halte doch einmal den frei verfügbaren GCC gegenüber. Weil die Verwendungsbreite ungleich größer ist, treten da die kleinsten Macken viel schneller zu Tage. Aus diesem Grund sind die meisten Automotive-Zulieferer vom Kommerz zum GNU (TriCore) gewechselt. Man hat erkannt, dass Teuer nicht zwingend Besser ist. Es gäbe für mich nur einen einzigen Grund einen kommerziellen Compiler zu kaufen. Nur wenn der ein Feature hat, über das der gcc nicht verfügt. Dann wäre die Beschaffung zu überlegen. Das ist zum Beispiel beim AT32UC3C0512 der Fall. Dieser µC hat eine Hardware-FPU. Der GNU 2.4.2 unterstützt sie z. Zeit leider nicht. Aber IAR kann das. Der kostet dann aber auch 4500€ + MWST. Dieser Spaß ist mir zu teuer, nur um Codegenerierte Modelle ordentlich zu treiben. In einem Punkt gebe ich Dir allerdings Recht. Der Zugriff auf Flash-Konstanten im AVR ist beim Win-AVR abweichend vom Standard umgesetzt. Das nervt mich auch... So, nun viel Spaß beim Geld ausgeben wünscht Dir Carsten
cskulkw schrieb: > Wenn Du nicht auf Grund äußerer > Zwänge darauf angewiesen bist, ein Qualitätsmanagement vorzuhalten, dann > kann ich Deine Geringschätzigkeit gegenüber dem GCC nur als > Überheblichkeit werten. Wo auch immer Du jetzt in meinen Beiträgen Geringschätzung für den GCC herausliest...
Peter Dannegger schrieb: > Was mich bei kommerziellen Tools immer abschreckt, ist die > Nutzergängelung. > Man arbeitet ja heutzutage nicht mehr nur auf einem PC, d.h. selbst als > Einzelnutzer müßte man mehrere Lizenzen kaufen. Das handhaben die Hersteller sehr unterschiedlich. IAR bindet die Lizenz an einen Computer oder an einen Dongle: > Stand-alone license > When you order a stand-alone license for a single user, you > have the choice to lock the license to either of: > * The hardware identies within the computer such as the > hard disk ID and network card ID > * A hardware lock, or dongle, which makes it easy to move > the license between different computers and to avoid > difficulties in case of hardware failure. Das ist sehr restriktiv, die subtile Drohung im letzten Satz muss man sich nochmal genau durchlesen: "difficulties in case of hardware failure". Rowley macht das anders: > CrossWorks Commercial Licenses are licensed per developer not > per computer. As such, a single developer that has purchased > a single CrossWorks license, can activate his software on as > many machines as he needs to develop and support his applications. Gut, da ist immer noch die Nutzergängelung der "Aktivierung" enthalten, aber die ist explizit so oft zulässig, wie vom Nutzer für erforderlich gehalten wird. Auch scheint da die Nutzung auf verschiedenen Betriebssystemen mit enthalten zu sein; Crossworks gibt es schließlich nicht nur für Windows. > Named-Developer Commercial License > Covers commercial development by a single named engineer > on any supported host operating system.
cskulkw schrieb: > Es gäbe für mich nur einen einzigen Grund einen kommerziellen Compiler > zu kaufen. Nur wenn der ein Feature hat, über das der gcc nicht verfügt. > Dann wäre die Beschaffung zu überlegen. Es geht hier nicht um Features. Es geht schlichtweg darum, dass wenn ich einem Bug im GCC oder der avr-libc zum Opfer Falle, ich keinerlei Ansprüche gegenüber der Community habe, dass diese mir hilft(evtl. sogar zeitnah hilft). Bei einem kommerziellen Produkt sieht das schon anders aus.
Jan S. schrieb: > Bei einem kommerziellen Produkt sieht das schon anders aus. in wie weit sieht es denn da anders aus? Wenn durch einen Fehler dir bei einem Kunden ein großer schaden entsteht dann glaube ich kaum das dir der Hersteller vom Compiler den bezahlt. Der wird sagen - "Dafür macht man ja eine QS"
Peter schrieb: > in wie weit sieht es denn da anders aus? Wenn durch einen Fehler dir bei > einem Kunden ein großer schaden entsteht dann glaube ich kaum das dir > der Hersteller vom Compiler den bezahlt. Der wird sagen - "Dafür macht > man ja eine QS" Ok, das ist nicht ganz die Art von Fehler, die ich meinte. Ich meine eher Fehler die bei der Entwicklung und QS schon auffallen, aber vom Compiler oder Library herrrühren. Bei GCC / avr-libc und auch bei einem kommerziellen Produkt reporte ich diesen Fehler dann, aber nur beim kommerziellen Produkt habe ich einen Anspruch gegenüber dem Hersteller; bei GCC / avr-libc bin ich auf das Wohlwollen der Community angewiesen. Und dabei gehts es mir nicht einmal um Antwortzeiten.
OK Bugfixgarantie und Herstellergarantie, kann Bestandteil der Lizenz sein. Ist das bei Kommerziellen AVR C Compilern üblich? Von PC-Compilern kenne ich eher Own Risk und Servicepacks nach Gutdünken des Herstellers. BTW. Du kannst dir immer Support kaufen, oder gleich den WinAVR-Entwickler, siehe Atmel. Beim Gedanken an Drittsupport stehst du mit einem quellofffenen System vielleicht besser da als bei einem Closed Source Produkt. Bei Closed Source kannst du praktisch nur den Originalhersteller nehmen.
Jan S. schrieb: > Antwortzeiten. Wobei ich sogar sagen würde, dass, wenn du an der richtigen Stelle die richtigen Leute fragst, die Community dir schneller antwortet als ein Hersteller.
Jan S. schrieb: > bei GCC / avr-libc bin ich auf das Wohlwollen der Community angewiesen. > Und dabei gehts es mir nicht einmal um Antwortzeiten. warum? Die Quellen sind doch frei und du kannst wahrscheinlich auch C programmierne. Was hindert dich daran selber den Fehler zu beheben?
Was hast du denn gegen den kommerziellen Anbieter für Ansprüche? Zuerst mal mußt du in der Lage sein den Fehler als Fehler eindeutig nachzuweisen. Das ist mitunter schon mal nicht ganz einfach. Wenn dir dann der Hersteller sagt, ok du hast Recht wird mit der nächsten Version (in einem Jahr) behoben, was dann. Klagen? Oder solls nur darum gehen seinem Chef zu sagen: das Projekt wird nicht fertig weil xy einen Fehler drin hat? Es ist ja wohl allgemein bekannt, daß es fehlerfreie Software nicht gibt. Und wenn die Tools fehlerhaft sind muss man sie versuchen zu umschiffen. Der Hersteller hilft da wenig. Das Netz schon, und bei mehr verbreiteten Tools (wie gcc) auch mehr als bei den sündhaft teuren. Daß im gcc noch dramatische Fehler sind für das läppische Ansi C um das es hier geht ist ziemlich selten (ok bei den avr Optimierungen kam das schon mal vor). Ganz anders sieht es da aus wenns um Programme für PCs geht. Da liegen Welten zwischen. Auch die lib für die avrs ist recht bescheiden im Verhältnis zu dem was heute für die PC Programmierung nötig ist. Da kann man fast alles noch verstehen und nachvollziehen. Bei den Libs für den PC reicht 1 Leben wohl nicht mehr aus. Also meine Meinung ist, es ist für mich nicht vorstellbar, daß die Entscheidung für den gcc ein Projekt blockieren kann. Und wenn die Maschine die du damit steuerst Eisenbahnschienen zu Bandnudeln presst, kannst du auch keinen Hersteller eines Compilers in Regress nehmen. Selbst wenn es der Compiler war ist es immernoch dein Fehler zu wenige oder die falschen Tests gemacht zu haben.
Peter schrieb: >> bei GCC / avr-libc bin ich auf das Wohlwollen der Community angewiesen. >> Und dabei gehts es mir nicht einmal um Antwortzeiten. > > warum? Die Quellen sind doch frei und du kannst wahrscheinlich auch C > programmierne. Was hindert dich daran selber den Fehler zu beheben? Die Tatsache, dass ich fürs Bugfixing in Tools nicht bezahlt werde, sonst nichts.
Luk4s K. schrieb: >> Antwortzeiten. > > Wobei ich sogar sagen würde, dass, wenn du an der richtigen Stelle die > richtigen Leute fragst, die Community dir schneller antwortet als ein > Hersteller. Dürfte stark vom Hersteller abhängen, aber nicht unwahrscheinlich, ja.
Jan S. schrieb: > Die Tatsache, dass ich fürs Bugfixing in Tools nicht bezahlt werde, > sonst nichts. und für Supportmail schreiben an den Hersteller wird du wohl bezahlt? Wenn du damit dein Problem lösen kannst ist es sogar billger als auf das nächste update von Hersteller zu warten.
Jürgen schrieb: > Was hast du denn gegen den kommerziellen Anbieter für Ansprüche? Zuerst > mal mußt du in der Lage sein den Fehler als Fehler eindeutig > nachzuweisen. Das ist mitunter schon mal nicht ganz einfach. Wenn dir > dann der Hersteller sagt, ok du hast Recht wird mit der nächsten Version > (in einem Jahr) behoben, was dann. Klagen? Auch das dürfte sehr stark vom Hersteller abhängig sein, jemand wie IAR bietet möglicherweise bessere SLAs wie ein kleinerer Laden, welcher evtl. gar keine SLAs bietet. Der kleinere Laden antwortet aber aus Eigeninteresse evtl. schneller als IAR. Die Community antwortet möglicherweise am schnellsten, möglicherweise aber auch erstmal garnicht.
Peter schrieb: > und für Supportmail schreiben an den Hersteller wird du wohl bezahlt? > Wenn du damit dein Problem lösen kannst ist es sogar billger als auf das > nächste update von Hersteller zu warten. Das mag ja evtl. bei trivialen Fehlern in der libc noch alles aufgehen. Bei einem Fehler innerhalb der GCC Optimierung aber die totale Katastrophe sein, vom Arbeitseinsatz her. Nur weil ich C und Assembler beherrsche bin ich noch lange kein Experte für Compilerbau.
Naja. Vielleicht sollte man das ganze Thema ein wenig niedriger hängen, damit der TO damit was anfangen kann. Ganz ernsthaft wird sowas ja eigentlich erst bei Millionenprojekten mit Vertragsstrafen diskutiert, was hier wohl nicht zutrifft. Normale Hersteller wird man ohne besondere vertragliche Vereinbarung nicht über das vom BGB vorgegebene hinaus in Anspruch nehmen oder gar haftbar machen können. Es geht also letztlich um die Frage welcher der Hersteller "im allgemeinen" und "der Erfahrung nach" zuverlässig und kurzfristig Support leistet. Ich meine auch, das sich auf der Ebene GCC und die kommerziellen nichts nehmen. Das ist bei Compilern auch nicht unbedingt bemerkenswert. Hingegen spielt das bei Layoutprogrammen wie Eagle doch eine grössere Rolle weil Konkurenz doch eher rar ist. Ursprünglich hat der TO ja nur gefragt welcher der genannten Compiler brauchbare und verlässliche Ergebnisse bringt. Erst im Gesprächsverlauf ist ja (nicht von ihm) die Rede auf den Support gekommen. Man sollte eigentlich auch noch objektivieren was nun mit "brauchbar" und "verlässlich" gemeint ist; ich fürchte aber, dass, wie üblich bei solchen Fragestellungen, gar keine Ergebnisse einer vorherigen Reflektion über diese Begriffe verfügbar sind. Also ist letztlich nur eine Empfehlung mit Hinweis auf positive oder negative Eigenschaften der Funktion und des Support gemeint. Damit, denke ich, ist der TO erstmal zufriedenzustellen.
Stell dir mal die Supportabteilung von so einem Hersteller vor. Die werden den ganzen Tag mit Müll zugetextet in dem versucht wird die eigene Unkenntnis auf Fehler beim Hersteller schieben. Mit anderen Worten du bist mit einem wirklichen Fehler ohne 100% igen Nachweis sowieso im Autoreturn. Ich wollte da nicht arbeiten und den Anfängern ihre eigenen Fehler nachweisen. Trotzdem nochmal. Der Compiler und die paar hauchdünnen Libs werden dir beim AVR nie das Genick brechen. Es ist kein Szenario denkbar wo der Compiler das KO-Kriterium ist. Dazu ist die AVR Schiene in der Regel zu einfach. Bei Arm o.ä. siehr das schon anders aus, aber da liegt auch häufig noch ein Betriebssystem drunter, dynamischer Speicher u.v.m. Eine andere Welt halt. Natürlich gibts auch kommerzielle Libs wie Netzwerkstacks o.ä. Das hat aber erstmal nichts mit dem Compiler zu tun.
Jan S. schrieb: > Das mag ja evtl. bei trivialen Fehlern in der libc noch alles aufgehen. > Bei einem Fehler innerhalb der GCC Optimierung aber die totale > Katastrophe sein, vom Arbeitseinsatz her. Nur weil ich C und Assembler > beherrsche bin ich noch lange kein Experte für Compilerbau. Um die Fehler die bisher in Verbindung mit der Optimierung des GCC aufgetreten sind zu eliminieren reichte es aus ein paar Zeilen des eigenen!! Codes etwas umzubauen und schon lief es. Ein Katastrophenszenario sehe ich da nie.
Qwertz schrieb: > Man sollte eigentlich auch noch objektivieren was nun mit "brauchbar" > und "verlässlich" gemeint ist; ich fürchte aber, dass, wie üblich bei > solchen Fragestellungen, gar keine Ergebnisse einer vorherigen > Reflektion über diese Begriffe verfügbar sind. Da mein Ziel eigentlich war, mal Erfahrungen mit einzelnen kommerziellen Tools einzuholen, möchte ich jetzt nicht gleich ein Lastenheft hier posten. Qwertz schrieb: > Also ist letztlich nur eine Empfehlung mit Hinweis auf positive oder > negative Eigenschaften der Funktion und des Support gemeint. Damit, > denke ich, ist der TO erstmal zufriedenzustellen. Genau das war gemeint... Um es evtl. verständlicher auszudrücken, wenn sich die Antworten auf den GCC beziehen, postet sie woanders, wenn denn der Geltungsdrang so hoch so ist, dass ihr unbedingt posten müsst. Ich werde mich hier nicht erklären. Wenn es sich dennoch nicht vermeiden lässt, hier zum Thema GCC zu posten: Meine Bitte an den nächsten Mod der mitliest: Diesen Thread dicht machen.
Jan S. schrieb: > Ich habe GCC auch schon häufig für AVRs eingesetzt, und bin auch kein > GCC oder Opensource Gegner, eher im Gegenteil. > > Aber im kommerziellen Bereich würde ich mich aber darauf ganz einfach > nicht verlassen wollen. Ich habe keinerlei Ansprüche gegenüber der GCC > oder avr-libc Community, und kann auch nicht, durch Leistung der > Community gegenüber, für entsprechenden Ausgleich sorgen. > > Der Rest hat tatsächlich auch viel mit "Gefallen" zu tun, aber der > Hauptgrund ist ein gewisser Supportanspruch gegenüber dem Hersteller > eines kommerziellen Compilers. Auf diesen möchte ich im "Nicht-Hobby" > Bereich einfach nicht verzichten. Das war doch aber dein Posting? Es ging ja auch nur darum diese Aussage zu relativieren. Der Supportanspruch gegenüber dem Hersteller wird dir bei der Fehlersuche nicht viel nützen, da bis auf ein paar wenige Ausnahmen nicht der Compiler die Fehler verursacht. Und die paar Ausnahmen sind leichter mit ein paar Anpassungen im eigenen Code umschifft als darauf zu hoffen, geschweige denn darauf zu bestehen, dass der Herstelle hilft. Ich programmieren seit 20 Jahren mit allen möglichen Compilern von Borland Microsoft Zortech Watcom bis zu gcc. Am Anfang waren da schon ziemliche Bugs drin, gerade bei Borland. Aber wenn man dann auf Hilfe hofft, ist man ganz schön auf verlorenen Posten und hilft sich dann doch selbst. Das wird bei den trivial-C für den AVR auch immer klappen. Da liegen eben Welten zur normalen PC Programmierung dazwischen und der Compiler wird beim AVR einfach zu oft als zu wichtig eingestuft.
Dirk schrieb: > Es gibt z.B. Anwendungen im Security Bereich, wo die gesamte Toolchain > von einem Sicherheitsgutachter zertifiziert werden muß. Ich zweifle. Verwechselst du vielleicht Security und Safety?
Jürgen schrieb: > Das war doch aber dein Posting? Es ging ja auch nur darum diese Aussage > zu relativieren. Da steht aber nirgends das GCC schlecht wäre, ich nutze ihn ja sogar im Hobby Bereich. Jürgen schrieb: > Der Supportanspruch gegenüber dem Hersteller wird dir > bei der Fehlersuche nicht viel nützen, da bis auf ein paar wenige > Ausnahmen nicht der Compiler die Fehler verursacht. Ich bezweifle, dass man das allgemein sagen kann, aber ok. Was bedeutet das nun für die kommerziellen AVR Compiler? Sind die alle sinnfrei? Ich kann mir nicht vorstellen, dass man dies über alle verfügbaren nicht freien Compiler sagen kann. Mag ja sein, dass einige davon im Gesamtkontext schlechter als der GCC sind, aber alle? Wenn ich mir hier schon auf die GCC Debatte einlassen muss, dann will ich auch mal ein paar Argumente gegen GCC und für einen kommerziellen Compiler hören. Ich glaube nämlich nicht, das die alle gleichzusetzen sind.
Och, gibts bestimmt. Die Frage ist nur, wie groß der Unterschied ist: Zertifizierung durch Sicherheitsgutachter <--> Würfeln. Wie zertifiziert denn so ein Gutachter einen Compiler? Genau, Quelltext begutachten? Haha. Sich auf seinen Vorgänger/Zuarbeiter verlassen? Und wie macht der das? Genau, Quelltext lesen? Haha. ... Selbstverständlich ändert das nix daran: Wenn der Kunde scharf auf so ein blödes Gutachten ist. Aber sicherer macht es die Sache bestimmt nicht. Nun, Argumente gegen GCC: Sein Quelltext ist wenig bis garnicht überschaubar und nur noch schwer zu warten -- zumindest für den Otto-Normal-Programmierer. Quelldateien mit > 10000 (zehntausend) Zeilen sind schon irgendwo unhandlich. Er ist darüber nicht für 8bitter gebaut, entsprechend verknotet er sich die Hirnwindungen beim Optimieren. Manchmal geht das auch schief. Die Standardbibliothek hätte man stellenweise schöner konstruieren können, grad der '_'-Namensraum ist etwas... quer. Die Frage ist, wie viel besser andre das machen -- es wird sich nicht viel nehmen.
Jan S. schrieb: > ... Nur weil ich C und Assembler beherrsche ... Genau dann sollte es doch überhaupt kein Problem sein zu erkennen, daß - und nach Inspektion des Assemblercodes, WAS der GCC ggf. "wegoptimiert" hat. Übrigens mit großen Abstand am allerhäufigsten, weil der Entwickler beim staccato-artigen "Reinhämmern" des Sourcecodes die verfügbare Höchstgeschwindigkeit seines eigenen Verstandes so brachial überholt hat, daß der Compiler danach mehr Stenogekritzele als einen wohlstrukturierten Quelltext vorfindet, in dem sämtlich erforderlichen Randbedingungen für alle verwendeten Elemente zweifelsfrei aufgeführt sind.
GoodOldEquipment schrieb: > Übrigens mit großen Abstand am allerhäufigsten, weil der Entwickler beim > staccato-artigen "Reinhämmern" des Sourcecodes die verfügbare > Höchstgeschwindigkeit seines eigenen Verstandes so brachial überholt > hat, daß der Compiler danach mehr Stenogekritzele als einen > wohlstrukturierten Quelltext vorfindet, in dem sämtlich erforderlichen > Randbedingungen für alle verwendeten Elemente zweifelsfrei aufgeführt > sind. Der Spruch ist Klasse. :-D
Martin schrieb: >> Es gibt z.B. Anwendungen im Security Bereich, wo die gesamte Toolchain >> von einem Sicherheitsgutachter zertifiziert werden muß. > > Ich zweifle. > > Verwechselst du vielleicht Security und Safety? Jau, DAS kenne ich zu Gut, und nein darum geht es mir nicht. ;-)
Rufus Τ. Firefly schrieb: > IAR bindet die Lizenz an einen Computer oder an einen Dongle: Das ist natürlich völlig inakzeptabel. Ich reise zum Kunden, finde einen Fehler, kann ihn aber nicht beheben, weil die Lizenz nur für den Desktop-PC gilt. Oder ich reise mit Notebook und Dongle, die Fluggesellschaft verbummelt das Gepäck, wer ersetzt mir dann den 4500€-Dongle? Rufus Τ. Firefly schrieb: >> CrossWorks Commercial Licenses are licensed per developer not >> per computer. So muß es sein. Peter
Jan S. schrieb: > Hallo zusammen, > > was ist denn die landläufige Meinung dazu, welcher kommerzielle C > Compiler für den AVR eine vernünftige Wahl ist? > Auf den ersten Blick fand ich folgende Compiler von: > IAR > Imagecraft > Rowley Crossworks > Codevision Im Automotive-Bereich wird IAR aus eigener Erfahrung sehr gerne genommen, auch wegen MISRA-C Support. Der IAR erzeugt auch exzellenten Code, deutlich besseren als der GCC. Das heißt dann unter Umständen, dass man ein kleineres Device nehmen kann, was in Stückzahlen deutlich Geld spart. ImageCraft habe ich hier auch liegen. Er funktioniert, die Unterstützung von AVR Spezifika wie getrennte Code/Daten Adressräume finde ich dort (und beim IAR) besser gelöst als beim GCC, aber ansonsten kann ich keine großartigen Hilights finden. An den IAR kommt er in der Leistung (aber auch im Preis) nicht heran, und der IAR wird auch intern bei Atmel für Entwicklungen verwendet. fchk
So, jetzt muss ich auch noch einmal meinen Senf dazugeben. Die Zertifizierung eines Produktes bedeutet in sehr vielen Fällen einfach nur, dass der Hersteller in der Lage ist, den damit verbundenen bürokratischen Aufwand zu handhaben. Es bedeutet nicht automatisch, dass das Produkt gut ist. Ganz im Gegenteil bedeutet der Zertifizierungsstatus sogar, dass Bugfixes eben nicht durchgeführt werden dürfen, weil dadurch eine Neuzertifizierung erforderlich wäre. Außerdem ist man als Hersteller ja aus dem Schneider, weil man ja auf die bestehende Zertifizierung verweisen kann. Mit dem Erwerb eines kommerziellen Entwicklungswerkzeugs erwirbt man auch nicht automatisch eine komplette Haftungsübernahme durch den Hersteller. Ganz im Gegenteil schließen so ziemlich alle Hersteller den Einsatz ihrer Werkzeuge für alle Verwendungszwecke aus, bei denen eine Gefährdung von Mensch oder Material auftreten kann. Und selbst wenn eine Haftungsübernahme zugesichert werden sollte, so würde sie nur dann gelten, wenn das Entwicklungswerkzeug auf einer exakt einzuhaltenden Umgebung eingesetzt wird, d.h. im Falle eines Compilers ein bestimmter Rechner eines Herstellers, auf dem eine wohldefinierte Betriebssystemumgebung installiert ist. Es muss eben genau die Konfiguration sein, die für den Erhalt der o.a. Zertifizierung verwendet wurde. Und jeder weiß, dass es nahezu unmöglich sein wird, exakt diese Konfiguration aufzubauen. Selbst wenn der Compilerfehler auch auf anderen Systemen reproduzierbar sein sollte, ist das immer noch nicht der Freibrief für beliebige Schadenersatzansprüche. Die Zertifizierung eines Entwicklungsprozesses oder Produktes dient nur dazu, Schadenersatzforderungen auf Grund einfacher oder grober Fahrlässigkeit auszuschließen. In anderen Rechtssystemen, z.B. den USA, sieht das ganze schon anders aus. Deswegen schließen ja fast alle Versicherungen auch Schäden durch den Einsatz von Produkten in den USA aus.
Bevor das hier ausufert: Es geht mir nicht um eine Haftungsübernahme, das hat irgendwer in den Raum geworfen...
Jan S. schrieb: > Bevor das hier ausufert: Es geht mir nicht um eine Haftungsübernahme, > das hat irgendwer in den Raum geworfen... Ich möchte nur daran erinnern, wer als Erster das Wort "Ansprüche" in den Raum geworfen hat... Worin sollen denn diese Ansprüche bestehen? Schlimmstenfalls muss der Hersteller des Compilers einräumen, die spezifizierten Leistungen nicht erbracht zu haben, und erstattet dann einfach den Kaufpreis zurück. Und was dann? Dann hat man seine z.B. 4kEUR zurückerhalten und darf noch nicht einmal mehr den (angeblich) fehlerhaften Compiler weiterverwenden? Das wäre ja eine ganz tolle Lösung. Ich habe es selbst auch schon in sehr vielen Projekten bzw. Projektanfragen erlebt, dass zu viele Leute überhaupt nicht daran interessiert sind, alles daran zu setzen, dass das Projekt erfolgreich durchgezogen wird, sondern nur daran, im Falle eines Scheitern - welches ja schon fast postuliert wird - einen Schuldigen benennen zu können. Und wenn das Projekt scheitert und das Unternehmen mit sich reißt, stehen sie auch auf der Straße, selbst wenn dann irgendwann der Kaufpreis des Compilers zurückerstattet werden sollte.
Andreas Schweigstill schrieb: > Ich möchte nur daran erinnern, wer als Erster das Wort "Ansprüche" in > den Raum geworfen hat... Herrje... Ansprüche sind dann immer gleich Haftungsansprüche oder was? Ich erwarte z.B. von einer Open Source Community nicht, dass man sich überhaupt um einen Bugreport kümmert, schließlich sind wir(man merke auf) Freiwillige. Von einem Hersteller, der sogar Support einräumt, erwarte ich hingegen schon das er evtl. Fehler in Compiler und Library behebt. Zeitnah sei jetzt mal dahin gestellt, aber das hängt, wie man nachlesen kann, stark vom jeweiligen Hersteller ab. Eine Haftungsübernahme ist für mich in jedem Fall lächerlich, das erwarte ich auch von niemandem, zumindest nicht im Software Segment.
Ich werde ab sofort nur noch auf Posts eingehen, welche "Erfahrungsberichte" und somit für eine Einschätzung nützliche Information enthalten.
Frank K. schrieb: > ImageCraft habe ich hier auch liegen. Er funktioniert, die Unterstützung > von AVR Spezifika wie getrennte Code/Daten Adressräume finde ich dort > (und beim IAR) besser gelöst als beim GCC, aber ansonsten kann ich keine > großartigen Hilights finden. An den IAR kommt er in der Leistung (aber > auch im Preis) nicht heran, und der IAR wird auch intern bei Atmel für > Entwicklungen verwendet Welche Imagecraft Variante konntest Du denn vergleichen? Da gibt es ja mehrere Ausprägungen mit mehr oder weniger "Optimierung". ;-)
Jan S. schrieb: > Welche Imagecraft Variante konntest Du denn vergleichen? Da gibt es ja > mehrere Ausprägungen mit mehr oder weniger "Optimierung". ;-) 7.x Professional Das Upgrade auf die 8'er habe ich mangels Bedarf erstmal nicht mitgemacht. fchk
AVR-GCC für ATTiny/8bit macht bei den Optimierungen viel Mist. Würde ich nur benutzen, wenn Du auf Optimierungen verzichten kannst. So der Stand mit Toolchain 2010-01-10. Zu anderen Targets/Versionen kann ich nichts sagen. Wenn Du Lust hast, dann mach doch beim LLVM AVR-backend mit!
Peter Dannegger schrieb: Moin Moin, > Rufus Τ. Firefly schrieb: >> IAR bindet die Lizenz an einen Computer oder an einen Dongle: > > Das ist natürlich völlig inakzeptabel. stimmt! > Ich reise zum Kunden, finde einen Fehler, kann ihn aber nicht beheben, > weil die Lizenz nur für den Desktop-PC gilt. > > Oder ich reise mit Notebook und Dongle, die Fluggesellschaft verbummelt > das Gepäck, wer ersetzt mir dann den 4500€-Dongle? und wer einen 4500,- Euro USB-Key mit in das Aufgabegepäck tut gehört ja auch bestraft. Sowas hat man am Mann! :-) Grüße, Micha
Rufus Τ. Firefly schrieb: >> * The hardware identies within the computer such as the >> hard disk ID and network card ID Micha S. schrieb: > und wer einen 4500,- Euro USB-Key mit in das Aufgabegepäck tut gehört > ja auch bestraft. Sowas hat man am Mann! :-) Blos gut das es auch USB-Ethernetadapter gibt. Aber nicht auf dumme Gedanken kommen.
Jan S. schrieb: > Wenn ich mir hier schon auf die GCC Debatte einlassen muss, dann will > ich auch mal ein paar Argumente gegen GCC und für einen kommerziellen > Compiler hören. Ich glaube nämlich nicht, das die alle gleichzusetzen > sind. Für den Einsatzzweck, für den du den Compiler brauchst, sind GNU-Tools nur dann eine realistische Option, wenn du dafür den gleichen Support erhälst -- also professionellen Support -- wie bei entsprechender Knete für einen proprietären Compiler auch. Falls hierzu das Beheben von Fehlern und Workarounds für evtl. Silicon-Bugs gehören, wird das so oder so teuer. Ich weiß jetzt nicht, ob du dich nach professionellem Support für GNU AVR-Tools umgeschaut hast und ob es sowas gibt und was das kostet. Jedenfalls ist "der Quellcode ist offen, also kann jeder die Bugs beheben, Optimierungslücken schliessen, etc." eine absolute Illusion (Hab schon ein paar Ports für 16/32-Bitter gemacht und weiß, wovon ich rede). Zur Zertifizierung eines Compilersystems gehören u.a. Nachweis/Nachvollziehbarkeit der Entwicklungsprozesse sowie Praxisbewährtheit. Die Fehlerfreiheit gehört nicht dazu; einfach deshalb, weil sie nicht beweisbar ist. Source-Reviews haben da eher psychologische Funktion. Bei Auftreten eines Compilerfehlers ist ein mögliches Vorgehen, entsprechende Quellpassagen zu meiden. Je aggressiver ein Compiler optimiert, desto schwieriger ist das, und gerade bei GCC wirst du kaum belastbare Aussagen erhalten, welche Quellkonstrukte welche GCC-Fehler definitiv ausschliessen. Für proprietäre Hersteller dürfte das aufgrund der Komplexität der Materie auch nicht einfach sein -- falls sie überhaupt Aussagen dazu machen. Hier haben proprietäre Compiler zumindest den Vorteil, daß das Wissen in einem einzigen Haus ist -- jedenfalls stell ich mir das in meiner Blauäugigkeit so vor, das das Wissen abrufbar ist... Eine weitere Möglichkeit, sich gegen Compilerfehler zu wappnen, ist das Verwenden einer (zertifizierten) Toolbox. Die Werkzeuge der Toolbox werden zertifiziert, und ob die Toolbox durch einen Compiler erstellt wurde oder von einem klöppelnden Äffchen ist eigentlich egal ;-) Freilich wird jedes Neuübersetzen der Toolbox eine neue Zertifizierung erfordern. Hier wird dann gerne sowas wie "Hex-Neutralität" gefordert, daß also das Beheben eines Compilerfehlers einen möglichst kleinen Fußabdruck im Hex-File hinterlässt. Bevor es sinnvoll ist, einen zertifizierten Compiler einzusetzen, muss erst mal geklärt sein, wie die damit erstellte Anwendung/Libs zu zertifizieren sind (statische Codeanalysen des hex, ...) dies wird durch Einsatz einer zertifizierten Toolbox, für die evtl. statische Analysen geliefert werden, nicht ganz so schmerzvoll. cskulkw schrieb: > Hallo Jan, > > nun die 4K€ sind Dir bekannt. Also, wir haben beruflich die Erfahrung > gemacht, dass kommerziell nicht unbedingt besser ist. Diese Hersteller > wollen Dir häufig auch noch Maintenance verkaufen. Weil Sie genau > wissen, dass ihr Produkt fehlerhaft ist. Wenn Du nicht auf Grund äußerer > Zwänge darauf angewiesen bist, ein Qualitätsmanagement vorzuhalten, dann > kann ich Deine Geringschätzigkeit gegenüber dem GCC nur als > Überheblichkeit werten. Das Problem ist nicht die Qualität von GCC, sondern daß Jan, wenn er GNU-Tools einsetzen will, einen professionellen Partner braucht, der den entsprechenden Support bietet, also z.B. -- einem bei Problemen mit der Anwendung der Tools beiseite steht -- klärt, ob "Compilerfehler" wirklich welche sind, am besten mit definierter Respond-Time -- Beheben von Tool-Fehlern, Absolvieren vorgegebener Testszenarien/-Suites, ... Wenn ein proprietärer Compilerherstaller das für 4 k€ liefert, ist's ein Schnäppchen, ditte falls ein professioneller Supporter für GNU avr-Tools das liefert. > Denk einmal darüber nach, wie viele Leute einen kommerziellen Compiler > nutzen und wie hoch die Fehleraufdeckungsrate durch den User bei diesen > ist. Dieses Ergebnis halte doch einmal den frei verfügbaren GCC > gegenüber. Weil die Verwendungsbreite ungleich größer ist, treten da die > kleinsten Macken viel schneller zu Tage. Aus diesem Grund sind die > meisten Automotive-Zulieferer vom Kommerz zum GNU (TriCore) gewechselt. > Man hat erkannt, dass Teuer nicht zwingend Besser ist. Auch GCC-Ports können lizensiert und teuer sein, Support ebenso. Gerade der angesprochene TriCore Compiler ist in einer Preislage, die an proprietäre Compiler heranreicht und -- je nach Supportpacket -- bei weitem über Jans Budget liegt. Freilich ist mir kein Supporter für GNU AVR-Tools bekannt, oder ob bei den proprietären Bugfixing etc. zum Support dazugehört. Teilweise verlangen Hersteller proprietärer Compiler für jeden Bugfix mächtig Extra-Flöcken, zumal dann, wenn der Fehler zeitnah behoben werden soll.
Alle bisherigen Beiträge beziehen sich auf die Theorie möglicher Fehler im Compiler. Da der TO nach Erfahrungswerten fragte, ein konkretes Beispiel: Ich hatte einen Fehler bei den eeprom_ Zugriffen. Nachdem ich zwei Tage bei mir gesucht hatte und klar war, dass mich keine Schuld trifft, hatte ich innerhalb von einem Tag einen Patch. Bezog sich auf die avr-libc, nicht Compiler. Es ist sicher im Sinn des TO wenn auch andere ihre Beispiele posten, wie oft sie einen konkreten Fehler hatten, bewiesen durch Patch oder Hotfix, und wie lange das gedauert hat. Vorzugsweise für die von ihm angefragten Produkte, aber auch im Vegleich zum gcc.
Für Codevision habe ich dazu bereits Aussagen gefunden, die sollen wohl recht flink sein. Eine Firma wie HP Infotech scheint mir auch eher auf Augenhöhe zu sein wie z.B. IAR. Es geht mir auch garnicht so um garantierte Antwortzeiten, es geht nur darum wenigstens "gefühlt" den Anspruch auf Support zu haben. Ein anderer Punkt beim GCC scheint ja auch zu sein, das dieser Compiler eher für größere Systeme designt ist, und ein ziemlicher Klotz ist. Alleine schon die Größe des Systems diktiert da ja eine gewisse Fehlerwahrscheinlichkeit. Was den Ansatz LLVM angeht, auch das scheint mit ein wenig überdimensioniert. LLVM würde ich frühestens ab ARM9 o.ä. sehen. Welchen Vorteil soll das bei AVR bringen?
Habe mir vor ca. 2 Jahren auf Kundenwunsch hin wegen Kompatibilität Codevision angeschafft. Funktioniert wunderbar, und günstig ist es auch.
X- Rocka schrieb: > auf Kundenwunsch hin wegen Kompatibilität Kannst Du das etwas detaillierter beschreiben? Zu was wurde Kompatibilität gefordert? Ist ja evtl. ganz hilfreich zu wissen.
Peter schrieb: > Wieso nicht? Es wäre noch wichtig zu wissen was Dir am AVR-GCC nicht > gefällt um hier gut beraten zu werden! Ist er zu preiswert? Das GCC geraffel ist doch einfach krank, das gehört doch einfach in die Tonne. Wenn man nicht einmal die Speicherzugriffe richtig im Griff hat. Ich sage nur printf_P(PSTR... und dieser ganze Schwachsinn. Ich war irgendwann davon so genervt dass ich Geld in die Hand genommen habe und mir eine IAR Workbench gekauft habe. Damit bin ich voll und ganz zufrieden.
wrdsdsd schrieb: > Das GCC geraffel ist doch einfach krank, das gehört doch einfach > in die Tonne. Wenn man nicht einmal die Speicherzugriffe richtig im > Griff hat. Ich sage nur printf_P(PSTR... und dieser ganze Schwachsinn. Das ist natürlich kompletter Schwachsinn. Das liegt nicht am gcc, sondern an der für C-Programmierung ungeeigneten Harvard-Architektur der AVRs. Wenn IAR das verbirgt, dann verwendet es sehr ineffizienten Code für Pointerzugriffe.
Rufus Τ. Firefly schrieb: > Das ist natürlich kompletter Schwachsinn. Das liegt nicht am gcc, > sondern an der für C-Programmierung ungeeigneten Harvard-Architektur der > AVRs. > > Wenn IAR das verbirgt, dann verwendet es sehr ineffizienten Code für > Pointerzugriffe. Das interessiert mich überhaupt nicht. Der Prozessor ist wie er ist, dafür benötige ich ein Tool. Ob der eine Harvard- oder eine Wurzelsepp-Architektur hat ist mir egal. Ich will mich darum nicht kümmern müssen. Das ganze wäre ja auch nicht so schlimm wenn der GCC sich dazu bequemen könnte mal ne Warnung abzusetzten wenn da was nicht stimmt. Aber nee der Dreck wird überstetzt und man sicht sich einen Ast ab. Ganz abgesehen von den anderen Fehlern. Vielleicht sollten sich die GCC-Leute ja mal von AVR einen Baustein machen lassen mit dem der Compiler besser umgehen kann. Das ganze hat die Firma Keil schon seit mindestens 25-Jahren im Griff.
Rufus Τ. Firefly schrieb: > Das ist natürlich kompletter Schwachsinn. Das liegt nicht am gcc, > sondern an der für C-Programmierung ungeeigneten Harvard-Architektur der > AVRs. Wäre jetzt aber ein weiterer Punkt, bei GCC ist wohl von Neumann Hauptentwicklungszweig. Ich kann jetzt allerdings nicht bewerten, an welchen Stellen dies beim Compilerbau zu ungünstigen Desigentscheidungen führt, wenn der Compiler dann für Harvard arbeiten soll.
Das Problem ist hierbei, daß der Compiler "smarte Pointer" verwenden muss, die nicht nur die Adresse, sondern auch die Art des adressierten Speichers speichern. Was bei jeder Dereferenzierung des Pointers zusätzlichen Code zur Folge hat, denn es muss ja in Abhängigkeit des Speichers, auf den der Pointer zeigt, unterschiedlich vorgegangen werden. Die Folge ist nicht nur zusätzlicher Code, sondern natürlich auch zusätzlicher Speicherbedarf, weil ein Pointer eben nicht mehr nur zwei*, sondern drei Bytes groß ist (Adresse + Speicherart). Damit werden Programme nicht nur langsamer, sondern benötigen auch mehr Speicher. Das Hardwaredesign der AVRs hätte natürlich auch vorsehen können, daß die (physikalisch getrennten) Adressräume unterschiedliche Adressen verwenden, daß also Adressen im Flash-ROM und Adressen im RAM nicht überlappen, dann aber hätte schon früher eine Erweiterung auf insgesamt größere Adressen stattfinden müssen (der Mega128 hat bereits mehr als 64 kiB Flash-ROM, und kann bis zu 64 kiB RAM ansteuern). Bei kleineren AVRs mit insgesamt nicht mehr als 64 kiB Adressraum wäre aber so ein einfacheres Adressierungsmodell möglich, ohne die Harvard-Architektur komplett aufgeben zu müssen. Bei jedem größeren AVR wäre dann aber ein neues Rechnermodell mit größeren Adressen erforderlich, was neben anderer Codeerzeugung auch gewisse Performancenachteile mit sich brächte; diese wären aber geringer als die einer reinen Softwarelösung. Am einfachsten entkommt man natürlich dem Dilemma, in dem man nur auf von-Neumann-Hardware programmiert. *) ich gehe hier mal von den üblichen 8-Bit-Architekturen wie dem AVR aus.
Rufus Τ. Firefly schrieb: > Das Problem ist hierbei, daß der Compiler "smarte Pointer" verwenden > muss, die nicht nur die Adresse, sondern auch die Art des adressierten > Speichers speichern. Was bei jeder Dereferenzierung des Pointers > zusätzlichen Code zur Folge hat, denn es muss ja in Abhängigkeit des > Speichers, auf den der Pointer zeigt, unterschiedlich vorgegangen > werden. Klar kann man auch nicht dem GCC vorwerfen, falls das so angekommen sein sollte. > Am einfachsten entkommt man natürlich dem Dilemma, in dem man nur auf > von-Neumann-Hardware programmiert. Ja das hiesse natürlich, die MCUs wechseln. Aber rein wenn ich mir das restlich Design anschaue, dann gefallen die AVRs immer noch am besten. Die Fälle in denen ich massiv Daten aus dem Programmspeicher lese, dominieren aus meiner Sicht nicht die Problemstellungen für welche ich einen AVR einsetzen würde. Anonsten MSP430, 8051er von Atmel mit "erweiterter" Harvard Architektur etc. Auswahl ist ja gegeben. ;-)
@wrdsdsd Du hast vermutlich nicht mal die geringste Ahnung davon, wie lächerlich der Mist ist, den du hier erzählst. Du bist der typische DAU - nur benutzen, nicht verstehen.
Rufus Τ. Firefly schrieb: > Am einfachsten entkommt man natürlich dem Dilemma, in dem man nur auf > von-Neumann-Hardware programmiert. Am einfachsten - d’accord! Auf den GCC bezogen bedeutet das dann (den Worten folgendes, konsequentes handeln vorrausgesetzt): Schmeiß' den Kuckuck aus dem Nest, falls er Harvard heißt? ;-) Wäre es da nicht deutlich eleganter eine Option einzubauen, dem Compiler mitzuteilen, was der Entwickler bevorzugt, anstatt über die Struktur der Zielhardware zu jammern? Entweder hochoptimierten Code, oder gerne auch ein Byte mehr für smarte Pointer, die es dann dem Compiler viel leichter möglich machen, eine korrekte Adressierung zu gewährleisten und zu erkennen - oder sich ggf. per Warnung oder Fehler Gehör beim Entwickler zu verschaffen. Übersichtlicheren Code ohne das bereits angesprochene "_P-Gedöns" gäbe es zusätzlich kostenfrei in diesem Paket. An nicht wenigen Stellen, zum Beispiel dem Füllen einer GUI mit Inhalt, dürften Datenzugriffe in Hochsprache dann viel weniger von Harvard/Neumann-Unterschieden belastet sein, während die Performance des Gesamtsystems an dieser Stelle heutzutage ohnehin weniger von der Maschine, als viel mehr von der Fingerfertigkeit des Bedienenden abhängt. MfG
@Jan S. Bist Du jetzt schlauer geworden? Ich denke nicht. Wo ist denn konkret Dein Problem? Reicht Dir kein Compiler, der schon ein paar Tage alt ist? Bei einem AVR ist das kein Problem, da hat sich doch nicht viel getan. (Für einen 8051 kann man auch einen älteren Keil Compiler nehmen.) Irgendwann gab es mal die Erweiterungen mit MUL Befehlen, das ist doch aber auch schon fast zehn Jahre her. Mein Tipp, wenn Du kostengünstig arbeiten willst: versuche eine ältere IAR Version für AVR 'gebraucht' zu bekommen. Die gab es noch ohne vorgefertigte .lib. Somit war der Quelltext mit im Lieferumfang und auch für andere Anwendungen sehr hilfreich. Ganz elegant konnte man sich damit eigene printf_xyz() erzeugen. Der Code - auch mit float - war (ist) sehr kompakt. Fix-point Rechnerei braucht man nicht! Und wie PeDa geschrieben hat, gibt es die Option mit 64Bit double zu arbeiten: kompakter und schneller Code. Aktuell arbeite ich mir einer 2.2x Version, die mich nichts vermissen läßt. Deshalb habe ich mich auch nie mit GCCAVR näher auseinandergesetzt. Seinerzeit (vor 10 Jahren?) hatte ich Codevision getestet und Imagecraft. Die waren aus div. Gründen sehr unbefriedigend. IAR hat seinerzeit (heute wohl auch noch) jährliche Wartungsverträge für einiges Geld angeboten. Auf Behebung gemeldeter Fehler konnte man daher (teilweise lange) warten. Das lohnt alles nicht. Das ist meine "landläufige" Meinung.
Freund von GCC und AVR schrieb im Beitrag #2055412: > Wäre es da nicht deutlich eleganter eine Option einzubauen, dem Compiler > mitzuteilen, was der Entwickler bevorzugt, anstatt über die Struktur der > Zielhardware zu jammern? Das wäre ganz erheblicher Aufwand. Bedenke, daß der gcc in erster Linie ein Compiler für 32-Bit- oder noch größere Systeme ist, den einige Leute mit viel Aufwand so weit aufgebohrt haben, daß er auch brauchbaren Code für 8-Bit-Architekturen wie den AVR erzeugen kann. Das jetzt noch um "smart pointer" zu erweitern ist sicherlich möglich, allerdings bezweifle ich, daß diejenigen, die so viel know-how haben, daß sie es könnten, die Erfordernis dafür sehen oder sich gar die Zeit nehmen, es zu tun. Außerdem jammern diese Leute nicht über die Struktur der Zielhardware, sondern sie nutzen sie, mit den Einschränkungen, die sie einem halt auferlegt. Denn es geht ja, wenn man sich dazu herablässt, sich damit auseinanderzusetzen. Was aber Zeitgenossen mit dieser Erwartungshaltung > Das interessiert mich überhaupt nicht. Der Prozessor ist wie > er ist, dafür benötige ich ein Tool. Ob der eine Harvard- > oder eine Wurzelsepp-Architektur hat ist mir egal. > Ich will mich darum nicht kümmern müssen. sich ganz offensichtlich weigern zu tun.
sffdfdf schrieb im Beitrag #2055639: > Da zu muß ich jetzt mal was sagen: > > Wenn ich so ein Produkt auf die Menschheit loslasse dann muss ich bitte > den Ergeiz haben was ordentliches zu machen oder ich lasse es. Zuersteinmal muss es vor allem eines erfüllen: meine Anforderungen. Die Anforderungen und Vorlieben anderer sind mir dabei erstmal ziemlich egal. Und wenn sich dann Leute finden, die das auch gebrauchen können - wunderbar! Dann freue ich mich. > Ich hab es ausprobiert, es ist ne Krücke, fertig. Du meinst das - ist ja ok. Andere (wir z.B.) nutzen den GCC (nicht nur auf AVRs) und es gab da nie Probleme. > Wir sind eines freies Land, wer will kann > den Mist benutzen. Ich hab halt Geld in die Hand genommen und mir was > gescheites gekauft. Formulieren wir das einfach um: Du kommst damit nicht zurecht und die unterschiedlichen Pointerarten stören Dich und hast dann etwas anderes genommen. Ist doch ok. > Es ist ja nicht nur der Unterschied zwischen Ram und Flash, fürs EEprom > gibt es ja ähnliches. Wie kann man auf die Schnapsidee kommen das so zu > lösen? Wo ist denn bei der EEPROM-Addressierung das Problem? Da habe ich mir vor Jahren eine passende Bibliothek mit ein paar Funktionen gebastelt - fertig. Ich verstehe auch nicht wirklich, wo bei einem printf_P das Problem liegt. Man liest sich das einmal in der avrlibc-Doku durch, denkt "Aha, ok, deshalb" und setzt das dann entsprechend ein. > "Smartpointer" gibt es bei Keil schon seit 25 Jahren. Ist halt ein Byte > mehr, naund? Das würde mich z.B. stören. Speicherplatz und Geschwindigkeit sind gerade im AVR-Bereich nicht wirklich "üppig" vorhanden. Da denke ich beim Programmieren lieber etwas schärfer nach :-) Ansonsten hat hier der GCC immer schon das getan, was er sollte. Das Geld stecke ich lieber in die Produktentwicklung. Chris D.
Als neugieriger Mensch habe ich gerade die aktuelle Demoversion von CodeVision 2.05 installiert und mit einem vorhandenen Programm getestet. Der IAR-Compiler erzeugt für einen Tiny2313 eine Hex-Datei mit 1860 Byte. CodeVision ist trotz aller Optimierungen nicht in der Lage mit dem Flash des 2313 (2kb) auszukommen. Ein Umstellung auf ATmega48 klappt auch nicht, da auch die max. 3kb Code der Demoversion zu wenig sind. Also wieder weg mit dem Zeug!
sffdfdf schrieb im Beitrag #2055639: > Wenn ich so ein Produkt auf die Menschheit loslasse dann muss ich bitte > den Ergeiz haben was ordentliches zu machen oder ich lasse es. Tja, wenn es Dich überfordert, für einen µC passende Programme zu schreiben, und Du erwartest, daß der Compiler Dir die Arbeit und das Denken abnimmt, dann sind µCs vielleicht doch nicht das richtige für Dich, auch wenn Du behauptest, damit schon so lange zu hantieren. Gcc ist ein ordentlicher Compiler, und die AVR-Unterstützung ist auch ordentlich, sie ist lediglich nicht sehr anfänger- und einsteigerfreundlich. Aber das ist auch C selbst nicht, und das Thema µC ist auch nicht sehr anfänger- und einsteigerfreundlich, und die AVRs im Speziellen haben auch noch die eine oder andere Problemzone, die Anfänger und Einsteiger auf die Bretter werfen kann. Wie aber die in diesem Forum unterwegs seienden Leute (und noch viel mehr) tagtäglich beweisen, ist das zu schaffen. Wer aber über die elementaren Grundprobleme des Programmierens in C hinausgekommen ist, der sollte in der Lage sein, die erforderlichen Dinge zu beachten, um mit so einer Krücke wie den AVRs zu arbeiten. Wenn er das nicht kann, bitte, soll er halt Geld ausgeben um einen Compiler zu kaufen, der "halt ein Byte mehr" verwendet und damit langsameren und ineffizienteren Code produziert. Oder den Arsch hochbekommen und den avrgcc entsprechend erweitern. Geht ja alles, ist ja OSS.
IAR schrieb: > Als neugieriger Mensch habe ich gerade die aktuelle Demoversion von > CodeVision 2.05 installiert und mit einem vorhandenen Programm getestet. > > Der IAR-Compiler erzeugt für einen Tiny2313 eine Hex-Datei mit 1860 > Byte. CodeVision ist trotz aller Optimierungen nicht in der Lage mit dem > Flash des 2313 (2kb) auszukommen. > Ein Umstellung auf ATmega48 klappt auch nicht, da auch die max. 3kb Code > der Demoversion zu wenig sind. Also wieder weg mit dem Zeug! So, und jetzt bitte noch GCC
moderator schrieb im Beitrag #2055837: > Rufus Τ. Firefly schrieb: >> Tja, wenn es Dich überfordert, für einen µC passende Programme zu >> schreiben, und Du erwartest, daß der Compiler Dir die Arbeit und das >> Denken abnimmt, dann sind µCs vielleicht doch nicht das richtige für >> Dich, auch wenn Du behauptest, damit schon so lange zu hantieren. > > > absolut dummes geschwätz Ich stimme Rufus zu. Dein massiver Spam (21 Beiträge mit dem gleichen Text) stellt deine Inkompetenz genug zur Schau.
Rufus Τ. Firefly schrieb: > Bei kleineren AVRs mit insgesamt nicht mehr als 64 kiB Adressraum wäre > aber so ein einfacheres Adressierungsmodell möglich, ohne die > Harvard-Architektur komplett aufgeben zu müssen. Das ist unabhängig von der Menge an Flash möglich, sofern nicht mehr als beispielsweise 32kiB RAM implementiert sind. Also bei allen existierenden AVRs, bei denen der externe Bus nicht vorhanden ist oder nicht entsprechend verwendet wird. Denn dann könnte man die zweite Hälfte des Datenadressraums auf eine feste oder variable ROM-Stelle mappen und wäre mit fast allen konstanten Daten bedient. Wer hat schon mehr als 32kiB davon? Nur für riesige Tabellen wäre eine Krücke wie pgm_read_far noch erforderlich, und damit könnte man leben. Genau das hat nämlich Microchip bei den PIC30 implementiert. Die sind zwar sonst nicht grad für gute Architekturen berühmt geworden (was evtl. zur der weisen Einsicht führte, es bei 32 Bits nicht erst zu probieren), aber diese Idee gefällt mir. Natürlich hat das einen kleinen Pferdefuss: Datenzugriffe aufs ROM sind bei diesem Verfahren einen Takt langsamer als normale Datenzugriffe, was den Core und dessen Ablaufsteuerung etwas verkompliziert. Dass Atmel das nicht nachträglich in den alten Core einbaute kann ich daher nachvollziehen. Dass sie es aber auch beim AvrX nicht getan haben hat diesen für mich aus dem Rennen geworfen.
IAR schrieb: > Als neugieriger Mensch habe ich gerade die aktuelle Demoversion von > CodeVision 2.05 installiert und mit einem vorhandenen Programm getestet. Super, gute Idee! Kannst Du noch ein paar Infos zum verwendeten Programm geben? Z.B. ob dort Fixkomma oder Fliesskomma Arithmetik oder ähnliches verwendet wird? Dies scheinen mir ja Bereiche zu sein, in denen sich die Spreu vom Weizen trennt. IAR schrieb: > Der IAR-Compiler erzeugt für einen Tiny2313 eine Hex-Datei mit 1860 > Byte. CodeVision ist trotz aller Optimierungen nicht in der Lage mit dem > Flash des 2313 (2kb) auszukommen. > Ein Umstellung auf ATmega48 klappt auch nicht, da auch die max. 3kb Code > der Demoversion zu wenig sind. Also wieder weg mit dem Zeug! Das ist ein deutlicher Unterschied, in der Tat.
Jan S. schrieb: > IAR schrieb: >> Als neugieriger Mensch habe ich gerade die aktuelle Demoversion von >> CodeVision 2.05 installiert und mit einem vorhandenen Programm getestet. > Super, gute Idee! Kannst Du noch ein paar Infos zum verwendeten Programm > geben? > Z.B. ob dort Fixkomma oder Fliesskomma Arithmetik oder ähnliches > verwendet wird? Dies scheinen mir ja Bereiche zu sein, in denen sich die > Spreu vom Weizen trennt. In dem Zusammenhang ist auch immer gut zu wissen, welchem Standard gefolgt wird. Es gibt ja einiges am IEEE, was auf AVR zu länglichem Code führt. Wenn eine Fließkomma-Lib sich aus Effizienzgründen die IEEE nicht komplett implementier, spielt sie in einer anderen Liga wie eine IEEE-konforme. Zeit- und Codedichtmessungen sind da u.U. nicht direkt vergleichbar. Veröffentlichen Compiler-Hersteller eigentlich auch ihre Errata? Also sowas wie die Buglisten von GCC? Software wie Compiler sind aufgrung ihrer Komplexität fast zwangsläufig mit Errata behaftet, die in unterschiedlichen Versionen zum Tragen kommen. Wenn die Fehler schon nicht zeitnah behoben werden: Werden sie dann wenigstens bekanntgemacht?
>So, und jetzt bitte noch GCC Das hatte ich vor längerer Zeit mal gemacht; das Programm paßte in den 2313. Beim Probieren mit CodeVision ist mir wieder Einiges unangenhem aufgefallen. Zum Beispiel werden im Listing erst endlos viele Makros definiert. Bevor ich dann MEINEN Code sehe nervt das jedesmal. Dann werden die Register und INT-Vectoren anders bezeichnet als im Datenblatt des jeweiligen AVR; auch das ist lästig. Aber, wer ein bißchen Spielen will, kann sich die Demoversion installieren. Es gibt einige Funktionen zum Ansprechen von PCF8583 (nicht beider Demo dabei), LCD, FATxyz, .... Für einen Anfänger ganz nett - ich schreibe mir lieber meine eigenen Routinen. Dann habe ich hier AVRstudio 4.18, aber nur testweise mit dem Dragon benutzt. Wem das gefällt - kostet halt nichts. Wenn ich nichts anderes hätte, würde ich auch damit arbeiten. Und noch etwas zu IAR. Auch da tauchen ab und zu Probleme auf, die aber für mich kein Grund sind, eine nagelneue Version zu kaufen. Ich weiß nicht, wie weit GCC jetzt ist; schon mit recht frühen Versionen des IAR konnte man Register beim Compilieren reservieren, die dann nicht woanders verwendet wurden. Das ist ideal für schnelle Interruptroutinen mit statischen Registern. Aber ein wenig Erfahrung braucht man dafür schon. Falls ich mal XMEGAs in die Finger bekomme, wird die alte Version vermutlich auch noch reichen. Wenn man sich ab und zu eine Demo-CD besorgt, hat man automatisch die .h-Dateien und Linkerskripte für neuere Prozessoren dabei, und die Fehler in den alten sind behoben ;-) >Super, gute Idee! Kannst Du noch ein paar Infos zum verwendeten Programm >geben? Ich denke, Du solltest Informationen geben.
Was willst Du machen? Geht es Dir nur darum, die allerneueste Version Dein Eigen zu nennen? Dafür wäre mir meine Zeit zu schade.
IAR schrieb: > Ich weiß nicht, wie weit GCC jetzt ist; schon mit recht frühen > Versionen des IAR > konnte man Register beim Compilieren reservieren, die dann nicht > woanders verwendet wurden. Das ist ideal für schnelle Interruptroutinen > mit statischen Registern. Aber ein wenig Erfahrung braucht man dafür > schon. Wenn Du damit meinst, dass man Register fest bestimmten Variablen zuordnen kann - das zumindest geht schon geraume Zeit. Machen wir hier öfter in schnellen ISRs. Es wäre mal ein echter Vergleich der Kompilate der verschiedenen Compiler interessant: Größe, Laufzeiten Dazu eine Übersicht der Stärken und Schwächen. Chris D.
Chris D. schrieb: > IAR schrieb: >> Ich weiß nicht, wie weit GCC jetzt ist; schon mit recht frühen >> Versionen des IAR >> konnte man Register beim Compilieren reservieren, die dann nicht >> woanders verwendet wurden. Das ist ideal für schnelle Interruptroutinen >> mit statischen Registern. Aber ein wenig Erfahrung braucht man dafür >> schon. > > > Chris D. Habe ich auch schon mit dem GCC gemacht. Oder sollte man hier eher sagen "verbrochen"... Sowas ist nämlich echt kein guter Stil und solche "Optimierungen" sind meist Hinweise auf eine schlechte Architektur.
Hallo, ich setze beruflich für die AVRs auch den CodeVision ein und bin damit sehr zufrieden. Vorteile: -Zuverlässig und ausgereift (noch keine großen Bugs erlebt) -Falls mal ein Bug festgestellt wurde, wurde dieser i.d.R. sehr rasch behoben -Sehr gute IDE -Praktischer CodeWIzard (ideal um schnell mal etwas auszuprobieren) -Günstig Nachteile: -Lässt diverse "nicht ANSI C Schweinereien" zu ;-) -Codegroße der erzeugten Programme größer im Vergleich zum IAR Arbeite regelmäßig auch mit dem Keil-Compiler (ARM und 8051 Derivate) und stelle fest, dass der CodeVision den Vergleich (auch wenn andere Plattform) wirklich nicht scheuen muss. Gruß, Sebastian.
IAR schrieb: > Geht es Dir nur darum, die allerneueste Version Dein Eigen zu nennen? Wie kommst du denn darauf? Ich habe derzeit überhaupt keinen kommerziellen Compiler im Einsatz. Aber nach dieser Frage verstehe ich einige deiner Posts besser, Du bist offensichtlich davon ausgegangen, dass ich einen neuen Compiler suche? Dem ist nicht so, da ich keinen kommerziellen Compiler besitze.
Codegröße ist zweifellos ein Primär-Kriterium; aber wenn ich sehe, dass ein Tiny88 nur unwesentlich mehr kostet als ein Tiny44, kann ich mit ein paar Bytes mehr gut leben. Zumal wir eh' gern noch etwas "Reserve" haben, falls sich die Anforderungen an die Funktionalität im Laufe des Produktzykluses ändern. Bei den meisten unserer Produkte sind die paar Cent den Stress der Platzoptimierungen um jeden Preis nicht wert. Was mir am Codevision gefällt, ist die Bit-Adressierung ohne die Bitschiebereien, die mir GCC aufzwingt und die ich irgendwie nicht mit meiner Denkweise abgleichen kann. Dafür bietet GCC den nicht unerheblichen Vorteil, ihn überall und so oft zu installieren wie ich möchte. Speziell die an eine Maschine gebundene Lizenz hat mich bisher davon abgehalten, CodeVision zu kaufen - so sehr ich die o.g. Adressierungsart im GCC auch vermisse.
coldtobi schrieb: > Chris D. schrieb: >> IAR schrieb: >>> Ich weiß nicht, wie weit GCC jetzt ist; schon mit recht frühen >>> Versionen des IAR >>> konnte man Register beim Compilieren reservieren, die dann nicht >>> woanders verwendet wurden. Das ist ideal für schnelle Interruptroutinen >>> mit statischen Registern. Aber ein wenig Erfahrung braucht man dafür >>> schon. > > Habe ich auch schon mit dem GCC gemacht. Oder sollte man hier eher sagen > "verbrochen"... Sowas ist nämlich echt kein guter Stil Das macht man ja nicht ständig sondern wirklich nur in echten Ausnahmefällen und sehr gezielt. Ganz ehrlich: ich habe schon so viele Stile gesehen - und jeder meint, er hätte einen guten. Wir nehmen hier den Stil, der die Probleme unserer Kunden löst - so einfach ist das. > und solche "Optimierungen" sind meist Hinweise auf eine schlechte > Architektur. Jede Architektur hat ihre Vor- und Nachteile. Wir werden sicher nicht die Controllerfamilie wechseln, nur weil sie irgendwo Nachteile hat. Dann wären wir nämlich nur am Wechseln :-) Chris D.
Stefan --- schrieb: > Was mir am Codevision gefällt, ist die Bit-Adressierung ohne die > Bitschiebereien, die mir GCC aufzwingt und die ich irgendwie nicht mit > meiner Denkweise abgleichen kann. Wie ist das denn gelöst? Kannst Du dafür ein Beispiel geben? > Dafür bietet GCC den nicht unerheblichen Vorteil, ihn überall und so oft > zu installieren wie ich möchte. Speziell die an eine Maschine gebundene > Lizenz hat mich bisher davon abgehalten, CodeVision zu kaufen - so sehr > ich die o.g. Adressierungsart im GCC auch vermisse. Ja, schon das wäre hier Ausschlusskriterium. Eine fehlende Linuxversion ebenso. Chris D.
Ich habe mir nun nicht die komplette Posts gelesen, nur überflogen. Ich arbeite schon seeeehr lange mit MicroC Pro AVR von Mikroelektronika. Ganz ehrlich! In Verbindung mit einem Dev-Board / Programmer von MikroE ist das Ding absolutes Gold wert! Es gibt für jeden Compiler eine Demo die auf jeden Fall einen Blick wert ist. Ich würde die Paar-Mark-Fünfzig jederzeit wieder ausgeben!
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.