Ich zeume das Pferd mal von hinten auf:
Versteht mich da bitte nicht falsch das sind nur meine Erfahrungen als HiVe Einsteiger der gewillt ist das System zu verstehen und nicht als "Genörgel" gemeint.
For lauter Cog's sehe ich den Wald noch nicht
Ist doch ein guter Ansatzpunkt um die Sache mal zu durchleuchten. Der Hive ist halt in seiner Art ein wenig anders als ein herkömmlicher Computer, aber ich denke gerade das ist ja das interessante. Wie Rainer das schon geschrieben hat kann man ganz klassisch gewohnte Strukturen auf ihm abbilden, aber du musst das nicht, du kannst deine ganz persönlich Vision ausprobieren
oder auch deine eigene Hölle erschaffen...
Ich denke ein guter Ausgangspunkt wäre es, nicht an einen normalen Computer zu denken, sondern quasi die Entstehung des Hive nachzuvollziehen. Denk dir einfach mal zwei der Propellerchips weg und nimm nur einen. Mit diesem Prop allein kann man ja schon eine ganze Menge machen, du kannst VGA, Sound, SD-Card und Keyboard anschließen und hast einen kompletten kleinen Computer. Aber du wirst schnell merken, dass ein Prop doch sehr begrenzte Ressourcen hat. Sicher würde es für ein Pacman oder einen kleinen Midiplayer reichen, du wirst also schon mit diesem einen Prop eine Menge Spaß haben, aber man muß schon mächtig sparsam sein.
Jetzt wird dir nach einigen Runden Pacman aber ziemlich langweilig und du denkst dir: Was wäre wenn man ein netzwerkfähiges Pacman macht und mit anderen zocken könnte - so richtig mit Capture the Flag usw. Nur würde der Code für Netzwerk nicht mehr in den einen Prop passen, also nimmst du einfach einen zweiten Propellerchip und verpasst ihm diese Aufgabe. Beide Propeller mußt du miteinander koppeln - entweder seriell oder parallel. Wenn du diesen Weg jetzt weiter gedanklich verfolgst und irgendwann vielleicht den Wunsch verspürst, die Entwicklung der Software selbst mit Editor & Compiler auf dem System zu realisieren, wirst du vielleicht bei einer ähnlichen Struktur ankommen, wie sie der Hive momentan hat. Sicher könnte man da an verschiedenen Stellen noch so einiges anders gestalten, so könnte man den Bus und das RAM-Interface komplett in einen FPGA stecken, so das z.B. jeder Prop direkt auf den RAM zugreifen könnte, aber wenn du das tust, kommst du sehr schnell an den Punkt wo es nur noch mit hochpoligen SMD-Bauteilen weiter geht. Diese Grenze wollte ich aber ganz bewusst nicht überschreiten, da so das ganze nicht mehr als Bausatz für fast jeden Bastler nachbausischer ist. Denn das war eine ganz zentrale Forderung: Es sollte ganz einfach sein. Kompliziert geht immer und ist keine Kunst, aber einfache Sachen fordern die Kreativität heraus.
Dieses "Nachvollziehen" hatte ich auch im Hinterkopf als ich im Tutorial folgendes geschrieben habe:
Hinweis 3: Experimentiere! Ich habe den Hive innerhalb einer Woche ohne Schaltplan aufgebaut und dabei vieles davon gelernt was man über diesen speziellen Microcontroller lernen muß. Der Aufbau des Gerätes ist kein notwendiges Übel, sondern vermittelt im ständig möglichen Experiment alle Grundlagen, um mit dem Propeller und dem Gesamtsystem – dem Hive – umzugehen.
Leider haben die meisten den Hive viel zu schnell aufgebaut, vielleicht kann man die Struktur aber auf diesem Weg nicht wirklich nachvollziehen, oder es fehlen noch die entsprechenden Testprogramme, mit welchen man die Struktur im Experiment quasi interaktiv nachvollziehen kann. Es muss ja beim Aufbau kein Geschwindigkeitsrekord gebrochen werden, sondern es geht ja auch und besonders darum die Struktur zu verstehen.
Obwohl ich die Vermutung habe das Regnatix für eigene Apllikationen, Spiele, Tools etc. herhalten soll verstehe ich nicht wirklich das Master/Slave Konzept.
Wie soll denn ein z.B. Netzwerktreiber für ein Netzwerkspiel den gerade überlaufenden TCP/IP Layerstack im eRAM sichern wenn aber nur Regnatix einen Speichertransfer einleiten kann?
Ich glaube du denkst zu zentralistisch. Man muss halt sehen das die einzelnen Propeller autark bleiben, also das der gesamte Netzwerkcode sich bis zu einem bestimmten Layer in Administra befindet. Das kann so weit gehen das Administra schon spezifische Verarbeitungen für das Game selbst realisiert, welche sich auf die Netzwerkdaten beziehen.
Ich verstehe im Moment auch noch nicht wie ich via Administra 5 Leitungen am Erweiterungsport steuern könnte. (da würde eine fehlen) Dar das Hauptprogramm welches Admin steuern soll im Master (Regnatix) laufen würde und den Bus schon für ein simples Print belegt stehen für Administra als Alternative auch nicht die Datenleitungen D0-D7 zur Verfügung.
Kommt darauf an was du konkret machen willst. Wenn du die Leitungen (Du redest doch jetzt von den freien Administraports ADM-P19..22 am Expansionsport?) nur schalten willst, weil du ein LED oder einen Motor angeschlossen hast, bekommt der Funktionsinterpreter in Administra genau eine Routine exio(port,status), welche eine bestimmte Leitung auf den Wert von Status setzt. Möchtest du komplexere Sachen machen muß diese Routine halt mehr leisten. Wenn du z.B. über diese Leitungen ein SPI-Interface realisieren möchtes, so bindest du eine Routine ein, welche ein Byte entsprechend dem SPI-Protokoll über diese Leitungen sendet. Regnatix braucht dann nur noch die Funktion aufrufen und das Byte übergeben, welches über SPI gesendet werden soll - der Rest ist Sache von Administra, da muß Regnatix nicht stndig schauen was da los ist. So läuft ja im Prinzip auch schon der Code für die SD-Card.
Das ist aber eine ganz normale Sache wie sie in jedem Computer stattfindet: Wenn du da eine Ausgabe machst, findet das meist auch über die Southbridge statt. Der Datenbus ist dabei nur kurz für die I/O-Operation belegt, den Rest erledigen dann Spezialschaltkreise. Warum also sollte Administra da unbedingt was selbstständig auf dem Datenbus machen wollen? Nicht das es nicht ginge, im Gegensatz zu den meisten klassischen Computern kannst du das problemlos im Hive realisieren, da ja sehr viel nur durch Software bestimmt wird, aber 4Bit-I/O-Leitungen zu verwalten ist da glaube kein ausreichender Grund.
Mir kommt es so vor als wenn Regnatix in einer Endlosaschleife ständig die Slaves fragen müste "Hast Du gerade eine Byte fürs eRAM oder brauchst du eines aus dem eRAM?" oder
"Soll ich ich mich für X Bustakte tot stellen damit ihr Sklaven am Erweiterungsbus schnuppern könnt?"
Wenn du es so programmierst, wird genau das auch passieren.
Aber ich denke es ist eine besondere Herausforderung im Hive dezentral und verteilt zu denken. Warum sollte Administra z.B. ständig auf den eRAM zugreifen? Viel von dem im Hive enthaltenen Speicher ist dezentral über die drei Propeller verteilt - jeder Chip hat seinen eigenen hRam den er nutzen sollte. Aber das ist ja auch keine neue Sache: Schau dir nur die Grafikkarten in den PC's an. Wenn sie eigenen (dezentralen) RAM auf der Grafikkarte selbst benutzen ist die Sache schnell. Wenn aber wie in vielen Notebooks Shared Memory genutzt wird, also die Grafikhardware sich den RAM auf dem Mainboard mit der CPU teilt, dann wird es langsam und bestimmte Sachen wie komplexe 3D-Operationen sind da wegen der fehlenden Bandbreite nicht mehr möglich.
In gleicher Weise kann man den eRam im Hive auch teilen - reserviere einfach eine COG in Regnatix mit dem entsprechenden Code, welche genau diese Aufgabe erfüllt - aber das sollte man sich schon genau überlegen. Aber es ist nicht unmöglich. Regnatix ist dadurch aber auch nicht völlig blockiert - hier vergisst du das jeder Chip ja acht Cogs hat - sondern eine COG würde mit dem entsprechenden Code nur die Aufgabe eines Memorycontrollers übernehmen, die restlichen sieben Prozessorkerne wären dann immer noch für die eigentliche Aufgabe in Regnatix verfügbar!
Ich habe mir die Bus Datagramme angeschaut erkenne aber nicht wirklich ein klares Busy Signal welches die Slaves davon abhalten könnten auf dem Erwertungsport zuzugreifen. /WR ist zwar die meisten Busclocks low aber nicht die ganze Sequenz lang wärend Regnatix auf dem Bus werkelt.
Der Erweiterungsport ist im wesentlichen der Daten- und Adressbus plus einige Spezialsignale, genau wie eine PCI-Buchse in einem PC - prinzipiell sind da ja auch die meisten Komponenten (RAM/Briges/CPU/alle gesteckten Karten...) angeschlossen, trotzdem würde eine Netzwerkkarte nicht an der CPU vorbei auf die Grafikkarte zugreifen wollen. Ich verstehe da nicht ganz genau was du vor hast, mit Sicherheit findet sich aber bei Bedarf die Möglichkeit den Bus feizuschalten - ist ja alles nur Software - aber wie gesagt bin ich mir nicht sicher ob du das wirklich willst.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
