Hi Stefan,
hier ein befruchtender Beitrag meinerseits.
> core - Eventkanäle (Source/Sink), Scheduling, ???
lib - Controller-unabhängige Komponenten, VirtualTimer?
controller - für jede(n) Controller(familie) getrennt
driver - Gerätetreiber mit spezifizierten Schnittstellen (I2C, SPI)
contrib - der ganze andere Kram ;-)
klingt plausibel. Plattformen als solche werden aufgegeben? Das begrüße ich.
* wo würden in so einem System die examples hinwandern? Dort geht es ja
darum, ein example für viele Plattformen gemeinsam bereit zu stellen.
Ich würd sie in ein extra Repository auslagern. Am besten erst mal alle
examples in ein gemeinsames Repository. Problem: Wie trennt man die Doku auf?
* Wo kommt die Dokumentation hin? Was wird alles dokumentiert?
Eine gute html-Api-Doku auf Basis von doxygen finde ich sehr hilfreich. Und
zwar so, dass man beim Lesen erfährt, wie man die Klasse / Funktion benutzt.
Also nicht in der vielsagenden Form "This is the default constructor."
Dann gibts da noch Doku, die sich eher um das Gesamtsystem dreht. Die könnte
man vielleicht in einem separaten Repository pflegen. Dafür wurde von Sören
mal sphinx vorgeschlagen, aber mit doxygen würde man sicherlich auch weiter
kommen. Vielleicht ließe sich auch einiges aus der existierende tex-Doku
übernehmen?
* Wie entscheiden wir, was wie nah an den Reflex Kern ran darf
Über die Mailingliste. Nur was vorher durchgesehen wurde, darf in den Kern.
Weitere Einschränkungen willkommen.
* Was wurde da noch alles vergessen?
Bei folgenden Problemen sind wir bei Lesswire bisher abgestorben:
1 Überladen von Code
2 Vorkompilieren von Bibliotheken
3 Abhängigkeit vom Scheduling-Schema
1) Folgendes Szenario: Eine Komponente in lib benötigt Code, der auf allen
Controllern bis auf einem identisch ist.
Lösung: partiell spezialisieren mit controller-Zweig als Template-Parameter,
der allgemeinen Implementierung in lib und der partiellen Spezialisierung im
betreffenden Controller-Zweig.
2) Vielleicht kann man einiges von den Reflex-Bibliotheken schon
vorkompilieren und linken. Dann hat man einmalig eine Art configure-stage
beim Installieren.
3) Jede Aktivität und damit jede Komponente ändert ihr Speicherlayout
abhängig vom Scheduling-Schema.
Problem: Bibliotheken lassen sich nicht einfach vorkompilieren ohne das
Schema vorher anzugeben.
Lösung 1: Eine gemeinsame Aktivitätsklasse für Fifo-Scheduler und
PriorityScheduler. Alle anderen Scheduler wegschmeißen.
Lösung 2: Eine gemeinsame Aktivitätsklasse für alle Scheduler. Zusätzliche
und zur Compilezeit bekannten Metadaten von Aktivitäten in einer zentralen
Tabelle sammeln und im Flash ablegen. Eine Aktivität bekommt nur noch einen
Pointer auf ihren Tabelleneintrag beim starten zugewiesen. Evtl braucht man
nicht einmal das. Allerdings ist der Aufwand für den Scheduler dann etwas
höher, die Metadaten herauszufinden.
Richard
