TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]

[frida]

Hallo drohne235

Ja, es war nur in busroutinen regflash geändert.

Ich denke, es hat etwas mit dem Timing zu tun.
Siehe meine Lösung in der Jobliste.
Aber ich sehe eine Lösung. Ich arbeite daran.

drohne085

[drohne235]

Ich denke, es hat etwas mit dem Timing zu tun.
Siehe meine Lösung in der Jobliste.
Aber ich sehe eine Lösung. Ich arbeite daran.

Der Fehler ist in der zweiten Version der bus_init-Routine schon behoben. Ursache war, das erst die Ports auf Ausgabe geschaltet und DANACH erst initialisiert wurden. So gab es einen kurzen Impuls auf /CS & /WR und die erste Zelle im externen RAM wurde überschrieben.

In der zweiten Version der Routine werden erst die Signalports initialisiert und danach auf Ausgabe geschaltet - das funktioniert ohne Störungen.

Ist also alles soweit ok, ich müsste nur mal den aktuellen Stand zusammenfassen und hier wieder mal posten.

[frida]

Code: Alles auswählen

' ---- blockversion

  bus_putchar1(SD_GETBLK)
  bus_putlong1(plen)
  ii := 0 ' ii auf Null setzen,dann wird es funktionieren
  repeat plen
    byte[progptr][ii++] := bus_getchar1

Hallo drohne235

Versuchen Sie diese

drohne 085

[drohne235]

Neues Archiv mit der aktuellen Arbeitsversion:

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!

Speicherverwaltung:

In dieser Version ist eine erste experimentelle Version der Speicherverwaltung des externen RAM's. Der Speicher kann dabei in einem einfachen oder einem strukturierten Modus verwendet werden. Klingt kompliziert, ist aber ganz einfach.

Einfacher Modus:

Hier kann ein Programm auf den eRAM über die IOS-Routinen ios.ram_* zugreifen. Im einfachsten Fall kann der Speicher im Systemmode direkt von 0 bis $07FFFF angesprochen werden. In diesem Modus ist darauf zu achten, dass eine eventuell vorhandene Ramdisk und die Systemvariablen nicht überschrieben werden. Die Ramdisk wird ab der physischen Adresse 0 als verkettete Liste verwaltet, die Systemvariablen befinden sich ab $07FFFF abwärts.

Code: Alles auswählen

