Der Inkompatibel-Neu-(Nicht-Hive-Genannt-)Kisten-Kram-Thread

[yeti]

----------8<-----{20170426-0721-GMT}----->8----------

Ich fände ein aus gleichen Propeller-Modulen aufgebautes "Prop-Cluster" nett.

Mal als Gedankenspiel: Man nehme ein bis zwei Hände voll Propeller, überlege sich, mit wievielen Pins sie untereinander kommunizieren sollen und sammelt diese in einem Bus zusammen. Die restlichen Pins sind für notwendige und optionale Peripherie, also auch zur spontanen freien Benutzung... ;-)

Fragt sich noch, ob die InterProp-Vernetzung als lineare, flächige, räumliche, ... Struktur geschehen soll. Ein selbstorganisierendes Mesh wäre zwar reizvoll, ist aber vermutlich Overkill für die armen kleinen P8X32As, wenn sie auch noch komplexe Routingprobleme lösen sollen.

Fragen:

Lassen sich Propeller "memory-mapped" auf einen klassischen Bus setzen oder kommt letztlich nur schnelle serielle Kommunikation in Frage?

Läßt sich mit CPLDs oder FPGAs so etwas wie eine "Telephonzentrale" aufbauen, mit der die Kommununikation vereinfacht werden kann?
Vermutlich erzwingt das nicht nur Einstieg in weitere Technologien und Toolchains, sondern auch SMD-Löterei... :-(

Ist die Benutzung von CPLDs/FPGAs daher vielleicht zu abschreckend?

Außerdem steht die Frage im Raum, warum man überhaupt noch Propellern will, wenn man FPGAs beherrscht... :-P

Sollte also Alles lieber CPLD- und FPGA-frei aus klassichen bedrahteten Bauteilen entstehen, um Nachbau zu vereinfachen?

----------8<-----{Auf gar keinen Fall hier klicken!!!}----->8----------

[PIC18F2550]

Die Vernetzungssoftware im Prop sollte so gering wie möglich sein und ohne Anpassung auf jeden Prop lauffähig sein (PASM & 2COGs).

Die Vernetzung sollte wie in Telephonanlagen über eine Art Matrixschaltwerk(CPLD) realisiert werden.
Für eine Parallele Schnittstelle würde ich mich nicht mehr entscheiden da der Verwaltungsaufwand und Störanfälligkeit zu groß ist,
Für die Vernetzung von 7 Props bräuchte man:
3 x OUT für Prop1 ... Prop7 ( der wert 00h steht für Leerlauf ) Mit Ausgabe der Propnummer wird auch die Busanforderung generiert.
1 x In Busfreigabe ( Sendefreigabe )
1 x OUT Seriel_TX
1x OUT Sendesperre
1x IN Seriel_RX

im HRAM werden zwei ein Arrarys eingerichtet
TX
word Status(0-1) / Propnummer(1-7) / Commando (0-2047)
word Länge(0-511)
Long (128)
RX
word Status(0-1) / 000 / Commando (0-2047)
word Länge(0-511)
Long (128)

Übertragen wird in zwei schritten:
in der 1. Übertragung sind Commando und Länge enthalten.
in der 2. Übertragung sind die Daten enthalten.

sind Daten =0 wird der Bus nach der 1. Übertragung freigegeben.

[yeti]

Wenn man eh schon 1-2 Cogs für die Kommunikation reserviert (lassen wir mal offen, ob evtl gar Einer reichen kann), dann sind alle grerade nicht sendenden Propeller ja ganz Ohr auf dem Bus.

Was spricht dann dagegen eine komplett serielle Kommunikation (z.B. mit Beans 8Mbit-Routinen (oder gab's davon sogar eine 14Mbit-Version?)) zu realisieren, die Absender und Empfänger in den Paketen mit beïnhaltet?
Ich find den Thread im Parallax-schen Forum zu diesen Routinen auf die Schnelle nicht wieder... aber das wird schon wieder auftauchen...
(-: ***Pausenmusik*** ;-)
Bingo: Propeller DEMO : (14.5 Meg Baud) High Speed Prop-to-Prop Serial Communication

Es würde ähnlich zu Ethernet auch Broadcast-Pakete erlauben und wäre in der Anzahl der Teilnehmer zumindest nicht durch die Anzahl der Busleitungen beschränkt, sondern lediglich durch das definierte Paketformat und die darin reservierten Bits für die Adressierung...

Plan-B könnte statt einer Leitungsvermittlung eine Paketvermittlung sein. Vermutlich läßt sich (mittels FPGA?) ein Multi-Port-RAM zimmern, das Daten-Pakete wie ein Switch zwischen angeschlossenen Ports/Geräten transportiert. Läßt sich sowas vielleicht gar durch einen als Switch eingesetzten Propeller realisieren?

[PIC18F2550]

Der Slave muß immer horchen oder es werden Steuerpins benötigt.
Für Multimaster Eigentlich recht kompliziert.

Ich würde IO Pin RX und TX getrennt machen das vereinfacht die umschalterei im Prop und CPLD.
Und es entfällt eventuell mitgelesene Daten heraus zu filtern

Master Baut Verbindung Auf und beendet diese auch wieder nachdem er die Antwort bekommen hat.

Jo das ist das SPIN Demo was ich meine.
Nur das die Treiber nicht dauernd neu in den COG geladen sollte.
Aber mal sehen wie man das am günstigsten verschaltet.

Es bleibt also erst ein mal bei den 7 Leitungen

[yeti]

@PIC18F2550 ... meinste echt, wir brauchen CPLD, FPGA oder andere Non-Prop-Brandbeschleuniger?

Könnte eine Art auf http://propeller.ws-nbg.de/main.php oder der Bean-schen 8- oder 14MHz-Routinen basierender Hub/Switch/Server auf einem extra dafür reservierten Propeller nicht den Job machen?

N Propeller an einem zentralen Propeller als Server, Switch oder wie auch immer wir das nennen würden, wäre wesentlich bastlerfreundlicher und propelleriger als das Thema CPLD oder FPGA ins Spiel zu bringen.

[PIC18F2550]

Hi Yeti,

Hab ich auch schon einmal durchgekaut, und komme im Stern nur auf 3 props an den einen prop dran. das bringt keine Punkte und keinen Speed.

Egal ob Stern oder Ringschaltung beide haben da immer den Bremsanker im Datenverkehr.

Ich hätte auch lieber was gesünderes für meine Augen gibt es aber leider nicht.

Oder kennst Du einen anderen Chip der als Koordinatenschalter uns freundlicher gesinnt ist?

[PIC18F2550]

An einem XC95144 mit 144pin können maximal 11 Propeller gleichzeitig mit 8,25MB (nicht gemultiplext) Daten austauschen.

[yeti]

8.25MHz kostet 2 Cogs, denk ich...
Sollen die wirklich in jedem Propeller geopfert werden?
Wäre wenn eh CPLD oder FPGA unvermeidlich scheinen, nicht Einfacheres machbar?

...und wer lötet uns die 144-Pinner?

Mir schwebt vielleicht ja auch ganz Anderes vor als Dir: Ich hab zunächst gar keine Geschwindigkeiten im Kopf und hätte eigentlich schon lieber eine Kommunikation mit beliebig vielen Propellern. Dazu müssten Absender und Empfänger im Datenpaket kodiert werden wie es jetzt auch zwischen unseren internettenden Rechnern passiert... letztlich würde man beim Nachbilden von Ethernet oder SLIP landen...

Ich muß da echt noch länger drüber brüten...

Besonders künstlerisch fände ich ja einen Propeller als Hub oder Switch zwischen anderen Propellern, was die Struktur der 8 Cogs um den Hub herum eine Ebene höher nachbilden würde. Die Vernetzung auf der nächsthöheren Ebene wäre dann das Aneinanderstöpseln solcher Hubs...

Du willst etwas praxistauglich Super-Schnelles, ich eher ewas für's Spielen im Elfenbeinturm?

[PIC18F2550]

Yeti das 1 Wirenetzwerk hatte ich auch schon ein mal auf der Focusachse.

Leider ist der Zeitverbrauch um Zusammenstöße der Datenpakte zu vermeiden bei mehreren nicht unerheblich.

Ein UTP System Fällt wegen der Unsicherheit ob das Paket ankommt erst ein mal grundsätzlich aus.

Machbar wäre da noch eine Art TCIP System.
Dort könnte ein einzelner COG pro Prop ausreichen.
7 Props gehen auf einen prop (lokaler Datenknoten) der an einer Art Superhighway hängt und mehrere Knoten verbindet.

[yeti]

Hmmmm... im Speichern-und-Weiterleiten-Netz mit Props an einem PropHUB könnt man auch Fullduplex fahren. Bei getrennten RX/TX-Leitungen könnte jede Seite der anderen ein "Bitte langsamer!" schicken ohne die aktuelle Übertragung zu zerstören.

...was überseh' ich da?