drohne235 hat geschrieben: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.
...
- 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.
Ich greife noch mal das Problem nicht reentranter Funktionen auf, wobei es mir nicht ausschließlich darum geht. Bei einer Überarbeitung des OS hat man die Möglichkeit, die Architektur zu überdenken und zukünftige Anforderungen so gut wie möglich zu berücksichtigen.
Um Probleme bei gleichzeitiger Nutzung von Hardware durch unterschiedliche Tasks zu vermeiden, bräuchte man eine Art Nachrichtensystem.
Jeder Task erzeugt für einen Betriebssystemaufruf eine Nachricht, die er in einem Ausgabepuffer ablegt. Ist der Ausgabepuffer nicht frei, muss er warten.
Ein Kommunikations-Task liest die Nachricht aus dem Ausgabepuffer und sendet sie an den zuständigen Cog. Dazu muss die Nachricht ggf. über den externen Bus zu einem anderen Propeller übertragen werden. Anschließend markiert er den Ausgabepuffer als frei.
Anmerkung:
Dies ist für den Task vollkommen transparent und erfordert keine Änderung der API oder der Programme. Ob das OS direkt ein Unterprogramm startet oder eine Nachricht verschickt, ist ja egal. Das Hive-OS macht es bei der Kommunikation zwischen unterschiedlichen Propeller-Chips auch schon so ähnlich. Die Adressierung der Chips erfolgt hierbei über die entsprechende Chipselect-Leitung.
Am Ziel angekommen wird die Nachricht in den Eingangspuffer des zuständigen Cogs gelegt. Ist der Eingangspuffer belegt, landet die Nachricht in einem globalen Zwischenlager (LOL - tolles Wort).
Falls dieses Überläuft gibt es eine Fehlermeldung auf den Konsole. Konflikte bei Hardware-Zugriffen gibt es hier nicht.
Man könnte sich noch eine Adressierung überlegen, um weitere externe Propeller zu erreichen, z.B. das magische Auge.
Damit wäre man in der Lage, beim Booten alle möglichen Adressen abzufragen und anzuzeigen, wer sich meldet, z.B. so:
Code: Alles auswählen
Hive - Booting TriOS...
Scan P-BUS
Address 0: Regnatix
0: Loader 1: P-BUS
2: X-RAM (1024K) 3: Editor
4: free 5: free
6: free 7: free
Address 1: Administra
0: P-BUS 1: Sound output (L+R)
2: I2C-BUS 3: RTC
4: SD-CARD 5: free
6: free 7: free
Address 2: Bellatrix
0: P-BUS 1: Video (40*25)
2: Keyboard (GR) 3: Mouse
4: free 5: free
6: free 7: free
Scan I2C-BUS
Address 3: MagicEye
0: I2C-BUS 1: SD-CARD
2: Sound (L+R) 3: RotoDisplay
4: free 5: free
6: free 7: free
Mit der Möglichkeit einer Adressierung wären weitere Hardwareerweiterungen leicht zu integrieren.
Außerdem wäre es auch besonders einfach, mehrere Anwendungen parallel zu betreiben und die Konsole einfach zwischen den aktiven Tasks umzuschalten.
Die Entwicklung von TriOS umfasst auf jeden Fall mehrere Aspekte:
Architektur
- Wie modular und flexibel soll es sein?
- Soll Trios auch auf anderer Hardware laufen können?
- Ist eine spätere Anpassung an den Propeller2-Chip erwünscht?
API
- Anforderungen an die Schnittstelle für Funtionsaufrufe
Link
- Anbindung weiterer Cogs und Adressierung
- Erkennung neuer Hardware (Plug and Play)
Hardware
- Anbindung externer Hardware über I2C, seriell oder...
- Definition eines BUS-Steckers
Für Ideen und Wünsche zu OS-Funktionen schlage ich vor, einen neuen Thread, z.B. "TriOS-API-Wunschliste" zu erstellen. So lassen sich die Vorschläge besser kanalisieren und wiederfinden.
So, ich drück jetzt mal auf Absenden, auch wenn ich mit der Darstellung noch nicht ganz glücklich bin. Schöner wird's heute nicht mehr.
Gruß, oog
