Wohin gehts mit dem Hive?

[zille9]

War ja auch nicht so ernst gemeint,

Hab ich auch nicht so empfunden.

Ich werde es halt einfach mal an einem Beispiel umsetzen müssen. Entweder verstehst Du dann, was ich meine oder ich merke, daß meine Idee nicht funktioniert...

Das wird das beste sein, so lernen wir beide was und vielleicht kannst Du mich ja bekehren.

[drohne235]

Ich habe mir mal zu den verschiedenen Themen hier Gedanken gemacht:

joergd & zille9:

Ich glaube ihr liegt da dichter beisammen als ihr denkt und habt nur eine verschiedene Perspektive. Im Bellatix-Code haben wir schon eine entsprechende Verbindung verschiedener Codeversionen, denn dort wird sowohl TV als auch VGA-Modus miteinander verwoben. Schön wäre naürlich auch ein derartig modularer Code für die verschiednen Administra-Versionen. Aber um bei Bella zu bleiben: Bei TV und VGA-Modus funktioniert das so gut, weil es beides ähnliche Textmodis sind. Schon beim G0-Grafiktreiber könnte ich mir eine ähnliche Integration schlecht vorstellen.

Ebenso scheint es mir unter TriOS nicht praktikabel zum Beispiel Plexus zu integrieren. Ich möchte erstmal schreiben, warum ich das denke, später verrate ich dann, warum Jörgs Idee aber auch nicht SO falsch ist...

Nun, der Grund warum Plexus und TriOS (oder auch mental) nicht so einfach zusammenwachsen können und müssen ist ihr Betriebssystemcharakter. Man kann den Hive aus dieser Perspektive als einfachen Computer ansehen - ich nenne das mal die 8-Bit-Klasse, obwohl der Hive natürlich alles andere als ein 8-Bitter ist, aber es geht mir mehr um die Struktur. Bei diesen Geräten gab es kein wirklich ausgewachsenes OS, sondern nur eine Ansammlung von Routinen im ROM, die Programme konnten die volle Kontrolle über das System übernehmen und musste(!) das auch tun. Das Programm selbst war also mehr oder weniger das OS. So ist es mit TriOS, Plexus.

Aber das Fehlen eines OS auf dieser Ebene ist ja auch eine positve Sache: Es ist halt alles sehr einfach und man kann ohne viel Aufwand selbst die Kontrolle übernehmen. Genau das ist doch aber auch das coole auf dieser Ebene: es ist einfach wie auf einem 8-Bitter, hat aber mehr Dunst unter der Haube. Wo man auf einem C64 noch Assembler bemühen musste, kann man die gleichen oder bessere Sachen hier einfach in Spin oder Basic realisieren.

Jörgs Ansicht ist aus zwei anderen Perspektiven richtig: Der Administra-Code von TriOS (nicht von Plexus!) für die verschiedenen Funktionsvariante könnte wie bei Bella modular werden. So könnte man alle Variationen in einer Datei pflegen. Ändere ich also etwas am FAT, so wäre es automatisch in allen Variationen aktualisiert. Ist aber eine Menge Arbeit, den Anfang habe ich schon gemacht, indem alle Funktionsnummern in die globale Konstantendatei gewandert ist. Ich hatte sogar schonmal einen ersten modularen Code gebastelt, aber da gingen dann subtile Sachen mit dem Sound nicht. Ist eine Menge Holz, darf nicht unterschätzt werden das!

Das wäre die erste Perspektive. Die zweite Perspektive ist noch spannender: TriOS ist die Einstiegsdroge; was wenn man, basierend auf einem PASM-Backbone, ein "echtes" OS mit Ressourcenverwaltung, Treibern, echten parallel laufenden Programmen, mehreren Screens/Fenstern schreibt? Das wäre doch mal eine Herausforderung für die Softwarspezilisten, ich selbst bin da noch nicht so weit. Meine Ebene ist 8-Bit-Klasse, also TriOS. Aber TriOS gibt so ein Konzept prinzipiell nicht her, Trios ist zu einfach gestrickt, TriOS ist Spin und das solte für die Einsteiger auch so bleiben. Fakt ist aber auch: So ein neues OS ist dann natürlich noch mehr Holz und deutlich komplexer, denn viele Codeobjekte aus dem OBEX müssen dann neu erfunden werden, böte aber das Potential, den Hive richtig auszunutzen. Und warum sollte so eine Sache nicht per GIT versioniert werden? Immer ran da, macht ein Projekt dort auf und los geht es!