ios.ram_wrbyte(ios#sysmod,0,ios#MAGIC)		- Schreibt den Wert 0 in die Systemvariable, um einen Kaltstart auszulösen.
ios.ram_wrbyte(ios#sysmod,$20,$100)		- Schreibt den Wert $20 an die physische Adresse $100 im eRAM.

Da es nun mühsam ist in einem kleinen Code solche Konflikte mit dem Systemspeicher zu vermeiden, gibt es den Usermodus. Im Usermodus wird nur genau jener freie Speicher adressiert, welcher sich zwischen Ramdisk und Systemvariablen befindet. In diesem Fall ist die Adressierung also virtualisiert.

Code: Alles auswählen

ios.ram_wrbyte(ios#usrmod,0,$100)		- Schreibt den Wert 0 an die Adresse $100 im Userspeicher!

In Regime kann man mit dem Kommando "free" jetzt auch die wichtigsten Systemvariablen der Speicherverwaltung anzeigen.

Code: Alles auswählen

RBAS		- Erste physische Adresse des Userspeichers
REND		- Physische Adresse der letzten freien Speicherstelle des Userspeichers.
USER		- Grösse des Userspeichers (REND - RBAS).
RAMDRV	0 - Ramdisk ist nicht initialisiert
		1 - Ramdisk ist initialisiert
SYSVAR	- Erste physische Adresse der Systemvariablen.

Noch genauer kann man sich die Speicherbelegung mit dem tool "eram" anschauen. Nur ein paar Beispiele:

Code: Alles auswählen

d	- Anzeige des Speichers. Es werden zwei Adressspalten angezeigt. Die zweite schwarze Adresse zeigt die physische Adresse, die zweite grüne Adresse die virtuelle Adresse im Userspeicher. 
d 100	- Anzeige ab physischer Adresse $100
d bas	- Anzeige vom Start des Userspeichers.
n 	- Anzeige inkrementell fortsetzen

Die Nutzung des Userspeichers ist sehr einfach. Es sind dabei nur folgende Regeln zu beachten:

• Man muss selbst darauf achten die Speichergrenzen nicht zu überschreiten. Bei überschreitung kann aber nichts passieren - die IOS-Routinen brechen einfach ab, allerdings werden die eigenen Daten halt nicht korrekt verarbeitet.
• Der Userbereich im eRAM ist nur zur Laufzeit der Anwendung gültig. Wird die Anwendung beendet, so kann durch Regime oder eine andere Anwendung mit den Daten der Ramdisk gearbeitet werden, wodurch sich der physische Bereich des Userbereiches verändert. Wer also rsidente Daten braucht, muss im strukturierten Modus mit der Ramdisk arbeiten.
• In einer Anwendung nicht den einfachen oder strukturierten Modus mischen - das gibt Chaos, wenn man nicht ganz genau aufpasst

Ansonsten kann man wie gehabt die schon bekannten IOS-Routinen verwenden, einzig der Übergabeparameter zur Wahl des System- oder Usermodus ist hinzugekommen. Als Beispiel kann man sich die Soundplayer anschauen, die ihre Dateiliste im Userspeicher ablegen.

Strukturierter Modus:

Was ist aber wenn wir einen kleinen Texteditor schreiben wollen, der seine Textdaten resident im eRAM speichern kann? Ich möchte also den Texteditor verlassen können, um in Regime zum Beispiel einen Assembler aufzurufen, welcher den Text dann assembliert. Dafür muss es meier Anwendung - dem Textprogramm - möglich sein, einen Speicherbereich im eRAM zu reservieren, der von System und anderen Anwendungen respektvoll behandelt wird.

Gedacht, getan: Im strukturierten Modus wird der Speicher in Form einer Ramdisk verwaltet. Die Dateien/Daten können über ihren Namen angesprochen werden. Es kann mit put & get sequentiell, oder mit read & write adressierbar auf die Daten in der Datei zugegriffen werden.

Als erstes praktisches Beispiel mögen die neuen Kommandos in Regime selbst dienen, mit denen man die Ramdisk verwalten kann:
Neue Regime-Kommandos:

Code: Alles auswählen

xload <sd:fn>           - datei in ram laden
xsave <x:fn>            - datei aus ram speichern
xdir                    - verzeichnis im ram anzeigen
xrename <x:fn1> <x:fn2> - datei im ram umbenennen
xdel <x:fn>             - datei im ram löschen
xtype <x:fn>            - text im ram anzeigen

So ist es also möglich, sich in der Kommandozeile anzuschauen, welche residenten Daten die Programme aktuell angelegt haben. Sofern es Textdaten sind, können diese Daten auch einafch angezeigt werden.

Die Speicherverwaltung ist allerdings noch sehr experimentell - was bedeutet, dass wohl noch einige Bugs drin sein dürften.

MAKE.BAT

Diese Batchdatei im obersten Verzeichnis kompiliert das Grundsystem, bestehend aus den drei Flashdateien und den grundlegenden Kommandos im Systemverzeichnis. Ist ein erster Versuch. Was noch fehlt ist ein Fehlerlog und vielleicht noch die anderen Programme.

[stesch99]

Hallo Drohne235!

Ich habe Deine aktuelle Version vom TRIOS aufgespielt.

Ich habe den Effekt, daß ein Hardwarereboot über den Resettaster den HIVE nicht mehr neu startet.
Ein Neustart funktioniert nur, wenn ich die Stromversorgung kurz wegnehme.

Ich nutze noch das Propeller-Tool 1.2.7(R2) und nicht den BST.

Kannst Du diesen Effekt bei Dir reproduzieren oder habe ich einen Störeffekt
auf meinem HIVE?

Gruß Steffen

[drohne235]

Ich habe den Effekt, daß ein Hardwarereboot über den Resettaster den HIVE nicht mehr neu startet.
Ein Neustart funktioniert nur, wenn ich die Stromversorgung kurz wegnehme.

Das Verhalten ist momentan richtig so, kann sich aber noch ändern. Zur Erklärung:

Durch die Integration der Ramdisk habe ich nun eine Unterscheidung zwischen Kalt- und Warmstart insofern verbessert, dass bei einem Warmstart die Ramdisk, und damit die resisdenten Daten von Anwendungen, erhalten bleiben. Die Unterscheidung findet über eine Systemvariable im eRAM statt (ios#magic == 0|235). Bei dem Wert 0 wird ein Kaltstart ausgeführt, und damit auch Ramdisk neu initialisiert und Bellatrix mit Code versorgt. Bei dem Wert 235 wird momentan nur Regnatix neu gestartet.

Wenn man nun Reset drückt starten alle deri Propeller neu, aber der eRAM behält seinen Wert, was bedeutet, ios#magic enthält den Wert 235 und Bella bekommt keinen Code. Ich denke grad noch darüber nach, wie man das realisieren kann, ohne das es unnötig kompliziert wird. Ansonsten gibt es noch das Kommando "reboot" in Regime - dort kannst du dann wählen ob Klat- oder Warmstart.

[frida]

Hallo drohne235
Ich habe eine Lösung auf Hardware-Neustart.
Es kommt mit schnellen Lader.
Ich muss Funktion 31 in der ADMINISTRA verwenden, wenn Sie nichts dagegen haben, für SD_BIN.

Haben Sie ein wenig Geduld noch.

frida

[drohne235]

Ich habe eine Lösung auf Hardware-Neustart.

Ich liebe diesen Satz...

Ich muss Funktion 31 in der ADMINISTRA verwenden, wenn Sie nichts dagegen haben, für SD_BIN.

Ist ok.

[frida]

Sehen Sie in der Job-Liste

frida

[drohne235]

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/