mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Warum gibts keine forumeigene C Bibliothek?


Autor: RazzleDazzle (Gast)
Datum:

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

Autor: wilials (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das würde mir auch gut gefallen
wilials

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

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

Autor: RazzleDazzle (Gast)
Datum:

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

Autor: Stefan Ernst (sternst)
Datum:

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

Autor: Klaus Wachtler (mfgkw)
Datum:

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

Autor: RazzleDazzle (Gast)
Datum:

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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

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

Autor: Referenz (Gast)
Datum:

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

Autor: RazzleDazzle (Gast)
Datum:

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

Autor: Marvin (Gast)
Datum:

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

Autor: Stichwortgeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino

Autor: Bernd (Gast)
Datum:

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

Autor: Bernd (Gast)
Datum:

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

Autor: Bernd (Gast)
Datum:

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

Autor: Thomas W. (wagneth)
Datum:

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

Autor: Link zu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RazzleDazzle schrieb:
> Wo finde ich das denn nun in der Codesammlung und SVN?
http://www.mikrocontroller.net/svnbrowser

Autor: Link zu (Gast)
Datum:

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

Autor: RazzleDazzle (Gast)
Datum:

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

Autor: Bernd N (Gast)
Datum:

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

Autor: Zwölf Mal Acht (hacky)
Datum:

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

Autor: Sven P. (haku) Benutzerseite
Datum:

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

Autor: RazzleDazzle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sven P.
Ach ja? Und den Compiler schreibst Du dann auch gleich selbst?

RazzleDazzle

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
typedef union conv_ {
  unsigned int w;
  unsigned char b[2];
} CONVERTW;
enthalten. Programmtechnisch ist das mehr oder weniger ein 
Lehrbuchbeispiel für schlechten Quelltext. Grad wenns portabel sein 
soll.

Autor: RazzleDazzle (Gast)
Datum:

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

Autor: Bernd-B (Gast)
Datum:

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

Autor: Sven P. (haku) Benutzerseite
Datum:

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

Autor: Bernd N (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

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

Autor: Sven P. (haku) Benutzerseite
Datum:

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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: Link zu (Gast)
Datum:

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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

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.