Zur Frage "Was machen die vielen Drohnen mit ihrem Hive": Ich vermute, nicht jeder will unbedingt programmieren, und das ist auch ok so. Viele bauen den Hive, weil der Aufbau selbst schon Spaß macht, weil sie sowas schon immer mal machen wollten, und weil sie aus ihrer Jugend die ersten Gehversuche auf einem Eigenbau oder einem 8Bitter gemacht haben. Muss man akzeptieren, ist dann wie im Modelbau, wenn man sich die kleinen Schiffchen, Flugzeuge und Todessterne zufrieden in die Vitriene stellt. Ich hab's am Anfang auch nicht verstanden, weil ich selbst da ja auch anders gestrickt bin - für mich beginnte die Sache erst nach dem Aufbau, ich wollte basteln und programmieren wie in alten Zeiten und ganz unabängig sein. Ich habe es entwickelt, ich kann es reparieren und ich entscheide, wann Schluss damit ist - mich drängt da kein Fortschritt und keine Firma, die vielleicht irgendwann der Meinung ist, ich muss mein Gerät verschrotten und irgenwelchen neuen Plunder von ihr kaufen...

Thema SVN/GIT: Hmm, ich sehe das ein wenig als Modeerscheinung an und glaube ganz ehrlich nicht daran, dass auf einmal massig Programmierer kommen, nur weil ich TriOS auf GIT statt auf google-code verwalte. Im Endeffekt vergurke ich damit wieder massig Zeit, und mir persönlich bringt das absolut nix außer zusätzlicher Arbeit. Ich hab ja meinen Spaß, und das nicht zu knapp - das sollte niemand vergessen, aber das sollte auch niemanden davon abhalten selbst Spaß zu haben. Wer auf dem Hive proggen und Spaß haben will, der wird das auch tun - ob nun mit GIT, SVN oder einfach lokal mit einer manuellen Versionsverwaltung. Das haben doch viele schon eindrucksvoll bewiesen: zum Beispiel zille9 mit Plexus, uheld mit dem coolen neuen Bella-Code (Fenster und TV/VGA-Integration) und joergd mit seinen ganzen LAN-Geschichten.

[PIC18F2550]

Oh je hier fliegen ja schonmal die Fetzen

Aus meinen Erfahrungen mit der if then geschichte sind das das unter umständen sehr unübersichtlich wird.
Daher habe ich mir überlegt wie ich das am besten in meinem system lösen kann.

Der HIVE ist nutzt nur ein 8 Bit bus gegen über meinen 16 Bit das schlägt sich auf die übertragungszeit nieder leider.
Aber für das Problem gibt es nur eine einzige vernünftige Lösung.
Es werden 2 bytes übertragen im 1. Eine Modulnummer und in der 1. der eigentliche Befehl.

z.B.
Modulnummer $03 = FAT
Befehl $10 = mound

Damit sollte das Problem eigentlich erschlagen sein

Und eine einzige Datei in dem die einzelnen Funtionen aufgeführt sind und zwar mit allen Parrametern
mit diesen Aufbau.

Code: Alles auswählen

#if FAT-TRIOS
  #if REGNATIX
    SUB ...
    VAR ...
    COD ...
    SUB ...
  #end if
  #if BELLATRIX
    SUB ...
    VAR ...
    COD ...
    SUB ...
  #end if
  #if ADMINISTRA
    SUB ...
    VAR ...
    COD ...
    SUB ...
  #end if
#end if

#if FAT-PLEXUS
  #if REGNATIX
    SUB ...
    VAR ...
    COD ...
    SUB ...
  #end if
  #if BELLATRIX
    SUB ...
    VAR ...
    COD ...
    SUB ...
  #end if
  #if ADMINISTRA
    SUB ...
    VAR ...
    COD ...
    SUB ...
  #end if
#end if

In dem entsprechenden Programm muß dann nurnoch über eine entfernung der Auskommentierung entschieden werden was rein soll und was nicht.

[TuxFan]

Moin moin!

