mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Kommerzieller AVR C Compiler


Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: IAR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!)

Autor: Atmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: cskulkw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Seltsam (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Qwertz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GoodOldEquipment (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bevor das hier ausufert: Es geht mir nicht um eine Haftungsübernahme, 
das hat irgendwer in den Raum geworfen...

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werde ab sofort nur noch auf Posts eingehen, welche 
"Erfahrungsberichte" und somit für eine Einschätzung nützliche 
Information enthalten.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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". ;-)

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Micha S. (ernie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: o.O (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Hermann (dr_coolgood)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mir vor ca. 2 Jahren auf Kundenwunsch hin wegen Kompatibilität 
Codevision angeschafft. Funktioniert wunderbar, und günstig ist es auch.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: wrdsdsd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: wrdsdsd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: GIF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Freund von GCC und AVR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: IAR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: IAR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: donbit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum kein Assembler?
Oder Forth wenn's portierbar sein soll?

Autor: Robert B. (robertb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nico Sch. (nico22)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: IAR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IAR schrieb:
> Ich denke, Du solltest Informationen geben.
Wie habe ich das denn zu verstehen?

Autor: IAR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: coldtobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastion S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan --- (xin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene K. (draconix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.