HIVE-Project

Irgendwann nach dem KC-Treffen möchte ich beginnen das bestehende Betriebssystem neu zu überarbeiten und eine erste Version des TriOS zusammenzustellen. Im folgenden meine groben Vorstellungen. Wie weit ich dabei komme und was letztlich dabei herauskommt muß ich mal schauen. Ich wollte mal die grobe Struktur zur Diskussion stellen, velleicht gibt es ja noch interessante Ideen dazu. Wer Lust hat kann natürlich mitarbeiten, dann geht das Ganze schneller. Und frühzeitige Mitarbeit sichert auch die Möglichkeit der Einflußnahme, denn spätere Programme werden wohl auf dieser Version aufbauen.

Ich hab mal ein Schichtenmodell angehängt, welches die Struktur darstellt. Wichtig erscheint mir dabei ein möglichst einfacher und übersichtlicher Aufbau. Was bedeutet das:

- Möglichst viel kompakter und gut lesbarer SPIN-Code.
- Das IOS bleibt nach wie vor nicht reentrant - das ist mir momentan noch etwas zu hoch und würde das IOS auch mächtig aufblähen scheint mir. Das bedeutet: Zugriffe auf die Systemroutinen (Datei, Bus, eRAM usw.) sollten nur zentral durch einen Prozess erfolgen.

Neben diesen Punkten erscheinen mir die Einbindung von Funktionen um mit Verzeichnissen umzugehen, die Möglichkeit Administra zur Laufzeit mit einem neuen Code zu booten und eine klare Struktur des IOS als einzige zentrale Schnittstelle zur Anwendersoftware am wichtigsten. Mit der Fähigkeit Administra zur Laufzeit anzupassen wird der Hive erst wirklich sein flexibles Potential entwickeln, denn eines ist bisher klar geworden: Alle Möglichkeiten und Potentiale kann man nicht in einem einzigen Administra-Bios unterbringen. So kann man dann zum Beispiel problemlos ein LAN-Bios starten, um mit dem Netzwerk zu experimentieren, oder vielleicht sogar einen kompletten Webservercode in Administra unterbringen - natürlich auf Kosten anderer Funktionen, welche man in dieser Betriebsart nicht benötigt.

Administra:
- Bootmechanismus für Administra
- Einbindung eines RTC-Chips
- Verzeichnisse
- Funktionen um Datei-Zusatzinformationen (Datum, Attribute) zu verwalten
- Funktionen für eine zentral nutzbare serielle Schnittstelle
- I2C-Funktionen für einen externen Bus
- Überarbeitung der Soundroutinen (Wave!)
- LAN-BIOS per Administra-Bootmechanismus

Bellatrix:
- Erweiterter Standardtreiber mit Funktionen für eine einfache Benutzeroberfläche
- Oberfläche vielleicht im LCARS-Design?

Regnatix:
- Loader: Funktionen für die Initialisierung mehrer residenter Prozesse
- Funktionen für eine Speicherverwaltung des eRAM

Regime:
- Extender für ausführbare Dateien (*.adm, *.reg/bin, *.bel)
- History
- Kommando "aload" um das BIOS von Administra zu laden

Zusatzprogramme:
- Einfacher Texteditor
- Einfacher Dateimanager
- SPIN-Compiler (Sphinx)

Sonstiges:
- Dokumentation der IOS-Funktionen
- Überarbeitung des Bootvorgangs vom Gesamtgerät
- Verwaltung der gesamten Quellen per SVN

18-09-2010-dr235
- regime: free zeigt jetzt auch die speicherbelegung des eram an
- speicherverwaltung/ramdisk integriert (beispielcode siehe eram.spin & regime.spin)
- eram.bin kann jetzt auch mit ramdisk umgehen
- regime: neue kommandos für ramdisk
- egalisierung der namen für den ramzugriff (älterer code muß leicht angepasst werden)
- user- und systemmode für ramzugriff eingefügt
- erste version eine make-batch um das gesamte system zu kompilieren (nur grundsystem)
- änderung zur ios: da bst eine pfadliste zu bibliotheksordnern unterstützt, liegt (soweit das möglich ist) die ios nun nur noch unter system\regnatix

WICHTIG: Pfad zur ios.spin im bst einstellen

Infos zur Speicherverwaltung in der Readme im Archiv!

11-07-2010-dr235
- integration sid1/2-funktionen in admsid/ios
- anpassung sid-demo von ahle2 als regnatix-code (verzeichnis demo)
- diverse graphics-spielereien (verzeichnis demo)
- sysconf /af - administra neu booten (admflash.adm wird dadurch überflüssig)
27-06-2010-dr085/235
- admin mountet nun automatisch nach einem boot
26-06-2010-dr235
- div. demos zugefügt
- shooter angepasst und eingefügt
20-06-2010-dr235
- erste lauffähige SID-Player-Version für die Kommandozeile (splay)
14-06-2010-dr085/235
- Semaphoren in FATEngine korrekt eingesetzt
- Abfrage des Volume-Labels korrigiert
10-06-2010-dr235
- Kommando "ramtest" zugefügt
09-06-2010-dr085
- Fehler in Administra-Bootfunktion behoben