BST: Sehe ich auch so. Allerdings vielleicht nicht ganz so kritisch: Notfalls könnte man den BST auch in einer VM mit einem älteren Betriebssystem laufen lassen. Aber eine Alternative wäre schon schön.

Die Alternative gibt es doch schon. SimpleIDE mit SPIN (open Spin) und C-Compiler. Open Source IDE für WINnies, TUXies, MACies und auch für Raspies. Einfach mal ansehen, kostet nur etwas Zeit, die mir scheints aber gut angelegt ist. Außer den geläufigen Preprozessor Befehlen die man vom BST her kennt gibt es auch den Include-Befehl mit dem man Dateien während der Compilierung einbinden kann. Ist zwar noch Beta aber meines Erachtens recht weit fortgeschritten. Ich werde damit meine Elderberry µC, Monoprop und Gam_Bo_Prop Weichware in SPIN erstellen, da alle drei ähnliche Busstrukturen haben und der zusätzliche Include Befehl einige Vorteile, z.B. bei der Pinzuweisung, bringt.

Neuer Hive mit Prop 2 oder 3 oder was auch immer, da kann man zwar drüber nachdenken, aber wenn ich an die zig Ankündigungen des Prop 2 denke und er doch nicht kam.........und wenn er mal kommt und keine USB-Schnittstellen oder HDMI-Ausgang besitzt, sehe ich für die Periferie wie Tastaturen, Mäuse oder Bildschirme etwas sehr schwarz. Die Entwicklung ist seit Einführung des Prop 1 ziemlich weit vorangekommen. Mittlerweile sind PS2- oder Kombies von PS2/USB-Tastaturen und Mäusen recht rar geworden. Monitore mit VGA-Eingang ebenso und die Lebensdauer dieser Geräte wird auch nicht besser bzw. länger. Und über eins sollte man sich auch im Klaren sein, lötfreundlich sind die neuen Prozessoren im SMD-Gehäuse für die Mehrzahl der Lötisten nicht.
Aber ich will niemanden von seinen Überlegungen abhalten.
Gruß
TuxFan

[PIC18F2550]

Hi TuxFan,

ich habe heute mal kurz die SimpleIDE angeschaut macht ja ein ganz ordentlichen Eindruck.

Werd mich warscheinlich damit anfreunden da BST keine include Funktion hat und die #IF Funktion wird bei größeren Projekten etwas unübersichtlich.
Wie das Funktioniert unter SPIN muss ich erst noch herausfinden.
Was ich vermisse ist das Fenster wo ich den fertigen CODE so in HEX Format mit den Quellcode mir anschauen kann.

Hab ja dieses Wochenende etwas Zeit .

[joergd]

Ich werde es halt einfach mal an einem Beispiel umsetzen müssen. Entweder verstehst Du dann, was ich meine oder ich merke, daß meine Idee nicht funktioniert...

Das wird das beste sein, so lernen wir beide was und vielleicht kannst Du mich ja bekehren.

So, dann will ich Dich mal bekehren.
Ich habe jetzt mal alle in TriOS enthaltenen Administra-Sourcen (admflash.spin, admay.spin, admsid,spin und admnet.spin) in eine Datei (admflash.spin, s. Anhang) zusammengeführt. Damit kann man dann alle bisherigen Binaries wie folgt bauen (Kopieren/Verschieben sind Linux-Beispiele):

Code: Alles auswählen

bstc -L lib -D __ADM_FAT -D __ADM_HSS -D __ADM_HSS_PLAY -D __ADM_WAV -D __ADM_RTC -D __ADM_COM -b -O a flash/administra/admflash.spin
cp admflash.binary ${flash}
mv admflash.binary ${sdsys}/admsys.adm

bstc -L lib -D __ADM_FAT -D __ADM_SID -b -O a flash/administra/admflash.spin
mv admflash.binary ${sdsys}/admsid.adm

bstc -L lib -D __ADM_FAT -D __ADM_AYS -b -O a flash/administra/admflash.spin
mv admflash.binary ${sdsys}/admay.adm

bstc -L lib -D __ADM_FAT -D __ADM_HSS -D __ADM_LAN -D __ADM_RTC -D __ADM_COM -b -O a flash/administra/admflash.spin
mv admflash.binary ${sdsys}/admnet.adm

