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 - ...
RazzleDazzle schrieb: > Wo finde ich das denn nun in der Codesammlung und SVN? http://www.mikrocontroller.net/svnbrowser
Link zu schrieb: > RazzleDazzle schrieb: >> Wo finde ich das denn nun in der Codesammlung und SVN? > http://www.mikrocontroller.net/svnbrowser http://www.mikrocontroller.net/articles/Hilfe:SVN
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.
@Sven P. Ach ja? Und den Compiler schreibst Du dann auch gleich selbst? RazzleDazzle
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 | typedef union conv_ { |
2 | unsigned int w; |
3 | unsigned char b[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/
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.