Mehrfach wurde angeregt einen Code-Pool für avr-gcc C zu schaffen.
Da der Artikel zu avr-gcc nicht der geeignete Ort dafür ist, bietet sich -- wenn überhaupt -- ein eigener Artikel an.
Nun ist ein Code-Pool kein normaler Artikel, und bevor man damit anfängt, sollte diskutiert werden, wie weit sowas überhaupt sinnvoll ist und wenn ja, in welcher Form.
Einfach nur ein copy && paste des Codes in den Artikel bringt keinem was.
Zu bedenken gebe ich mal
- welche Code-Convention sollten eingehalten werden?
- ANSI-C?
- Dokumentierung
- Kommentierung
- Indentation
- Naming Conventions für Makros, typedefs, Funktionen, etc
- Was ist das für Code?
- Funktionsbeschreibung / Interfaces / Prototypen / Synopsis / Spezifikation...
- ein komplettes Modul
- eine Funktion
- nur ein Schnippsel
- pseudo-Code
- dient das als Vorlage oder soll es 'out of the box' funktionieren?
- Wie weit reicht der Code?
- Stärken, Schwächen
- Unzulänglichkeiten und bekannte Fehler
- Ist der Code getestet?
- Für welche Controller?
- Ist das halbwegs portierbar?
- Welche Änderungen wären dazu vorzunehmen?
- inwieweit ist das ganze maschinen(un)abhängig?
- Kosten und Gewinn
- Was wird verbraucht?
- flash
- SRAM
- EEPROM
- Laufzeit
- Hardware (Timer, I/O, Interrupt-Vektoren)
- warum steht der Code im Artikel?
- warum könn(t)en andere davon profitieren?
- Was wird verbraucht?
- Wie könnten Versionierung / bugfixes / Erweiterungen /Diskussionen aussehen
- Welche Nebeneffekte treten auf?
- müssen IRQs aktiv sein?
- was ändert sich, wenn ISRs (nicht mehr) kaskadieren dürfen/müssen?
- globale Variablen?
- Ist der Code geeignet für eine Bibliothek?
- Was muss zur Compilezeit bekannt sein? Wann muss er neu generiert werden?
- was ist zu ändern, um den Code in eine Bibliothek aufnehmen zu können?
- Wie wird der Code einsortiert?
- Nach Funktion (schwierig, da oft mehrere Dinge erledigt werden)
- nach Qualität
- komplettes, sauber implementiertes portierbares Modul oder nur Schnippsel?
- Wie wird Überschaubarkeit gewahrt?
--SprinterSB 17:14, 2. Dez 2005 (CET)