So kann man sich schnell mal einen Administra-Code mit den verschiedensten Kombinationen bauen. Z.B. auch eine Variante ohne SD-Card-Treiber, aber mit kompletten HSS-Player für einen netzwerkfähigen Startracker. Der sollte dann aber nicht in den Flash geladen werden, da man danach keine andere Version von SD-Card laden könnte.

Ich hoffe, daß damit die Vorteile klar werden. Wenn ich jetzt z.B. die aktuellen SD-Card-Treiber einbauen will, muß ich das nur noch einmal machen. Und so viel unübersichtlicher ist der Code durch die #idfef/#endif auch nicht geworden. Noch besser ginge es sicher, wenn wir eine #include Anweisung hätten. Aber das wird auch noch...

Auf diese Art auch die Plexus- und Basic-Änderungen einzubauen, stelle ich mir auch nicht so schwierig vor. Für Obiges habe ich ca. 4-5 Stunden gebraucht. Hätte den weiteren gewaltigen Vorteil, daß man sich auch schnell mal ein Basic-Administra mit Netzwerk-Code bauen könnte. Wie sinnvoll das ist, wissen die, welche mal versucht haben, mein Basic-Programm zur IP-Adreß-Ermittlung von Hand einzutippen. Wenn da dann der TriOS-Netzwerk-Code in Administra geladen ist, tippt es sich sehr angenehm

[TuxFan]

Noch besser ginge es sicher, wenn wir eine #include Anweisung hätten. Aber das wird auch noch...

Dat gibbet doch schon, wie ich weiter oben schon bemekte. Nimm openspin wird mit SimpleIDE mitgeliefert. Müßte auch von der Befehlszeile aus gehen, für die, die das lieber haben. Für TUXies steht openspin nach der Installation in /opt/parallax/bin.
Einfach mal ausprobieren. OpenSpin wird die Zukunft sein. BST ist tot.
Ein altes Indianersprichwort sagt : "Wenn man bemerkt, daß man ein totes Pferd reitet, sollte man absteigen".
Gruß
TuxFan

[TuxFan]

........Was ich vermisse ist das Fenster wo ich den fertigen CODE so in HEX Format mit den Quellcode mir anschauen kann.......

Ich denke die Mehrheit der Benutzer von SimpleIDE würde diese Möglichkeit nicht benutzen wollen, so hat man es garnicht erst eingebaut.
Gruß
TuxFan

[joergd]

Dat gibbet doch schon, wie ich weiter oben schon bemekte. Nimm openspin wird mit SimpleIDE mitgeliefert. Müßte auch von der Befehlszeile aus gehen, für die, die das lieber haben. Für TUXies steht openspin nach der Installation in /opt/parallax/bin.

Ja, ich weiß. Ich wollte nur nicht gleich noch den Schritt von BST zu openspin gehen. Ich glaube nicht, daß das einfach so ohne jede Änderung geht...

[TuxFan]

Hallo Joerg!
Das was ich bisher mit SimpleIDE/OpenSpin bearbeitet habe, hatte ich zuvor mit BST/BSTC bearbeitet ohne Änderungen am Code zu machen. Ich hab, nachdem ich SimpleIDE unter Xubuntu 13.10 sowie Kubuntu 12.04 (nur sudo lauffähig) installiert hatte, einfach das jeweilige Mainprogram aufgerufen und ein Projekt daraus erstellt (Es wird eine Projektdatei angelegt, die man zukünftig aufruft). Dabei wird der Abhängigkeitsbaum mit den erforderlichen Dateien erstellt. Gegebenefalls müssen noch zusätzliche Pfade eingegeben werden. Bisher brauchte ich am Code nichts ändern.
Beim #include Befehl hab ich nur einmal beim Compilieren von PropOS von Cluso99 (Parallax Forum) bei einem seiner Programm Probleme gehabt.
Code vom Hive hab ich allerdings noch nicht getestet.
Ich denke auch, je mehr diesen Compiler und auch die IDE benutzen und Bugs zurückmelden desto besser wird dies OpenSource Projekt.
Gruß
TuxFan

PS.: Zuvor hatte ich bei der IDE von BST sehr oft Abstürze in Form von Unbedienbarkeit der Oberfläche gehabt. Bisher lief das bei SimpleIDE problemlos.