drohne235 hat geschrieben:Ich verwende PASD, damit kann man recht komfortabel arbeiten. Bei Gear hat mir immer die Anbindung direkt an die Infrastruktur im System gefehlt.
[1] TriOS
Vielleicht konnen wir anfangen mit das eRAM in zwei Teilen: 0.5MB fur TriOs und Ramdisk und 0.5MB fur XMM. Programme werden gestarted etwas wie
"cvm <program>" und "tcc <program>". Die Spin Programmen "tcc" bzw. "cvm" laden <program> ins eRAM xmm Bereich, starten eine Cog mit dem CPU Kode und gehen dan in eine OS loop. Die OS Befehle in run_cvm.spin sind meiner Meinung nach eine quick fix von Bellard, die Liste in Zog seht sich besser aus. Etwa 20 OS funktionen reichen aus fur ein mini-OS. Ein solches mini-OS greift dan wieder zu auf TriOS Bibliothek reg-ios.spin.
Das ist eine sehr gute Idee. TriOS kann man recht einfach auf die unterste RAM-Bank einschränken. Ich würde das in reg-ios per #define und bedingter Compilierung konfigurierbar machen. Wenn XMM dann die obere RAM-Bank nutzt, ist auch der Code für die Ansteuerung wesentlich einfacher. Und sowohl für TriOS als auch für die XMM-Sachen sind 512 KB ausreichend denke ich.
Hm warum so statisch?
Eine Stelle bestimmen, an der die Bereiche stehen entweder vorne im eRam , oder hinten, besser wäre es in den zuständigen Propeller. Dort eine tabelle an der z.B. steht
Anfang adresse ram ,End adresse ram, Bits, 3 byte ID
Also z.b.
$1000 chksum bit, Anz, "go" ; Blockgröße, Checksumme ;erste eintrag sondereintrag
$00000 $01fff $40 "TIO" ; trios
$02000 $03FFF $40 "XMM " ;xmm
$04000 $07FFF $01 "FRE" ; freier, unbenutzer speicher
$08000 $09FFF $41 "RES" ; reserviert könnte z.b. im eeprom stehen wo sich XMM später einträgt
$0A000 $0A2FF $4 "DIR" ; block der auf eine erweiterung dieser tabelle zeigt (für später mal)
$00000 $chksum $81 "EOF" ;ende markierung entweder hier die checksumme oder am anfang nicht beides
$06000 $xxxxx ; Checksum um die gültigkeit zu überprüfen
Eine Voreinstellung davon steht im hinten im eeprom, sprich wie es nach einem Kaltstart eingestellt wird.
So kann man jederzeit den Speicher anpassen wie an möchte, ohne neu zu übersetzten. die daten im eeprom ändern und Neustart.
Als Bits wäre denkbar $01 dynamischer wert,$02 temporäre daten (z.b. xmm brauch mal viel platz dann holt es sich noch was vom free-Bereich und gibt es später wieder frei), $40 fixer wert, darf im betrieb nicht verändert werden erfordert neustart, ,...
die Bits die nicht benötigt werden, bleiben erst mal frei.
Die Endekennung macht ob mit nem Bit z.B. $80, oder der Kennung eof, oder wenn Anfangsadresse gleich null, oder alles drei.
Die Checksum, wird über alle Einträge gemacht, z.b. EOR über alles mit funnycompliment $aa550ff0. damit wäre es z.b. möglich einen Warmstart zu machen. auf jedenfall könnte man damit die Gültigkeit sicherstellen.
das letzte Byte bei der Größe könnte man weglassen, oder man legt ne Blockgröße fest, z.b. 4KB in der der Speicher vergeben wird. dann reichen 16 Bitwerte für Anfang und ende.
Im eeprom könnte eine etwas abgewandelte Tabelle stehen, z.b. wenn anfangsadresse leer ist, steht eine länge bei der Endadresse. statt XMM steht res dort, und xmm trägt sich dann dort (aber nur im ram) ein wenn es verwendet wird, sollte aber xm2 verwendet werden (nur mal als beispiel), trägt sich das dort im ram steht auch ein. wenn es den Bereich wieder freigeben kann trägt es wieder res ein. dort könnten auch Daten stehen wie lang die Tabelle ist, z.b. 4 einträge, Speichergröße, wo die Tabelle im ram steht. Die Tabelle im eeprom könnte kleiner sein.
das ganze kann man sich so ähnlich vorstellen wie die Partitionstabelle bei ner Festplatte.
Vorteil, man könnte mit beliebigen Speicherausbau arbeiten, und die größen jederzeit schnell anpassen ohne neu kompilieren zu müssen.
Wie die Tabelle dann konkret aussieht, sollte man diskutieren z.B: welcher Bedarf existiert, und was sinnvoll ist,auf jeden Fall sollte sie offen für Erweiterungen sein, das ganze ist jetzt nur mal so grob, hingeschrieben.
