HIVE-Project

Habe schon einige Zeit nicht mehr ins Forum geschaut (so 1 Jahr ). Habe auch nicht mitbekommen das es eine neue Sammelbestellung gibt.

Jetzt das ich wieder mal Zeit habe und der Winter kommt, wollte ich mal wieder einsteigen.

Ist die neuste TriOS Version abwärts kompatibel mit der ersten Hive Version (R13)?

ben hat geschrieben:Habe schon einige Zeit nicht mehr ins Forum geschaut (so 1 Jahr ). Habe auch nicht mitbekommen das es eine neue Sammelbestellung gibt.

Jetzt das ich wieder mal Zeit habe und der Winter kommt, wollte ich mal wieder einsteigen.

Ist die neuste TriOS Version abwärts kompatibel mit der ersten Hive Version (R13)?

Na klar, ich hab es ja uch noch auf dem ersten Board laufen. Die neue Platine hat einige kosmetische Korrekturen und Verbesserungen und einen RTC.

Hallo allerseits!
Gestern hab ich mal nach langer Zeit den Hive wieder an Tastatur, Bildschirm und Spannungsversorgung angeschlossen und ihn mit dem neuesten TriOS gefüttert. Mit dem VGA-Treiber (1024 x 768) war mein TFT-Bildschirm mal wieder nicht zufrieden und meinte einige Zeilen verschlucken zu müssen. Ursache ist die Einstellung im Treiber auf 57Hz nicht 60Hz ( in bel-vga.spin) wie eingetragen. Diese Mimosenhaftigkeit habe ich ihm dann mit den Einstellungen für 60Hz bei einer Auflösung von 1024 x 768 aus der in dieser Seite angegebenen Tabelle http://web.mit.edu/6.111/www/s2004/NEWKIT/vga.shtml ausgetrieben. Sodele, er läuft jetzt richtig und ich werde in den nächsten Wochen neben anderen Propellereien mal ein wenig mit dem TriOS spielen. Leider habe ich keinen Videobildschirm, so daß ich leider die schönen Grafiken aus dem Toolpaket nicht ausprobieren kann.
Beim Füttern des Hive ergab sich folgendes Problem :
Beim Compilieren des Files "regflash.spin" im Verzeichnis "TriOS/flash/regnatix" erschien der Fehler in Zeile 63/2 : Unresolved Symbol - define
Da ich diesen Fehler nicht lösen konnte, habe ich "regflash.binary" aus dem Verzeichnis "TriOS/bin/flash" ins EEProm geladen.

Gruß
TuxFan

TuxFan hat geschrieben:Beim Füttern des Hive ergab sich folgendes Problem :
Beim Compilieren des Files "regflash.spin" im Verzeichnis "TriOS/flash/regnatix" erschien der Fehler in Zeile 63/2 : Unresolved Symbol - define
Da ich diesen Fehler nicht lösen konnte, habe ich "regflash.binary" aus dem Verzeichnis "TriOS/bin/flash" ins EEProm geladen.

Du kompilierst brav mit BST, wie es in der Install-Anleitung steht?
Ich vermute mal, daß nicht... und daher wird das #define in selbiger Zeile bemängelt...

Sieht wirklich nach bst aus.

Zur Video-Tabelle: Ich kann diese Einstellungen für den VGA auch als alternative Konfiguration ins TriOS aufnehmen und konfigurierbar machen. Dann brauchst du nur die entsprechende Konf aktivieren.

Hallo!

Als ganz schlimmer Tux-Jünger bleibt mir nur BST. Hab ich da irgendeine Einstellung verpennt ?

PS.: Au weia, hab jetzt mal unter "Tools...Optimisations....Non Parallax compatible Extensions" angewählt und dann scheint es zu funktionieren. Das hab ich bis jetzt noch nie benutzt.

Die Videoeinstellungen im Sourcecode anpassen ist nicht so tragisch. Ich wollte das nur mal anmerken falls noch jemand mit seinem TFT solche Anzeigeprobleme hat. Mein Bildschirm ist halt etwas penibel mit der 60Hz Einstellung.

Gruß
TuxFan

Die Optimierungen solltest du beim bst alle einschalten. Gerade in Verbindung mit dem IOS ist das pures Gold (spart massig hRAM), da der Compiler alle unbenutzten Routinen nicht einbindet. So ist es überhaupt erst möglich, allen "Krempel" mit ruhigem Gewissen in eine zentrale Datei zu stecken.

drohne235 hat geschrieben:Die Optimierungen solltest du beim bst alle einschalten. ........

Bedankt.
Wie man sieht lernt man nie aus......

