HIVE-Project

Hallo!

trios :
Sehr schön! Alles Gute zur Kiellegung.
Kann man auch die Projekt-Homepage unter Google Code angeben? Die sollte in der Beschreibung eigentlich nicht fehlen. Auch die "Retro-(Game)-Geschichte" sollte nicht unerwähnt bleiben.

FATEngine :
Ich hab mir mal die FATEngine von "Kye" angesehen. Sehr übersichtlicher Aufbau und viele Kommentare. Für mich als Anfänger in Spin sehr gut geeignet. Ich werde jetzt mal versuchen, die "FATEngine" anstatt "fsrw" in die Webserver-Software von "Patricklab" zu integrieren und eventuell auch die Funktionalität des Webservers etwas zu erweitern. Vielleicht kann ich damit auch etwas für TriOS tun. Als alter Fortran-Programmierer war ich nie so dicht an der Hardware.
Welche Version von der FATEngine hast Du in Gebrauch? Ich habe mal die 51kB-Version, die als letztes im Thread angehängt war (http://forums.parallax.com/forums/attach.aspx?a=39095) ausprobiert. Funktioniert mit meiner 2GB-Card.

Was ich auch gut finde ist die Ein-/Ausgabe über COM-Port, müßte sich doch auch zum Debugging eignen.

Gruß
Günter

Sehr übersichtlicher Aufbau und viele Kommentare.

Genau das fand ich auch sehr schön. Ich werde mich wahrscheinlich an der Version mit der Bootoption orientieren, da wir dadurch natürlich eine saubere Bootfunktion für Administra quasi mitgeliefert bekommen - und diese Funktion ist wirklich noch ein grundlegender Baustein für den Hive. Wenn das integriert ist, haben wir die maximale Flexibilität erreicht: von allen drei Chips kann zur Laufzeit durch IOS-Aufrufe der Code ausgetauscht werden.

Das gelbe vom Ei wäre natürlich noch die Möglichkeit mit mehreren Dateien zu hantieren.

Hallo!

drohne235 hat geschrieben: Administra:
- Bootmechanismus für Administra
- Einbindung eines RTC-Chips
............

Welchen RTC-Chip hast Du vorgesehen?
Ich hab vor, auch in Zusammenhang mit dem Webserver, eine Huckepack-Platine für das EEProm zu machen und eine RTC in den Hive einzubauen.

Gruß
Günter

Ich werd mal mit dem DS 1307 (2,35 bei Reichelt) experimentieren. Im Anhang mal eine Schaltung die ich irgendwo aus dem Parallax-Forum geklaubt habe - find den Thread jetzt grad nicht. Da fehlt aber noch eine Pufferung mit einer Lithiumzelle.

drohne235 hat geschrieben:Ich werd mal mit dem DS 1307 (2,35 bei Reichelt) experimentieren.

Auch im eigenen Forum ist der DS 1307 sehr beliebt.

Zum Beispiel hier:
http://hive-project.de/board/viewtopic. ... =rtc#p2010
http://hive-project.de/board/viewtopic. ... =rtc#p3079

Ich habe mir letztens auch einen mitbestellt, aber noch nicht eingebaut. Das kommt dann noch...

Gruß, oog

Auch im eigenen Forum ist der DS 1307 sehr beliebt.

Jo, wir müssen das mal so stückweise alles ins Hive-Wiki überführen. Ich hab schonmal damit angefangen: Die Versionsverwaltung auf google-code ist eingerichtet und im Wiki hab ich einen Abschnitt für TriOS und mit den Infos zum Projektarchiv eingefügt:

Auch im eigenen Forum ist der DS 1307 sehr beliebt.

In Projektarchiv sind momentan aber erstmal nur die initialen Quelltexte für Administra auf dem aktuellen Stand und einige andere kleine Sachen. Muß da erstmal testen wie das alles funktioniert. Der Name trios (muß bei google code klein geschrieben werden) war schon von einem anderen Projekt auf sourforge vergeben. Das Projekt scheint zwar nicht mehr aktiv zu sein, aber die Verwendung des Namens wäre mit einer Rückfrageprozedur verbunden gewesen. So habe ich es einfach in "hive-trios" umgewandelt - geht ja auch als Projektname.

Bzgl. dem RTC müssen wir nur sehen, das wir möglichst die gleiche Lösung verwenden, aber Details können wir besser in dem anderen Thread besprechen.

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

Ähnliche Gedanken hab ich auch schon gehabt, das müssen wir mal weiter spinnen. An einigen Punkten bleibe ich dabei immer hängen:

1. Bestimmte Aktionen sind noch nicht teilbar (ich glaube das nennt man "atomar"). So zum Beispiel momentan noch die Dateioperationen. Da weder das fsrw, noch die FATEngine mehrere geöffnete Dateien unterstützt, würde es wenigstens bei der Dateiarbeit zu Konflikten kommen, wenn zwei Tasks auf unterschiedliche Dateien zugreifen wollen.

2. Wie "teilbar" ist zum Beispiel das Soundsystem, oder die Textkonsole? Zwei Tasks senden zum Beispiel Zeichen oder Strings zur Textausgabe: wie werden die dann gemischt? Oder muß man für jeden Task dann auch einen eigenen Textpuffer/Screen reservieren?

3. Wo genau zieht man genau die API-Verwaltungsschicht mit den Puffern im Hive ein? Man hat ja prinzipiell zwei Möglichkeiten:
A) In Regnatix, was bedeutet, das man für die Puffer und den Code auch hier Platz reservieren muß.
B) In den Slaves, wodurch Regnatix mehr Ressourcen frei hat.

