Eine weitere Idee zur Strukturierung: Vielleicht benötigen wir ein Paket, das weder "Core" ist, noch "Components", sondern Implementierungsstützen für die "Components" und "Devices" liefert. Da könnten dann rein:
ProtoThreads, VirtualTimers, sämtliche ADTs, Buffer (eigentlich ja auch nur ein ADT), "Algorithms" wie Logarithm und Random. Aber vielleicht wird das dann auch schon wieder zu breit und unaufgeräumt. Ich will das jedenfalls nicht "misc" oder "util" nennen. Aber da sollten halt Sachen rein, die noch nicht direkt Komponenten mit Ereignisflussprinzip implementieren. Dinge die für die Benutzung mit Reflex dann in Komponenten verpackt werden. In die "components" Standardbibliothek sollten dann nur echte Komponenten nach Event-Flow-Model rein. Ich überlege auch wo das generische Debugging-Interface hingehört, damit das über alle Controller hinweg die gleiche Schnittstelle bietet, auch wenn die Controller dann für die Abbildung auf eine echte Implementierung verantwortlich sind. Grüße Stefan Am 08.07.2014 22:09, schrieb Stefan Nürnberger: > Hallo Richard, > > danke für die Arbeit. Bei den meisten Sachen gehe ich mit. Genaueres > unten im zitierten Text und in den Tickets. > > Ich hätte gern eine Auflistung von Ideen, wie die zukünftige Aufteilung > in Libraries aussehen soll/kann und was dann da rein gehört bzw. was > nicht, auch für Komponenten die es heute noch gar nicht gibt. Das macht > es einfacher darüber zu diskutieren, was man wohin schieben könnte. > Einiges ist ja recht klar. Anderes muss sicher diskutiert werden. > > Unfertige Idee: > core > Die Kernfunktionalität: Interrupts, Scheduling, Event Channels > controller-xxx > Diverse Pakete für Controllerfamilien, hardwareabhängiges, > Debugging, (ohne wird core mglw. nicht kompilieren?!) > "platform" sollte hier vielleicht auch mit rein, zwar weiter > in einer extra Ordnerstruktur, aber es ist doch stark verwandt. > components > Einfache generische Komponenten sowie oft verwendetes, eine Art > "Standardbibliothek" mit Prescaler, Delay, Buffer und auch das > VirtualTimer Framework. > devices > Generische Interfaces (I2C, SPI, "I/O Ports", etc.) > Generische Treiberimplementierungen auf Basis dieser > Interfaces, die mit allen Controllern funktionieren. > Vielleicht auch sowas wie z.B. eine "RGB-Led". > examples > Beispielanwendungen für verschiedene Plattformen. Ich mächte ja > gern ein Beispiel immer für mehrere Plattformen haben. Das passt > leider mit den getrennten controller-Bibliotheken nicht so gut. > proof-of-concept/staging > Sachen wie das Update Zeug und Reflection könnten als proof > of concept in eine Art Staging-Area. Vielleicht kann es auch > einfach mit zu den Examples. > > Die sinnvollen ADTs müssen wir auch irgendwo unterbringen. Und die nicht > ganz so sinnvollen sollten zur Übersichtlichkeit auch dort sein (oder > ganz entfernt werden). Aber ADTs sind keine Komponenten und keine > Geräte. Vielleicht brauchen wir hierfür eine eigene Library, mit Sachen > die von den "components" und "devices" für die interne Implementierung > genutzt werden können. > Eine weitere Sache sind Protokollstacks für Kommunikation. Ich bin mir > nicht sicher ob das mit zu "devices" gehört. Das sollte vielleicht eher > mit dem XML-Zeug zusammengelegt werden. > > Grüße > Stefan > --- 8< ---