DOWNLOAD DER AKTUELLEN VERSION: Die aktuelle Version ist als Quelltext und als BIN-Version auf der google-code-Seite zum TriOS als Download verfügbar. Wer mitarbeiten möchte, kann sich dort auch in der Versionsverwaltung registrieren.

Link Downloads: http://code.google.com/p/hive-trios/downloads/list
Link Versionsverwaltung: http://code.google.com/p/hive-trios/

zu Sonstiges:

Punkt 3:

- Verwaltung der gesamten Quellen per SVN

Ist hier stattdessen GIT möglich?

Ob GIT oder SVN ist die Entscheidung noch nicht wirklich gefallen. Für mich persönlich sind beide Programme Neuland - ich muß mich da ein wenig auf euch verlassen und natürlich auf digger, der das Ganze stellt. Er wird sich sicher auch noch zu dem Thema hier melden.

Julian hat ja schon ein SVN aufgesetzt, ich hoffe er ist nicht böse, wenn wir das ein wenig bündeln und selbst organisieren wollen. Wichtig ist nur der zentrale Zugang und eine einheitliche Basis für alle die mitarbeiten wollen.

Hurra, der Winterschlaf ist vorbei......

drohne235 hat geschrieben:........Neben diesen Punkten erscheinen mir die Einbindung von Funktionen um mit Verzeichnissen umzugehen, die Möglichkeit Administra zur Laufzeit mit einem neuen Code zu booten und eine klare Struktur des IOS als einzige zentrale Schnittstelle zur Anwendersoftware am wichtigsten. Mit der Fähigkeit Administra zur Laufzeit anzupassen wird der Hive erst wirklich sein flexibles Potential entwickeln, denn eines ist bisher klar geworden: Alle Möglichkeiten und Potentiale kann man nicht in einem einzigen Administra-Bios unterbringen. So kann man dann zum Beispiel problemlos ein LAN-Bios starten, um mit dem Netzwerk zu experimentieren, oder vielleicht sogar einen kompletten Webservercode in Administra unterbringen - natürlich auf Kosten anderer Funktionen, welche man in dieser Betriebsart nicht benötigt......

Schön, daß Du dir das aufbürdest. Ich hatte schon gedacht, daß ich das mal selber machen müßte und in 5 bis 10 Jahren dann endlich so weit wäre den Hive in Gänze auszunutzen.

Ich denke mir, Du hast dir sicher zu diesem Punkt mal den bootloader für die ybox2 angesehen. Hierbei soll es wohl so gemacht worden sein, wie Du dir das zur Zeit vorstellst. Ich versuche mich da gerade ein wenig einzulesen um mich auch endlich in Spin einzuarbeiten. Hierbei merke ich, das dies mit zunehmendem Alter auch nicht mehr so schnell geht. Wenn ich es richtig verstanden habe wird aber ein größeres EEProm (>=64kB) benötigt um dann die gesamte Software für die ybox2 zu speichern.

Zur Funktion des Administra als Webserver hab ich erste User-Erfahrungen sammeln können. Ich werde dies mal kurz unter der Rubrik : Software behanden.

Wenn ich schon tiefer in der Spin-Programmierung drinstecken würde, wäre ich Dir sicherlich eine größere Hilfe. Aber ich bemühe mich Fortschritte zu machen.
Den von Dir gedachten Aufbau werde ich jetzt mal in Ruhe studieren. Auf den ersten Blick sieht es schon mal gut aus, ich denke Du hast dir sicher jede Menge Gedanken darüber gemacht.

Gruß
Günter

Fur die Dateiarbeit setze ich momentan voll auf die FATEngine von Kwabena Agyeman:

http://forums.parallax.com/forums/defau ... 5&m=416556

Dieses Paket kann mit Verzeichnissen umgehen und hat auch eine Bootfunktion. Außerdem ist der Code von Kye wirklich klasse strukturiert. Ich habe ja schon ganz verwegen in der bisherigen Version im fsrw kleine Veränderungen eingebracht, aber ich muß sagen, dass ich arge Probleme habe diesen Code intuitiv zu verstehen - alles erscheint mir da sehr verworren und undokumentiert. Einfach mal beide Versionen öffnen und vergleichen: für mich ein Unterschied wie Tag und Nacht. Ansonsten kann man über fsrw nicht schimpfen, der Code funktioniert tadellos, aber mit der Struktur komme ich persönlich da nicht weiter.