4. Wie könnte man eine einfache und flache TriOS-Version ohne explizite Ressourcenverwaltung realisieren, die möglichst einfach (vielleicht nur durch eine entsprechende zusätzliche Softwareschicht realisierte) bessere Version erweitert werden kann. Das wäre wichtig für die Kompatibilität und die Realisierbarkeit. Gerade bei letzterem Punkt möchte ich realistisch sein: Ich bin kein Softwarespezialist und es ist sinnlos sich Sachen vorzunehmen, die man eh kaum realisieren kann - da muß man realistisch bleiben. Aber man will ja einen nächsten Schritt nicht unnötig behindern und jedesmal bei Null anfangen...

Mehr später, ich hab schon die Kisten für Pausin gepackt.

drohne235 hat geschrieben:... eine erste Version des TriOS zusammenzustellen
...die grobe Struktur zur Diskussion stellen
...vielleicht gibt es ja noch interessante Ideen dazu
...spätere Programme werden wohl auf dieser Version aufbauen.

Helft den verwirrten!

Das jetzige OS nennen wir doch Hive-OS, oder?
Ich frage mich gerade, ob ich den Aufruf zum TriOS falsch verstanden habe. Wollen wir das vorhandene OS erweitern oder gegebenenfalls etwas völlig neues auf die Beine stellen? Welche Ideen sind hier gefragt?

Ich gehe mal von der Annahme aus, dass wir das vorhandene OS weiterentwickeln. Dies dürfte den geringsten Aufwand erfordern. Für ein späteres OS kann man ja schon Ideen sammeln. Will man die Skizze mit den parallelen Tasks so verstehen, dass mehrere Hive-Anwendungen echt parallel laufen, so benötigt man einen komplett neuen Unterbau. Man könnte daran denken, auch andere (zukünftige) Hardware zu unterstützen. Auch dazu würde mir eine Menge einfallen.

Nehmen wir vorerst mal das vorhandene OS als Grundlage.
Wir können die vorhandene API erweitern, so dass man Programme wie einen Editor oder eine Command-Shell damit entwickeln kann. Einige Anforderungen dafür wurden bereits im Forum zusammen getragen.
Die Anforderungen an die API sollte man in einem eigenen Thread sammeln und diskutieren.

Hier ein Beispiel für Anforderungen an das OS, damit man einen Editor realisieren kann:

Funktion zum Ermitteln einer Dateigröße
Funktion zum Ermittel, ob eine Datei existiert
Funktion zum Anlegen einer neuen Datei
Reservieren von Speicherplatz im externen RAM (X-RAM)
Abfrage der Kommandozeilenparameter (wurde ein Dateiname angegeben?)
Anzeige einer Fileselectbox zum Laden / Speichern
Laden einer Datei von SD in das X-RAM
Speichern einer Datei vom X-RAM auf SD
Laden eines Speicherblocks vom X-RAM in den Hub-RAM
Speichern eines Speicherblocks vom Hub-RAM im X-RAM
Verschieben eines Speicherbereichs im X-RAM
Ermitteln der Größe des Bildschirms oder Fensters
Auswahl, Laden und Darstellen eines Zeichensatzes (wenn LCARS-Oberfläche unterstützt werden soll)
Abfrage der Cursorposition (X und Y getrennt)
Setzen der Cursorposition (X und Y gemeinsam)
Anzeigen / Blinken des Cursors ohne das darunter liegende Zeichen zu löschen

An Hive-OS oder TriOS Programme würde ich die Anforderung stellen, dass sie mit dem vom Benutzer gewählten Ausgabegerät zurecht kommen müssen. Der Benutzer gibt vor, ob er TV, VGA oder ein Terminal via RS232 angeschlossen hat. Der Editor muss in der Lage sein, den vorhandenen Bildschirm optimal zu nutzen.

Für optionale Menüs und eine Statuszeile sollten übergreifende Definitionen existieren, die eine einheitliche Bedienung von Hive-Anwendungen ermöglichen. Man kann sich an DOS-Programmen (SAA-Oberfläche) orientieren oder eine eigene sinnvolle Definition erstellen.
Wer möchte, kann ja ein paar Demo-Screens erstellen und als Foto in das Forum stellen. So kann man unterschiedliche Designs vergleichen und entscheiden, wie es später aussehen soll.

