In der aktuellen "Markt&Technik", S. 17, gibt es den Artikel "Wer viel Zeit und wenig Geld hat, ... der kann sich eien GNU-Compiler von der GNU.org-Webseite herunterladen - allen anderen bleibt dieser Weg aber wohl verschlossen.". Und es geht weiter u. A. mit "Wenn ein Entwickler den GNU-Compiler von der GNU.org-Webseite herunter lädt, dann erhält er ein Sammelsurium von Dateien. Daraus einen lauffähigen Compiler zu erzeugen, ist zwar möglich, aber sehr zeitintensiv." Angeblich hat der Herr Keil dies selber versucht. Das ist reinste Propaganda, denn mit einer der üblichen Anleitungen hat man den Compiler in wenigen Minuten fertig.
Hast Du schon mal versucht eine Entwicklungsumgebung von NULL Ahnung beginnend für den STM32 mit Eclipse, Yagarto und Codesourdery sowie Debuggen mit OpenOCD und Likerfile/Makefile zum laufen zu bekommen ??? Na dann viel Spass. Ich nutze diese GNU Umgebung und ich weiß wovon ich spreche. Wenn das ein Chef einer Firma bezahlen müsste, dann hätte der Aufbau dieser GNU Umgebung ca. 8000 EUR Manpower gekostet! Ich habe daraus den Artikel STM32 geschrieben, darin steht wie es geht, samt Demo Projekt und vielen anderen Tipps. Und davor hat wohl Herr Keil angst...
Gast
#1899577
GNU-Quelltexte sind jetzt wirklich nicht die aufgeräumtesten und übersichtlichsten, das habe ich auch schon festgestellt. Bisher hatte ich aber wenig Probleme, GNU-Zeug zu übersetzen, sei es ein vollständiger GCC inklusive binutils usw., seien es andre, kleinere Tools. Und das scheint abertausenden von anderen Benutzern ebenso zu gehen. Wenn jetzt ausgerechnet Herr Keil das nicht auf die Reihe bekommt, würde ich nicht unbedingt bei GNU anfangen, einen Fehler zu suchen... Vor einer solchen Vielfalt von Plattformen, für die der GCC heute kompiliert und optimiert, würde mir als kommerzieller Compiler-Architekt auch der Hintern auf Grundeis gehen. Vermutlich hat er wieder mal probiert, den GCC im Quellenstamm zu bauen, obwohl davon ausdrücklich abgeraten wird...
Markus Müller schrieb: > Hast Du schon mal versucht eine Entwicklungsumgebung von NULL Ahnung > beginnend für den STM32 mit Eclipse, Yagarto und Codesourdery sowie > Debuggen mit OpenOCD und Likerfile/Makefile zum laufen zu bekommen ??? > > Na dann viel Spass. Also ich weiß ja nicht auf welchem rückständigen System du arbeitest, aber unter Debian ist es eine Sache von ein paar "aptitude install" Kommandos um die gewünschten Programme zu installieren.
Gast
#1899744
Das Problem ist nicht, die Programme zu installieren. So fern es Tutorials gibt, an denen man sich orientieren kann, geht das relativ schnell. Schwierig wird es allerdings, wenn es für den uC kein explizites Turorial gibt. Da muss man viel ausprobieren und sich sehr tief einarbeiten. Wenn man etwas lernen will ist das super, wenn man einfach ein schnelles Ergebnis haben will nicht. Die Zeiten, in denen man mit vi Code schreibt und irgend wie auf den uC bringen will sind glücklicherweise vorbei. Mit einer ordentlichen IDE, JTAG & Co. lässt sich wesentlich angenehmer, schneller und damit billiger entwickeln. Es ist billiger, einen Compiler für Geld zu kaufen, wenn man sich damit viel Mühe und Zeit sparen kann. Schau dir Crossworks an. Alles was deren IDE kann, lässt sich auch mit reinen GNU Programmen aufbauen (Wenig verwunderlich, da intern der gcc verwendet wird). Der Aufwand bis alles einwandfrei läuft ist teils sehr groß. Bei Crossworks, wie auch bei anderen kommerziellen Compilern muss man einfach nur den Controller auswählen und hat schon einen Codebasis zum loslegen die dann auch wirklich funktioniert. So gerne ich auch mit gcc arbeite, der Compiler ist ein Sammelsurium. GCC, Binutils, GDB, Newlib, (OpenOCD, Eclipse, ....). Je nach Fall ist einiges an Handarbeit nötig bis alles zufriedenstellen läuft. Distributoren nehmen einen zwar in den meisten Fällen die Arbeit ab, wenns aber klemmt, wirds schnell unangenehm.
>Propaganda
Das Wort Propaganda sagt schon alles wenn man die Bedeutung kennt.
-- Falschinformation aus EINER Quelle --
Muss man dazu aus dem Osten kommen ?
Gast
#1899790
Hm, im Duden steht aber etwas ganz anders, Wikipedia auch? Propagande muss keine Falschinformation sein, auch nicht aus einer einzelnen Quelle.
Ehe ihr Helden euch hier weiter die Mäuler über gcc zerreißt, seht doch mal nach, was unter der Oberfläche des AVR-Studios läuft...
Huui, wooow! Da ist einer aber ganz früh aufgestanden! Du hast doch noch nie den Quellhaufen eines gcc gesehen...
Gast
#1899842
@Uhu: Wie du schin schreibst: Unter der Haube. Man könnte deine Aussage also so auffassen, dass GCC direkt nicht nutzbar ist.
Tilo Lutz schrieb: > Man könnte deine Aussage also so auffassen, dass GCC direkt nicht > nutzbar ist. Habe ich was ausgesagt, außer daß ihr Helden seid?
Gast
#1899885
Sorry, ich vergaß, wem ich antwortete.
Michael H. schrieb: > Huui, wooow! Da ist einer aber ganz früh aufgestanden! > > Du hast doch noch nie den Quellhaufen eines gcc gesehen... Was hat das damit zu tun? Ich find's halt auch schade dass es keine guten Distros gibt und dass z.B. sowas wie WINAVR nur unter Windows gepflegt wird. Bleibt einem nur das selber uebersetzen (und patchen!), was in diesem Fall aber recht locker und problemlos geht, dank build script. Dass das nicht unbedingt was fuer den unbedarften Laien ist, sollte klar sein, vor allem wenn mal was nicht auf Anhieb klappt. Michael
An dieser Stelle sei bemerkt, dass VIELE kommerzielle Entwicklungsumgebungen, inklusive Xcode von Apple auf GCC basieren. Das ist für mich alleine schon ein Qualitätszeugnis
Viktor Chmelnitzki schrieb: > An dieser Stelle sei bemerkt, dass VIELE kommerzielle > Entwicklungsumgebungen, inklusive Xcode von Apple auf GCC basieren. Noch; Apple wird in der nächsten Version (XCode 4) nur noch das Frontend von GCC benutzen, das Backend wird defaultmäßig LLVM sein (bis CLang soweit ist GCC komplett ablösen zu können, was hauptsächlich noch an C++ hängt). Die GNU-Infrastruktur (GCC, GDB usw.) ist ordentlich veraltet, das muss man schon zugeben, auch wenn die Ergebnisse des Compilers nicht schlecht sind.
Gast
#1899992
Viktor Chmelnitzki schrieb: > An dieser Stelle sei bemerkt, dass VIELE kommerzielle > Entwicklungsumgebungen, inklusive Xcode von Apple auf GCC basieren. Das > ist für mich alleine schon ein Qualitätszeugnis Seit wann ist Verbreitung ein Qualitaetszeugnis?
>Seit wann ist Verbreitung ein Qualitaetszeugnis?
Soviele Fliegen koennen sich nicht irren ...
:-)
Erwin Meyer schrieb: > Das ist reinste Propaganda, denn mit einer der üblichen Anleitungen hat > man den Compiler in wenigen Minuten fertig. Es mag ja sein, daß für Dich das alle Pillepalle ist, aber viele andere können es nicht. Nicht jeder ist ein Linux-Experte. Ich kann mich noch gut erinnern, als ich das erste mal versuchte, den AVR-GCC/Cygwin zu installieren. Nach mehreren Tagen habe ich entnervt aufgegeben und alles wieder von der Platte geputzt. Erst als jemand so freundlich war, den WINAVR zu entwickeln, konnte auch ich den AVR-GCC benutzen. Ich kann mir daher gut vorstellen, daß es für viele andere Targets keinen für Nichtexperten erfolgreich zu installierenden GCC gibt. Peter
Peter Dannegger schrieb: > Nach mehreren Tagen habe ich entnervt aufgegeben und alles wieder von > der Platte geputzt. Das ist leider ein weit verbreitetes Problem in der OpenSource-Szene. Die Jungs schreiben tolle Software, aber schaffen es nur zu oft nicht, eine Beschreibung zu bauen, die nur halbwegs brauchbar ist - sofern sie überhaupt was verfassen, was den Namen verdient. Das gilt übrigens auch für vieles, was hier veröffentlicht wird. Im Übrigen kann sich das Compilat von gcc durchaus mit dem kommerzieller Compiler messen. Visual C++ ist jedenfalls nicht besser.
Uhu Uhuhu schrieb: > Im Übrigen kann sich das Compilat von gcc durchaus mit dem kommerzieller > Compiler messen. Visual C++ ist jedenfalls nicht besser. Wenn Du damit VC6 meinst, ja. Die neueren Compiler (beginnend mit VC2003) aber haben gcc hinter sich gelassen; vor einigen Jahren gab es mal einen ernstzunehmenden Vergleichstest im DDJ (kann im Moment keine genauere Quellenangabe machen, verglichen wurden u.a. Watcom- und Intel-Compiler, und vom Intel-Compiler abgesehen war der von MS, wenn ich mich recht erinnere, in den meisten Disziplinen überlegen).
Für Windows/Linux-Programmierung nimmt man auch kein GCC sondern Lazarus/Freepascal. Damit ist der Code relativ leicht portierbar. Siehe hier, eine ordentliche Lagerverwaltung mit Doku: Beitrag "Re: Elektronik Lager und die vielen Kisten (Verwaltung)"
Markus Müller schrieb: > Für Windows/Linux-Programmierung nimmt man auch kein GCC sondern > Lazarus/Freepascal. So, so... Compilier doch mal den Linux-Kernel damit, oder nur eines der vielen tausend Programme, die auf allen möglichen Plattformen laufen und in C/C++ geschrieben sind.
Uhu Uhuhu schrieb: > Markus Müller schrieb: >> Für Windows/Linux-Programmierung nimmt man auch kein GCC sondern >> Lazarus/Freepascal. > > So, so... > > Compilier doch mal den Linux-Kernel damit, oder nur eines der vielen > tausend Programme, die auf allen möglichen Plattformen laufen und in > C/C++ geschrieben sind. So, so... Dann schreib doch mal ein Windows C/C++ Programm und kompillere es mal unter/für Linux.
Markus Müller schrieb: > Dann schreib doch mal ein Windows C/C++ Programm und kompillere es mal > unter/für Linux. libwine?
Markus Müller schrieb: > Dann schreib doch mal ein Windows C/C++ Programm und kompillere es mal > unter/für Linux. Das geht nur deswegen nicht, weil Microsoft sich an keinerlei Standards gehalten hat. Das fängt schon beim Backslash als Pfadtrenner an, der die einzige echte Innovation ist, die M$ überhaupt je zustande gekriegt hat ;-)
Markus Müller schrieb: > Dann schreib doch mal ein Windows C/C++ Programm und kompillere es mal > unter/für Linux. Versuch es zb mal mit dem QT Framework... Das ist IMHO plattformunabhängig, sodass du deinen Code nur neu kompilieren musst ohne große #ifdef WIN oder #ifdef UNIX Geschichten. Das Framework versteckt die ganzen Unterschiede.
Markus Müller schrieb: > Für Windows/Linux-Programmierung nimmt man auch kein GCC sondern > Lazarus/Freepascal. Wenn du den Ball ins 9er Loch bekommen willst, nimmt man doch keinen Golfschläger, sondern ein Katapult.
Mit crosstool-NG http://ymorin.is-a-geek.org/projects/crosstool habe ich mir schon eine Menge verschiedene gcc Cross-Compiler für verschiedene Architekturen gebaut. Stand-alone mit und ohne C-Library oder für Linux. crosstool-NG bietet ein ähnliches Konfigurations-Interface wie der Linuxkernel ("make menuconfig") und automatisiert das Patchen und Bauen einer kompletten GNU Toolchain. Das ist nicht komplizierter und dauert nicht länger, als sich einen kommerziellen C-Compiler in einem Online-Shop zu kaufen, herunterzuladen und zu installieren. Meine Erfolgsquote mit diesem Script war bisher 100%. Hier die Liste der unterstützten Architekturen: Alpha, ARM, AVR32, Blackfin, IA-64, MIPS, OpenRISC/or32, PowerPC, s390, SuperH, x86.
Wer Programme sowohl für Windows als auch für den Linux Desktop schreiben möchte (bzw. muß), hat mit http://www.wxwidgets.org/ und der IDE http://www.codeblocks.org/ eine freie und funktionierende Lösung.
Oliver Döring schrieb: Danke erstmal für den Hinweis mit den Crosscompilern - könnte mir demnächst helfen :-) > Wer Programme sowohl für Windows als auch für den Linux Desktop > schreiben möchte (bzw. muß), hat mit > > http://www.wxwidgets.org/ Genau - dann könnte er auch gleich bei KiCad mithelfen ;-) Andere freie Lösungen existieren: Tcl/Tk usw. > und der IDE > > http://www.codeblocks.org/ Arbeitest Du damit? Ich schaue sie mir gerade an, da mir Eclipse nicht so zusagt. Allerdings habe ich es noch nicht geschafft, codeblocks eine vernünftige SVN-Anbindung zu geben. Das muss auf jeden Fall sein. Sonst sieht codeblocks schon sehr schön aus - da gibt es sogar AVR-Vorlagen. Chris D. (Ist heute ein besonderer Tag? Hier rennen Sie (die Kunden) uns die Bude ein ...)
Ich habe damit nur einmal ein kleines Konfigurationstool für ein Produkt geschrieben, das dann unter Linux und Windows funktionierte. Wobei nur das GUI und der damit zusammenhängende Code identisch war, die Kommunikation über den USB-Port musste zwei mal getrennt implementiert werden. SVN habe ich nicht benutzt, da es ein sehr kleines Projekt war, deshalb kann ich dir da nicht weiterhelfen. Um auf dem PC ein embedded Linux für eine andere Architektur zu bauen, ist buildroot das Standardtool. Allerdings hat das auch Schwächen, ein bisschen patchen wird man immer müssen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.