Seite 7 von 10
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: Sa 17. Jul 2010, 12:35
von drohne235
Für alle die Probleme hatten TriOS zum spielen zu bekommen, hab ich die Version nochmal aktuallisiert und überprüft, also die Bin's geflasht, eine neue Karte erstellt un getestet. Ich glaube einige Spielereien aus dem Demo-Ordner sind auch neu hinzugekommen - einfach mal schauen.
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: Do 5. Aug 2010, 18:30
von BorgKönig
Huhu Drohne235
bitte baue in den SD-Card Loader noch eine Routine ein, die eine Fehlermeldung auf dem Bildschirm anzeigt, wenn keine SD-Card eingelegt wurde, oder die Boot Dateien nicht geladen werden konnten. Alternativ reicht es, wenn alle HB- Leds blinken...
Der Grund dafür ist folgender: Ich hatte gestern das neue OS in die EPRoms geflasht, die SD-Card fertig gemacht und wollte heute etwas testen. Aber anstatt zu Booten, tat der Hive garnix. Einige tests haben gezeigt, das meine SD-Card defekt ist... Ich hatte heute die EPRoms erneut geflast, das war aber unnötig...
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: Do 5. Aug 2010, 20:06
von drohne235
BorgKönig hat geschrieben:Huhu Drohne235
bitte baue in den SD-Card Loader noch eine Routine ein, die eine Fehlermeldung auf dem Bildschirm anzeigt, wenn keine SD-Card eingelegt wurde, oder die Boot Dateien nicht geladen werden konnten. Alternativ reicht es, wenn alle HB- Leds blinken...
Das ist nicht ganz trivial: wenn das Medium nicht gemounted werden kann, wird auf der einen Seite kein Code gebootet in Regnatix & Bellatrix (kein Bild) und Administra hängt in der Routine zum Mounten fest. Da hilft auch kein Trap - denn der ist aktiv. Wenn du nun eine Card einlegst, hörst du vor dem Heartbeat ein kurzes "pling" (SoundFX7). Genau das ist die akustische Fehlermeldung. Keine (funktionierende) SD-Card ist halt ein ziemlicher Härtefall.
Schau dir dazu mal im admflash.spin im Verzeichnis "flash" die folgenden beiden Routinen an:
init_chip - Hier wird Administra initialisiert und versucht (sd_mount("B"), das Medium zu mounten.
sd_mount(mode)
Wie ich das sehe, müsste man die entsprechende(n) Routinen in der FATEngine selbst modifizieren, um den Fehler abzufangen. Vielleicht findest du ja eine Lösung!?
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: Di 10. Aug 2010, 08:55
von volkerp
Hallo Developer-Drohnen,
ich wollte das aktuelle TriOS ausprobieren. Leider scheitere ich am Laden es EEPROMs von Administra (egal ob über TriOS\hive-trios\flash\administra\admflash.spin oder direkt TriOS\hive-trios\bin\flash\admflash.binary): Das Propeller-Tool sagt nur "loading RAM, verifying RAM" und dann kommt die Fehlermeldung "Propeller Chip lost...". Was mache ich falsch bzw. wie macht ihr das?
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: So 22. Aug 2010, 20:32
von drohne235
Besteht das Problem immer noch?
Ich hab grad nochmal mit allen meinen Versionen (bin/spin bzw. bst/propellr tool) getestet - funktioniert bei mir. Ich würde auf ein Kommunikationsproblem tippen.
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: Mo 23. Aug 2010, 06:25
von volkerp
ich hatte dann mit BST geflasht - da geht das ohne dass der Propeller gleich neustartet.
Im Propeller-Tool war der Fehler reproduzierbar (bei Umstellung von Administra vom "alten" OS auf TRIOS)
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: Mo 23. Aug 2010, 08:22
von drohne235
BST ist eh die bessere Wahl. Mit den Optinierungen ist dein yplay nur noch halb so groß, da BST alle unbenutzten Routinen aus dem IOS nicht mit compiliert.
Aber das sollten wir mal im Hinterkopf behalten und wenn es reproduzierbar ist schauen wir spätestens mal beim KC-Treffen was da läuft. Wenn wir dann zwei Hives haben und das reproduzierbar auf einem geht und auf dem anderen Gerät nicht, dann sollten wir das auch weiter eingrenzen können.
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: Mo 20. Sep 2010, 22:37
von drohne235
18-09-2010-dr235 - fehler in bus_init behoben: erste eram-zelle wurde gelöscht durch falsche initialisierung
Manno, da hab ich lange nach gesucht...
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: Mo 27. Sep 2010, 19:30
von frida
Hallo drohne235.
Wo war der Fehler. Ist es etwas, das ich erstellt habe?
Ich bin bald fertig mit schnellen Lader in einer Woche.
HIVE 085
Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]
Verfasst: Di 28. Sep 2010, 20:08
von drohne235
Nein, keine Fehler in deinen Änderungen - die laufen alle korrekt!
Mir ist schon vor langer Zeit aufgefallen, dass nach einem Reboot oder Reset die erste eRAM-Zelle immer auf den Wert 0 gesetzt wurde. Zuerst dachte ich an ein Hardwareproblem, ein falscher Pegel auf der CS/WR-Leitung oder ähnliches.
Jetzt wurde die Situation aber etwas drängender: Die Speicherverwaltung/RAMDisk nutzt ja den Bereich ab Adresse 0. Zumal ich festgestellt hatte, dass die erste Zelle auch gelöscht wurde, nachdem der Loader ein neues Programm gestartet hat. Ursache war die Routine "bus_init" im IOS.
Die fehlerhafte Version:
Code: Alles auswählen
PUB bus_init 'bus: initialisiert bussystem
{{bus_init - bus: initialisierung aller bussignale }}
dira := db_in ' datenbus auf eingabe schalten
outa[18..8] := 0 ' adresse a0..a10 auf 0 setzen
outa[23] := 1 ' obere adresse in adresslatch übernehmen
outa[23] := 0
outa[reg_ram1] := 1 ' ram1 inaktiv
outa[reg_ram2] := 1 ' ram2 inaktiv
outa[reg_prop1] := 1 ' prop1 inaktiv
outa[reg_prop2] := 1 ' prop2 inaktiv
outa[busclk] := 0 ' busclk startwert
outa[bus_wr] := 1 ' schreiben inaktiv
outa[reg_al] := 0 ' strobe aus
Die neue Version:
Code: Alles auswählen
PUB bus_init 'bus: initialisiert bussystem
{{bus_init - bus: initialisierung aller bussignale }}
outa[bus_wr] := 1 ' schreiben inaktiv
outa[reg_ram1] := 1 ' ram1 inaktiv
outa[reg_ram2] := 1 ' ram2 inaktiv
outa[reg_prop1] := 1 ' prop1 inaktiv
outa[reg_prop2] := 1 ' prop2 inaktiv
outa[busclk] := 0 ' busclk startwert
outa[reg_al] := 0 ' strobe aus
dira := db_in ' datenbus auf eingabe schalten
outa[18..8] := 0 ' adresse a0..a10 auf 0 setzen
outa[23] := 1 ' obere adresse in adresslatch übernehmen
outa[23] := 0
Jetzt werden also die CS/WR-Signale korrekt auf inaktiv geschaltet, bevor die entsprechenden Ports auf Ausgabe und damit aktiviert werden.
Aber mnal was anderes:
Ich hatte die Idee im Loader (in PRI load) die sdgetblk-Funktion, statt einer Schleife mit sdgetc zu verwenden. Das müsste eine verdopplung der Ladegeschwindigkeit ergeben. Hat aber erstmal nicht geklappt. Vielleicht siehst du ja den Fehler - ich hänge die Version mal an.