Um die Speicherverwaltung zu vereinfachen, kann man den Speicher in Blöcke einteilen, zum Beispiel in vielfache von 256 oder von 512 Bytes.
512 Byte Blöcke haben den Vorteil, dass genau ein Sektor von SD-Karte hinein passt.
256 Byte Blöcke haben den Vorteil, dass man sie mit einem einzigen Byte adressieren kann.

Es sollte eine Funktion zum _schnellen_ Laden und Speichern von Daten zwischen HUB-Ram und X-Ram geben. Die zu bearbeitende Datei lädt man dann in das X-Ram und überträgt von dort nur die gerade zu bearbeitenden Daten in das HUB-RAM. Will man mit mehreren Dateien gleichzeitig arbeiten, so müssen alle im X-RAM liegen, da SD-Karten-Treiber in der Regel nur eine Datei gleichzeitig öffnen können.
Der Lade- und Speichervorgang muss auf optimale Geschwindigkeit optimiert werden.

Gruß, oog

drohne235 hat geschrieben: 1. Bestimmte Aktionen sind noch nicht teilbar (ich glaube das nennt man "atomar"). So zum Beispiel momentan noch die Dateioperationen. Da weder das fsrw, noch die FATEngine mehrere geöffnete Dateien unterstützt, würde es wenigstens bei der Dateiarbeit zu Konflikten kommen, wenn zwei Tasks auf unterschiedliche Dateien zugreifen wollen.

Wir brauchen eine OS-Funktion, die jeweils eine komplette Datei in das eRAM lädt. Von da aus Können Tasks beliebig langsam und parallel auf "ihre" Datei zugreifen, ohne dass es andere Tasks stört.

drohne235 hat geschrieben:2. Wie "teilbar" ist zum Beispiel das Soundsystem, oder die Textkonsole? Zwei Tasks senden zum Beispiel Zeichen oder Strings zur Textausgabe: wie werden die dann gemischt? Oder muß man für jeden Task dann auch einen eigenen Textpuffer/Screen reservieren?

Ja, es gibt mehrere Möglichkeiten.
1) Ein Task, der Bildschirmausgaben nutzt, muss einen Puffer im Hub-RAM ablegen und schreibt dort hinein.
2) Ein Task "öffnet" ein Fenster auf dem Terminal (Bellatrix). Bellatrix legt einen Puffer an und sendet dem Task ein "Handle", also eine Zahl, welche auf den Puffer zeigt.
Bei Bildschirmausgaben übergibt der Task jeweils das Handle auf sein Fenster.
3) TriOS unterstützt eine Adressierung auf Task-Ebene. Der Zugriff funktioniert dann wie bei (2), wobei die Task-Adresse als Handle verwendet wird.
Zwischen den Fenstern kann man per Tastatur umschalten.

drohne235 hat geschrieben:3. Wo genau zieht man genau die API-Verwaltungsschicht mit den Puffern im Hive ein? Man hat ja prinzipiell zwei Möglichkeiten:
A) In Regnatix, was bedeutet, das man für die Puffer und den Code auch hier Platz reservieren muß.
B) In den Slaves, wodurch Regnatix mehr Ressourcen frei hat.

Wenn man bereit ist, sich von vorhandenen Strukturen zu lösen, baut man am besten ein Cog zu Cog Nachrichtensystem auf, das eine Adressierung über Propeller Chips hinweg erlaubt. Es hat dann Ähnlichkeiten mit einem Netzwerk und ist sehr universell, könnte also auch auf anderer Hardware laufen.

drohne235 hat geschrieben:4. Wie könnte man eine einfache und flache TriOS-Version ohne explizite Ressourcenverwaltung realisieren, die möglichst einfach (vielleicht nur durch eine entsprechende zusätzliche Softwareschicht realisierte) bessere Version erweitert werden kann. Das wäre wichtig für die Kompatibilität und die Realisierbarkeit. Gerade bei letzterem Punkt möchte ich realistisch sein: Ich bin kein Softwarespezialist und es ist sinnlos sich Sachen vorzunehmen, die man eh kaum realisieren kann - da muß man realistisch bleiben. Aber man will ja einen nächsten Schritt nicht unnötig behindern und jedesmal bei Null anfangen...

Am einfachsten ist, man setzt auf dem vorhandenen OS auf und überarbeitet die API. Die ist für Programme erst mal am wichtigsten.

HIVE-Project

TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]

Re: TriOS

Re: TriOS

Re: TriOS

Re: TriOS

Re: TriOS

Re: TriOS

Re: TriOS

Re: TriOS

Re: TriOS

Re: TriOS