Hallo zusammen!
Wie ich im Betreff schon schrieb, würde ich es mir wünschen, wenn es in
diesem Forum - ähnlich einer Codesammlung - eine Sammlung von
C-Bibliotheken gäbe. Aufgeteilt in Hardware- bzw. Softwarebibliothek und
ggf mit Beispielprogrammen und Diskussion. Das würde den Einstieg für
Anfänger enorm erleichtern, weil er so nicht erst lange im WWW suchen
muß um eine Lösung für sein Problem zu finden. Er hätte außerdem die
aktuellste und eine mehrfach erprobte Version.
Es müßten sich natürlich Moderatoren finden, die diese Sammlung
verwalten würden.
Was haltet Ihr davon?
RazzleDazzle
Grundsätzlich hab ich mir das schon einmal überlegt.
Das Problem: Zur Zeit gibt es niemanden, der sich die Arbeit machen
würde, die zweifellos in genügender Anzahl vorhandenen Einzelteile aus
Codesammlung und Tutorium zu sammeln, auf einen gemeinsam akzeptierten
Codestil zu bringen und zu pflegen.
Das nächste Problem besteht darin: Für welche Hardwarebasis soll das
alles geschehen? Es gibt hier (leider) keine Referenzhardware, die man
zb. als gemeinsame Basis für Pinbelegungen etc. benutzen kann.
D.h. meiner Meinung nach müsste man zuallererst damit anfangen, so etwas
wie ein Experimentiersystem als Referenzsystem definieren, welches zb
als Basis für das Tutorium hergenommen wird (was auch dem Tut sicherlich
gut tun würde).
Karl heinz Buchegger schrieb:
> Das Problem: Zur Zeit gibt es niemanden, der sich die Arbeit machen> würde, die zweifellos in genügender Anzahl vorhandenen Einzelteile aus> Codesammlung und Tutorium zu sammeln, auf einen gemeinsam akzeptierten> Codestil zu bringen und zu pflegen.
Das ist wohl das größte Problem und vermutlich von einer Person gar
nicht zu schaffen.
> Das nächste Problem besteht darin: Für welche Hardwarebasis soll das> alles geschehen? Es gibt hier (leider) keine Referenzhardware, die man> zb. als gemeinsame Basis für Pinbelegungen etc. benutzen kann.
Ich halte eine Referenzhardware für eher kontraproduktiv. Gerade weil es
beispielsweise unterschiedliche Möglichkeiten zum Anschluß eines
Text-LCD gibt (4-bit, 8-bit, mit R/W, ohne R/W, memorymapped) sollte man
sich unter einem Oberbegriff "Textdisplay" die richtige Bibliothek
aussuchen. Wer dann noch zu einem Exoten oder einer "einer unüblichen"
Anschlußmöglichkeit greift, ist selbst Schuld. Er darf dann aber auch
gerne seine Lösung einem Moderator zur Aufnahme in die Sammlung
vorlegen.
RazzleDazzle
RazzleDazzle schrieb:
> Ich halte eine Referenzhardware für eher kontraproduktiv. Gerade weil es> beispielsweise unterschiedliche Möglichkeiten zum Anschluß eines> Text-LCD gibt (4-bit, 8-bit, mit R/W, ohne R/W, memorymapped) sollte man> sich unter einem Oberbegriff "Textdisplay" die richtige Bibliothek> aussuchen.
Dem "kontraproduktiv" kann ich ganz und gar nicht zustimmen. Ich denke
auch, dass eine solche Referenzhardware von Vorteil wäre. Das Ganze soll
sich doch an Anfänger richten, oder? Die Hardware ist doch da der erste
Schritt, und auch die erste Hürde. Ein leicht nachbaubare
Referenzhardware als Ausgangspunkt wäre da doch vorteilhaft. Auf dessen
Basis könnte dann auch eine eventuelle ausführlichere Beschreibung des
Softwaremoduls erfolgen.
Zusätzliche Module für alternative Anschlussmöglichkeiten oder für
komplett andere Hardware sind damit ja nicht ausgeschlossen.
Es gibt doch jetzt schon den Ansatz mit SVN sowie die
Rubrik "Codesammlung".
Reicht das nicht? In SVN kann alles rein, was sich gelegentlich
noch ändern wird und vielleicht Varianten austreibt und kann vor
allem vom jeweiligen Ersteller und bei Bedarf von weiteren gepflegt
werden.
Karl heinz Buchegger schrieb:
> die zweifellos in genügender Anzahl vorhandenen Einzelteile aus> Codesammlung und Tutorium zu sammeln, auf einen gemeinsam akzeptierten> Codestil zu bringen und zu pflegen
Karl Heinz Buchegger hat es doch hier bereits genau auf den Punkt
gebracht! Genau das, nicht mehr und nicht weniger, soll eine
Bibliothekssammlung machen. Warum sich selbst noch Zwänge mit einer
Referenz-Hardware auferlegen. Bis die dann erst mal von allen akzeptiert
ist, ist die ganze Idee schon längst den Bach runter.
Eine Anfängerhardware mit eigenem Tutorial und einer Teilmenge der noch
zu schaffenden Bibliothekensammlung ist doch wieder eine ganz andere
Geschichte.
Der Witz ist doch, dass jeder C-Programmierer diese Bibliothekensammlung
für sich bereits hat. Im Prinzip kocht da doch jeder sein eigenes
Süppchen.
RazzleDazzle
RazzleDazzle schrieb:
> Ich halte eine Referenzhardware für eher kontraproduktiv. Gerade weil es> beispielsweise unterschiedliche Möglichkeiten zum Anschluß eines> Text-LCD gibt (4-bit, 8-bit, mit R/W, ohne R/W, memorymapped) sollte man> sich unter einem Oberbegriff "Textdisplay" die richtige Bibliothek> aussuchen.
Hmm
Nehmen wir zb die Peter Fleury Funktionen für die LCD Ansteuerung.
Die sind nun wirklich auf jede Hardwaresituation ganz einfach
anzupassen. Und doch gibt es jede Woche mindestens 10 Fragestellungen
dazu, von Leuten, die das nicht schaffen.
Das reicht von: Ich habe mein LCD am Port D angeschlossen, muss ich
jetzt überall PORTD eintragen?
bis hin zur Erkentniss, dass das Weglassen der R/W Leitung so zunächst
nicht vorgesehen ist, aber im Grunde leicht ausbaubar ist (dem steht
dann allerdings meistens ein Satz im Eröffnungsposting entgegen: Ich
will ... bauen, habe aber keine Ahnung von programmieren)
Von daher halte ich eine Referenzhardware keineswegs kontraproduktiv.
OK. Kontraproduktiv könnte höchstens sein, dass dieselben Leute dann
noch weniger darüber nachdenken was sie da eigentlich tun.
Hallo
als Referenzplatform köönnte man die Board von Uli Radig nehmen. Der hat
ja auch schon vieles zur Verfügung gestellt.
Was ich in diesem Zusammenhang schlecht finde, ist die ausführliche
Diskussion über das Pollin Board, wie man darauf die Radig Software zum
Laufen bringt.
Ich bin aber nicht Uli!
Klaus Wachtler schrieb:
> Es gibt doch jetzt schon den Ansatz mit SVN sowie die> Rubrik "Codesammlung".
Mal konkret:
Für die drei elektrischen Rolladen meines Wintergartens plane ich z.Zt.
die Hardware. Es wird ein Bedienelement mit 6 Tastern und 6 LED, sowie
integriertem Helligkeitsensor (BPW40) und Temperatursensor (DS18S20)
geben. Außerdem ein Relaismodul mit 4 FET und 4 Relais, eventuell
Text-LCD. Beide Module haben jeweils einen AVR mit MAX485 und werden in
Zweidraht an den bestehenden Hausbus angeschlossen.
Ich brauche C-Funktionen für:
- Text LCD, 4-Bit, ohne RW
- RS485-Kommunikation mit MPCM
- AD-Wandlung
- 1Wire allgemein, DS1820 speziell
- PWM für LED (Hard- oder Soft-PWM?)
- Tastenentprellung
Wo finde ich das denn nun in der Codesammlung und SVN?
RazzleDazzle
Eventuell lohnt es sich hier, ein verteiltes Konzept anzuwenden, wie es
Beispielsweise beim Linux-Kernel verwendet wird. Jeder pflegt seine
Bibliotheken selbst und bringt sie auf einen gemeinsamen Stand und eine
Person muss nur noch die aktuellen Versionen pruefen und
zusammenfuehren.
Ich weiss ehrlich gesagt nicht, wieso hier alle eine Referenzhardware
wollen: Ich sehe darin nur Nachteile.
Gruesse
Marvin
Hallo,
man könnte ja ganz einfach anfangen mit C-Bibliotheken für die weit
verbreiteten Gerätebusse: I2C, SPI und 1-Wire.
Dann braucht der Anwender doch nur seine eigenen Port-Pins anzupassen
und ev. einige zeitabhängige Funktionen.
Der Rest sollte dann auf jeder Plattform laufen.
Auch bei Bauteinen, die nicht gerade über Ports betrieben werden,
sondern "ganz normal" über Daten-, Adress- und Steuerbus (wie z.B. bei
vielen 8051er-Systemen) ist der Änderungsaufwand oft minimal und bezieht
sich hier nur auf das Ändern der CS\-Adressen.
Allerdings kommen dann die wirklichen Schwierigkeiten, denn C-Compiler
ist ja nun leider nicht gleich C-Compiler, besonders was die Handhabung
von SFRs-, SFR-Bits und Interrupts angeht.
Hier sind dann eigentlich die meisten Anpassungen notwendig.
Wir arbeiten gerade an einer ´C´-Funktionssammlung für den 1-Wire Bus
(DS18S20 und seine "Kollegen" DS2408 und DS2450).
Basis ist ein 8051er und die IDE ist µC/51.
Bei Bedarf können wir diese incl. einer kleinen Einführung in den
1-Wire-Bus, gerne hier veröffentlichen.
Bernd
>> Der Witz ist doch, dass jeder C-Programmierer diese Bibliothekensammlung>> für sich bereits hat. Im Prinzip kocht da doch jeder sein eigenes>> Süppchen.
Was glaubst du warum das so ist ? Ich würde hier auch nicht alles
mundgerecht servieren wollen. Fertige Bibliotheken erarbeitet man sich
und versteht sie dann auch. Mir kommt das eher so vor als würde eine
Form von "bedien mich" Mentalität sich mehr und mehr breitmachen.
Karl Heinz bringt es auf den Punkt :-)
Kontraproduktiv könnte höchstens sein, dass dieselben Leute dann
noch weniger darüber nachdenken was sie da eigentlich tun.
@Bernd
"Kontraproduktiv könnte höchstens sein, dass dieselben Leute dann
noch weniger darüber nachdenken was sie da eigentlich tun."
Denk doch nicht so schlecht über die reinen µC-Anfänger.
Man sollte parallel zu den Bibliotheken auch nicht mit Erläuterungen
sparen, warum man etwas so programmiert hat.
Nur so können Anfänger wirklich etwas lernen.
Sehr oft findet doch der Beginner eine tolle Profi-Bibliothek, die alles
kann was er sucht, aber von Ablauf der Funktionen versteht er nichts.
Er kann die Funktionen gerade man einbinden und aufrufen.
Und wenn was nicht funktioniert, steht er da, fragt im Forum und bekommt
(manchmal) die Antwort, er solle sich doch bitte das selber erarbeiten.
Und die Suche im WWW bringt auch nicht viel, weil dann ev. vorhandene
Erklärungen zu anderen Funktuionen passen.
Wenn also Bibs veröffentlicht werden, dann auch mit "guten" Erklärungen
dazu
Bernd
Naja,
Copy + Paste aus alten Projekten ist aber auch nicht immer schön.
Die EierlegendeWollMilchSau wird man nur mit sehr viel Aufwand
programmieren können...
Vielleicht sollten wir Anforderungen an diese Lib(s) sammeln ???
- Erweiterbar
- µC (Familien) unabhängig
- Aufbau nach bestimmten Schema
- Frei konfigurierbar
- ...
Bernd schrieb:
> Mir kommt das eher so vor als würde eine> Form von "bedien mich" Mentalität sich mehr und mehr breitmachen.
Als TO fühle ich mich angesprochen. Ich habe keine akademische
Ausbildung. Beruflich habe ich nichts mit Mikroelektronik zu tun. Ich
bin erst im Laufe meines (Berufs-)Lebens auf den Geschmack gekommen. Vor
10 Jahren habe ich dank Mark Alberts, dem Entwickler des preisgünstigen
BASCOM-Compilers, den Einstieg in die AVR-Programmierung geschafft.
Danke, Mark Alberts.
Mehrfach habe ich versucht - neben meinem Berufs- und Familienleben - C
zu lernen. Vergeblich.
Mit Bascom habe ich in den letzten 4 Jahren einen Hausbus realisiert,
der Rolladen steuert, Heizung steuert, Regenwasser erfasst.
Bedienmöglichkeit in den einzelnen Etagen, Dokumentation der
Systemgrößen auf SD-Karte. Das alles in Bascom.
Mir geht es darum Projekte zu verwirklichen. Wie ein Zeichen auf ein
Text-LCD oder Grafisches LCD im Detail kommt, interessiert ich nicht.
Bascom hat auch keine tolle IDE. Der Editor ist viel schlechter als
Notepad++. Aber ich habe alles beisammen. Darauf kommts an.
MfG
RazzleDazzle
Da es noch einen weiteren Bernd gibt habe ich noch einen Buchstaben
hinzugefügt :-)
>> Mehrfach habe ich versucht - neben meinem Berufs- und Familienleben - C>> zu lernen. Vergeblich.
Das kann ich gut verstehen denn gute C Bücher oder auch Anleitungen wie
man C erlernt sind rar gesäht.
Ich habe einfach unterstellt das man eben Lernen möchte und dann findet
man schon recht viel hier. Ebenso gibt es eine Menge Leute hier die sehr
hilfsbereit sind.
Eine Rubrik C für Anfänger wäre dann eher brauchbar und hilfreich.
>> Mir geht es darum Projekte zu verwirklichen. Wie ein Zeichen auf ein>> Text-LCD oder Grafisches LCD im Detail kommt, interessiert ich nicht.
Kann ich auch verstehen aber dann bleib bei deinem Baukastensystem ala
Bascom. Hier ist eben dann das Limit vom Werkzeug abhängig. C und
Assembler sind unlimited :-)
Du betreibst das als Hobby, ist auch ok so. Vergiß aber nicht das hier
einige unterwegs sind die ihre Brötchen damit verdienen. Hilfe zu
leisten oder perfekten Code zu liefern sind zweierlei. Bei einer Lib
gehe ich von perfekten Code aus... allein das beißt sich schon mit dem
Begriff Anfänger.
Ein Library sollte natuerlich hinreichend flexibel geschrieben sein.
Dies ereicht man in vielen Teilen mit wenigen zusaetzlichen Zeilen.
Anstelle :
PortB,7=1; // CS hoch
sollte man eher
define CS = PortB,7
..
CS=1;
schreiben. Aber da ist man nach der zweiten Version sowieso.
Bei Mikroprozessoren, wo was schiefgehen kann, was Geld kostet:
In den meisten Fällen verlasse ich mich nur ungern blind auf fremden
Quelltext. Und wenn ich den fremden Quelltext doch Stück für Stück
durchgehe, kann ich ihn auch gleich selbst schreiben oder neu schreiben.
RazzleDazzle schrieb:
> @Sven P.> Ach ja? Und den Compiler schreibst Du dann auch gleich selbst?
Ne, den benutzen aber dafür auch ein paar tausend Leute mehr, die Fehler
finden.
Zum Beispiel ist im RFM-Stack aus dem SVN folgendes:
1
typedefunionconv_{
2
unsignedintw;
3
unsignedcharb[2];
4
}CONVERTW;
enthalten. Programmtechnisch ist das mehr oder weniger ein
Lehrbuchbeispiel für schlechten Quelltext. Grad wenns portabel sein
soll.
Sorry, Sven P., ich hab die Ironie-Tags vergessen. Aber jemand wie du
kann ja einstecken!
Eigentlich erwarte ich ja gerade von einem professionellen Entwickler,
dass er seinen Quellcode kennt.
Aber ich bin bisher davon ausgegangen, das professionelle Entwicklungen
auch mit professionellen Entwicklungsumgebungen (Keil, ICC, hitec, etc.)
gemacht würden. WinAVR habe ich eigentlich nur als Spielwiese der
professionellen Programmierer betrachtet, die sich hier mal ein bischen
austoben wollen.
Liege ich da etwa falsch?
RazzleDazzle
Man sollte hier vielleicht doch ganz klar unterscheiden, zwischen
Anfängern, engagierten Hobbyisten und Profis.
Ist eine "Fremd-Bib" vernünftig dokumentiert und offen gelegt, und
gerade bei ´C´, ohne die allerbesten Super-Tricks und Kniffe
programmiert, so können die ersten beiden Gruppen durchaus was lernen,
denn sie erkennen: "Aha, so kann man etwas lösen" und das sollte hier
das Ziel sein.
Und selbst Profis sollten offen für andere Wege sein, die auch
funktionieren. Aber diese Anwender können dann wirklich selber etwas
schreiben und es dann in einer vernünftigen Form weitergeben (sofern das
möglich und erlaubt ist)
Bernd-B
(der zweite Bernd hier)
RazzleDazzle schrieb:
> Sorry, Sven P., ich hab die Ironie-Tags vergessen. Aber jemand wie du> kann ja einstecken!
Da brauchst du keine Ironie-Tags, dein Einwand ist auch so vollkommen
berechtigt.
Prinzipiell, so sag ich ehrlich, würde ich mir lieber einen Compiler
selber schreiben, als die Krücke von GCC zu benutzen, nur dazu fehlt mir
Wissen, Zeit und Motivation.
> Eigentlich erwarte ich ja gerade von einem professionellen Entwickler,> dass er seinen Quellcode kennt.
Schön wärs. Irgendwo musst einen Schnitt machen. Ich für meinen Teil
etwa denke mir: Unten POSIX und fertig. Ich mach mir keinen Kopf mehr
darüber, wie irgendwer POSIX implementiert.
> Aber ich bin bisher davon ausgegangen, das professionelle Entwicklungen> auch mit professionellen Entwicklungsumgebungen (Keil, ICC, hitec, etc.)> gemacht würden. WinAVR habe ich eigentlich nur als Spielwiese der> professionellen Programmierer betrachtet, die sich hier mal ein bischen> austoben wollen.> Liege ich da etwa falsch?
Naja, wie gesagt... der GCC ist m.M.n ne veraltete Krücke, die offenbar
kaum noch jemand warten möchte (ich verweise auf 'Fefe sein Blog', wo
man sich mit den GCC-Entwicklern zankt).
Die Krux an der Sache ist: Wenn du in die Quelltexte von Keil, ICC,
Hitec hereinschauen könntest, würdest du mit großer Sicherheit
(zumindest in Teilen des Quelltextes) zum gleichen Ergebnis kommen...
Professionell für AVR ist allerhöchstens der Assembler, da siehst du was
reingeht und weißt definitiv, was herauskommt.
>> WinAVR habe ich eigentlich nur als Spielwiese der professionellen>> Programmierer betrachtet, die sich hier mal ein bischen austoben wollen.>> Liege ich da etwa falsch?
Ja :-) sehe keinen Grund hier den IAR Compiler zu verwenden obwohl
dieser recht gut ist.
Ich will aber keine Compiler diskussion starten... es ist eher das Henne
Ei Problem. Diejenigen die es können brauchen keine LIB und diejenigen
die gerne eine hätten können es nicht, nicht böse gemeint.
>> In den meisten Fällen verlasse ich mich nur ungern blind auf fremden>> Quelltext.
Sehe ich auch so.
>> Und wenn ich den fremden Quelltext doch Stück für Stück durchgehe, kann >> ich
ihn auch gleich selbst schreiben oder neu schreiben.
Jap, zumindestens bekommt er dann "meine Form", die Gedankengänge werden
nachvollzogen und dann in die eigene Form gebracht. Fremder Code kann
sehr hilfreich sein, fertige LIB's nicht.
@Sven,
> Prinzipiell, so sag ich ehrlich, würde ich mir lieber einen Compiler> selber schreiben, als die Krücke von GCC zu benutzen, nur dazu fehlt mir> Wissen, Zeit und Motivation.
Interessant. Wie paßt das zusammen ?
> Naja, wie gesagt... der GCC ist m.M.n ne veraltete Krücke, die offenbar> kaum noch jemand warten möchte (ich verweise auf 'Fefe sein Blog', wo> man sich mit den GCC-Entwicklern zankt).
Zum Zanken fehlt bei Fefe die Möglichkeit zu Kommentieren. Er hat seine
Sicht der Dinge, und die wird nicht dadurch wahrer je lauter er sie
durch die Gegend posaunt. Andere sehen halt Dinge anders.
Gruss,
Tobi
Tobi schrieb:
> @Sven,>>> Prinzipiell, so sag ich ehrlich, würde ich mir lieber einen Compiler>> selber schreiben, als die Krücke von GCC zu benutzen, nur dazu fehlt mir>> Wissen, Zeit und Motivation.>> Interessant. Wie paßt das zusammen ?
Recht simpel: Ich hab spaßeshalber die GCC-Quellen gelesen, weil ich
u.A. auf der Suche nach beispielhaften Implementierungen von Bäumen etc.
war. Dabei empfand ich die Quelltext unnötig lang (ich finde 13.000
Zeilen in einer Datei nicht sonderlich übersichtlich) und in meinen
Augen furchtbar chaotisch. Dass Backend und Frontend schon lange nich
mehr so wirklich miteinander wollen, sieht man ja immer wieder, wenn es
Probleme gibt, den GCC auf eine Architektur anzupassen (unnötige Prologe
und so weiter).
Aber andrerseits habe ich halt keine Ahnung von Compilerbau und die
Thematik interessiert mich nicht sonderlich.
>> Naja, wie gesagt... der GCC ist m.M.n ne veraltete Krücke, die offenbar>> kaum noch jemand warten möchte (ich verweise auf 'Fefe sein Blog', wo>> man sich mit den GCC-Entwicklern zankt).>> Zum Zanken fehlt bei Fefe die Möglichkeit zu Kommentieren. Er hat seine> Sicht der Dinge, und die wird nicht dadurch wahrer je lauter er sie> durch die Gegend posaunt. Andere sehen halt Dinge anders.
Ist schon wahr. Aber an Zankereien in den Mailinglisten ändert das ja
nix...
Das Problem an so einer Bibliothek ist, dass jeder etwas andere
Anforderungen und Vorstellungen hat wie so etwas aussehen soll.
Allenfalls für Anfänger wäre eine komplette All-In-One-Bibliothek
interessant; aber da gibt es bereits Arduino, und für den der es ganz
einfach haben möchte, BASCOM. Bei denen die tiefer einsteigen wollen
gehen die Anforderungen zu weit auseinander, so dass sowieso mehr
Anpassungen notwendig sind, und es relativ wenig zusätzlicher Aufwand
ist die Bibliotheken/Codeschnipsel (z.B. für Entprellung, FAT, LCD, RC5)
selbst zusammenzusuchen.
Sicher wäre es sinnvoll die in der Codesammlung verstreuten Bibliotheken
besser zu sortieren und zugänglich zu machen, z.B. durch Pflege einer
"Referenzversion" im Wiki (wie bei Entprellung) oder SVN. Aber da
müssen die ursprünglichen Autoren mitspielen, damit Änderungen auch
wirklich ins Wiki/SVN übernommen werden, und man nicht doch wieder im
Forum nach der aktuellsten Version suchen muss.
Der GCC ist vom Ergebnis her nicht schlecht, hat aber intern mit viel
altem Ballast zu kämpfen. Irgendwann kommt der Punkt an dem sich das
nicht mehr lohnt, und mit CLANG steht bereits der Nachfolger in den
Startlöchern.
Andreas Schwarz schrieb:
> Irgendwann kommt der Punkt an dem sich das> nicht mehr lohnt, und mit CLANG steht bereits der Nachfolger in den> Startlöchern.
Tut mir leid, aber das will ich erstmal sehen, webkit hat Gecko auch
nicht verdrängt.
Wie oft haben sie den GCC schon tot gesagt? Der letzte GCC-Killer war
der Portable C Compiler, wo ich auch nur einmal was von gehört habe.
Wobei ich dir Recht, gebe, dass irgendwann der GCC mal tot sein kann.
Aber niemand weiß wann und ob das GNU-Projekt wirklich Lust hat, bei
einem Apple-Produkt mit ein zu steigen... da bin ich mir nicht so
sicher.
GNU hat viele Entwickler und wenn die wollen, können sie auch mal ein
Jahr (oder so) nur den Code aufräumen, optimieren, verbessern usw. usf.
Link zu schrieb:
> GNU hat viele Entwickler und wenn die wollen, können sie auch mal ein> Jahr (oder so) nur den Code aufräumen, optimieren, verbessern usw. usf.
Das Problem ist:
Der gcc wird auf vielen Platformen eingesetzt. Wir hier in der µC Szene,
sind 'unter ferner liefen'. Wenn gcc weiterentwickelt wird, dann wird
sich das hauptsächlich in der 32 und 64 Bit Welt abspielen. Das haben
wir doch auch heute schon, dass so manche Operation auf einem 8-Bit µC
einfach nicht wirklich vom Compiler implementiert wird.
Ich seh das wie Andreas:
Soabld es ein halbwegs konkurenzfähiges 'Produkt' gibt, welches
* auf einem AVR vernünftig optimiert und mit all den Spezialitäten
sauber umgehen kann
* ins AVR-Studio genauso simpel eingebunden werden kann wie der WinAVR
sind die Tage des WinAVR gezählt.
Zumindest mich würde nicht, oder nicht viel beim WinAVR halten.
Letztenendes ist es mir egal, wie der Compiler heißt, solange ich mich
auf ihn verlassen kann.
Link zu schrieb:
> Aber niemand weiß wann und ob das GNU-Projekt wirklich Lust hat, bei> einem Apple-Produkt mit ein zu steigen... da bin ich mir nicht so> sicher.
Ich bin mir ziemlich sicher dass sie dazu keine Lust haben, aber das ist
auch gar nicht nötig.
> GNU hat viele Entwickler und wenn die wollen, können sie auch mal ein> Jahr (oder so) nur den Code aufräumen, optimieren, verbessern usw. usf.
Irgendwann hat jede Software das Ende ihrer Lebensdauer erreicht, dann
ist es mit Code aufräumen nicht mehr getan, dann muss sie neu
geschrieben werden um mit der aktuellen Konkurrenz mithalten zu können.
Zum Thema Mikrocontroller, ein "driver" (=backend) für MSP430 ist in
Entwicklung: https://www.fooe.net/trac/llvm-msp430/