Vielleicht gelingt es ja auch noch später um die FATEngine eine FCBEngine als Schicht zu legen, um mehrere geöffnete Dateien über FCB's zu verwalten. Ich denke, momentan sollte wenigstens die Verwaltung verschiedener Pfade bzw. Suchkontexte möglich sein, so das man Systemkommandos in einem getrennten Pfad (/bin) ablegen kann. Muß mal schauen und experimentieren. FCB's sind aber in der ersten Version noch nicht geplant - das ist mir noch zu aufwändig. Ich denke aber ich werde die passenden Übergabeparameter aber schon vorsehen, so daß man da später von dieser Seite nichts ändern muß.

drohne235 hat geschrieben:Wer Lust hat kann natürlich mitarbeiten, dann geht das Ganze schneller. Und frühzeitige Mitarbeit sichert auch die Möglichkeit der Einflußnahme, denn spätere Programme werden wohl auf dieser Version aufbauen.

Ja, klingt sehr interessant. Freut mich sehr, dass es wieder weiter geht. Wenn es die Zeit erlaubt, bin ich dabei.

drohne235 hat geschrieben: - Das IOS bleibt nach wie vor nicht reentrant - das ist mir momentan noch etwas zu hoch und würde das IOS auch mächtig aufblähen scheint mir. Das bedeutet: Zugriffe auf die Systemroutinen (Datei, Bus, eRAM usw.) sollten nur zentral durch einen Prozess erfolgen.

Der Code muss nicht reentrant sein, wenn man beispielsweise so vorgeht:
Nur der Treiber-Cog greift auf die Hardware zu, z.B. SD-Karte.
Andere Tasks senden Nachrichten wie "Lies Sektor xyz" die in einer Liste landen und der Reihe nach abgearbeitet werden.

Der Bildschirmtreiber könnte beispielsweise virtuelle Fenster bereitstellen, in die mehrere Tasks gleichzeitig ihre Ausgaben schreiben können. Die Fenster könnten dann nebeneinander gleichzeitig angezeigt werden oder der Benutzer könnte wie bei Linux mit "ALT+F-Taste" zwischen mehreren Konsolen wechseln. Jeder Task würde dann eine Nachricht an den Bildschirmtreiber senden "Zeige Text xyz, Farbe yxz, Position zxy in meinem Fenster".

Gruß, oog

Der Code muss nicht reentrant sein, wenn man beispielsweise so vorgeht:

Da hast du recht. In diesem Schritt würde ich da auch nichts vorsehen. Wenn mehrere Tasks parallel auf die Ressourcen zugreifen, muß man eh eine einzelne Cog vorsehen, welche exklusiv die Kommunikation über den Bus zu den Slaves und dem externen RAM steuert. Alle Tasks dürfen dann nur noch über diese Buscog ihre Zugriffe erledigen. Dafür kann man dann später noch eine Softwareschicht über dem IOS einfügen, um diese Funktionen zu realisieren.

In der momentanen Version möchte ich mich noch nicht damit beschäftigen. Letztlich gibt es genug interessante Experimente die man mit so einem einfachen Systemmodell machen kann. Muß ja nicht immer alles multi und kompliziert sein... Mir schwebt da erstmal ein einfaches, übersichtliches und stabiles System vor, wie ich das so zum Beispiel vom Atari ST in Erinnerung habe - sollte ausreichend sein für viele Programme und Games. Da ist es dann manchmal sogar hinderlich und nimmt einem den Spaß und die Motivation, wenn man eine zu komplexe Ressourcenverwaltung hat.

Wenn es die Zeit erlaubt, bin ich dabei.

Das klingt super.

Ich würde auch gern mitarbeiten, bin mir aber nicht sicher, ob meine Kenntnisse und Erfahrungen ausreichen um wirklich etwas beitragen zu können.

Mitarbeit ist immer willkommen. Wenn du bei den beiden Software-Tutorials durchblickst, ist das technisch ausreichend denke ich. (Mit mehr Verständnis hab ich auch nicht angefangen.) Wenn nicht, dann einfach experimentieren und fragen: genau das ist ja der Zweck vom Hive. Selbst wer noch keinen Code für das OS selbst schreibt, bringt doch anderen Einsteigern einen Gewinn durch eigene Experimente und Fragen hier im Forum.

Wir werden für die Entwicklung ein Projekt auf google code einrichten. Ich hab gerade ein wenig reingeschnuppert und denke das wird so aussehen:

Projektname: trios (muss klein geschrieben werden als Projektname)
Zusammenfassung: SPIN-OS für die Parallax Propeller Architektur
Projektbeschreibung: In diesem Projekt wird ein experimentelles und einfaches Betriebssystem für einen auf drei Multicore-Mikrocontrollern P8X32A "Propeller" basierenden Computer entwickelt.

Versionskontrollsystem: SVN
Lizenz: MIT

Projekt-Labels: Parallax Propeller OS Hive


Als Versionskontrolle wird SVN und Mercurial angeboten.Hat noch jemand eine Idee zur Beschreibung? Sonst lege ich das Projekt heut abend an.