Gruß
TuxFan

drohne235 hat geschrieben:Die Optimierungen solltest du beim bst alle einschalten. Gerade in Verbindung mit dem IOS ist das pures Gold (spart massig hRAM), da der Compiler alle unbenutzten Routinen nicht einbindet.

Jo... schon pfiffig...

drohne235 hat geschrieben:So ist es überhaupt erst möglich, allen "Krempel" mit ruhigem Gewissen in eine zentrale Datei zu stecken.

...aber ob die Tendenz zu Megafiles wirklich so stilbildend und übersichtsfördernd ist?

Egal!

Was mir noch querer im Magen liegt ist das Abtauchen des BST-Autors und die ausbleibenden Bugfixes...

Es ging mal die Kunde rund, Mister BST hätte aufgrund eines schleichenden Festplatten-Verrottens die Quellen verloren... den Beitrag im großteichjenseitigen Propellerforum finde ich aber nicht mehr.

Ich hielt BST daher schon komplett für tot und somit meidenswert, stolperte dann aber hierüber:

http://forums.parallax.com/showthread.php?129328&p=1051440&viewfull=1#post1051440 hat geschrieben:I've asked Brad for PST-compatibility in his terminal and it seems to be in process -- will help me with a book project I'm working on as I'd like Mac and Linux folks to be able to do the same formatted output that I frequently do with PST (i.e., without resorting to TV or VGA output).

Diese vom 14.11.2011 stammenden Zeilen lassen dann doch wohl wieder etwas Hoffnung aufkeimen, daß BST nicht im digitalen Nirwana verschwunden ist... ich werd's aber bis zum Beweis der Wiederauferstehung mit skeptischem Blick betrachten...

Mir wäre auch lieber, wenn diese Features von Parallax auch in das Propellertool eingebaut würden. Zumal mir die optische Anzeige der Verschachtlung dort sehr gefällt. Eine sehr gute Variante die Programmstruktur sichtbar zu machen. Außerdem kann man im BST keine Lesezeichen definieren.

Thema Megafile/IOS: Hab ich auch lange drüber nachgedacht und denke die aktuelle Struktur ist da ein optimaler Kompromiss. Natürlich wäre es schöner, wenn man thematisch zusammengehörige Routinen in getrennte Objekte packen würde. Das wäre übersichtlicher und man hätte getrennte Namespaces. Aber alle diese Objekte haben etwas gemeinsam: sie greifen über den Bus auf Ressourcen zu, was bedeutet, sie benötigen entsprechende Routinen um Byte/Word/Long/Block Daten über den Bus empfangen und senden zu können. Im Prinzip sind diese Routinen dann in allen Objekten einzeln vorhanden (wenn man getrennte Objekte verwendet) und werden damit mehrfach compiliert und verbrauchen auch mehrfach Speicher. Da ist das Objektkonzept des Compilers nicht ausgefeilt genug. Nun ist aber gerade hRAM nicht unbegrenz vorhanden, weshalb ich mich beim TriOS für diese Variante entschieden habe. In der jetzigen Version nutzen halt alle Funktionen die gleichen und nur einmal im Speicher befindlichen Routinen für den Bus. Nachteil: Man muß alles in eine Datei packen UND der BST ist zwingend nötig.

Zumindest bzgl. der Übersichtlichkeit ist das aber nicht ganz so schlecht, wie es im ersten Augenblick scheint: Wenn man im BST die Routinen einfaltet (geht mit einem Mausklick), sind alle Routinen mit entsprechenden aussagekräftigen Kommentaren versehen und man hat damit quasi ein Inhaltsverzeichnis um schnell Funktionen zu finden. Ich habe auch entsprechende Dummy-Blöcke eingefügt, um mit gelben Zeilen Funktionsgruppen und mit roten Zeilen die Chips abzugrenzen. Man kann wirklich ziemlich schnell damit arbeiten. Hab mal ein Screenshot angehängt.

Und wie gesagt: mit dem BST werden ja nur die Funktionen compiliert und im Speicher gehalten, welche auch wirklich verwendet werden. Im Extremfall - zum Beispiel beim "Hallo Kollektiv!"-Demo belegt das IOS-Objekt nur wenige Byte im Speicher!

Und nicht die definierbaren Suchpfade im BST zu vergessen: nur so kann man wirklich die Libs in einen eigenen Ordner packen und kann sie auch zentral verwalten! Auch so eine Sache die im Propellertool fehlt, welches einfach nicht für größere Projekte ausgelegt ist.

Edit: Letzter Post von BradC ist vom 14.10.2011 - es gibt also Hoffnung.