bel-ios

[volkerp]

Bei der Umsetzung von Spielen und anderen Applikationen tritt häufig das Problem auf, das diese nur für einen Propeller geschrieben sind (Hydra, Demo-Board, C3 ...) und nun die Aufgabenverteilung an die 3 Chips des Hive ansteht.

Solange man auf Sound und RAM verzichtet, bietet es sich an, Bellatrix als Chef zu nehmen und den Code hier laufen zu lassen. Bellatrix hat TV, VGA, Tastatur-Anschluss und damit auch fast alles, was oben genannte Boards bieten. Eine Anpassung von Softwware beschänkt sich dann i.W. auf die andere Pin-Belegung der Anschlüsse.
Mit Sound wird es schon aufwändiger: Bellatrix muss die Soundkommandos an Administra weiterleiten. Dafür böte es sich an, eine direkte Kommunikation zwischen Bellatrix und Administra zu schreiben. Als Ergebnis hätte man ein "bel-ios.spin"-Objekt, was analog zum "reg-ios" unter Regnatix die Kommunikation transparent für das Hauptprogramm an die Slaves/den Slave weiterleitet.

Mit der Standard-Funktionen des IOS müsste Bellatrix die Kommandos an Regnatix senden, und dieser die Kommandos dann an Adminstra. Das würde gerade bei Sound zu zeitlichen Verzögerungen führen, die sich sicherlich bemerkbar machen würden, oder?

Wie könnte man eine direkte Kommunikation zwischen Bellatrix und Administra basteln? Würde es reichen, auf Regnatix /PROP2 dauerhaft auf Lo zu setzen und BUSCLK als IN festlegen? Dann könnte meinen Gedanken nach Bellatrix analog zum Code für Regnatix die Buskontrolle übernehmen und mit Administra kommunizieren, ohne dass auch Adminstra neuen Code braucht. Also quasi ein 2-Propeller-System? Oder sehe ich das falsch oder geht das noch einfacher/anders?

[drohne235]

Ein kleines Problem ist das HS-Signal, welches per Dioden (D2/3) verodert ist und somit nur in eine Richtung (Slave --> Master) Signale senden kann. Slave --> Slave geht zumindest für das HS-Signal nicht. Um zwischen den Slaves direkt ohne Regnatix zu kommunizieren, braucht es ein Protokoll, welches mit einem Signal weniger auskommt. Im Prinzip sollte das machbar sein, aber wenn ich das recht sehe, nur mit einer Codeänderung auch in Administra - was aber auch kein wirkliches Problem ist. Regnatix kann sich komplett vom Bus abtrennen, oder wird per HS wieder geweckt.

Im Prinzip sind folgende Signale für eine direkte Kommunikation vorhanden:

D0..7
/WR
BUSCLK

Wenn man davon ausgeht, das Bella in diesem Game-Modus Master und Admin Slave ist, benötigt man keine Selektionssignale.

Edit: Die Datagramme für das normale Busprotokoll haben ein Update mit kleinen Korrekturen bekommen.
http://hive-project.de/content/2529

[PIC18F2550]

Zur Zeit stoße ich mit meinem USB-Projekt an ein ähnliches Problem.
die erweiterung um mehrere Busteilnehmer.

Meine Gedanken kreisen um eine Art Datenpaket in 8 Bit breite und 4 Steuerleitungen.
Das Datenpaket besitzt eine Zieladresse (angesprochene Subroutine)und eine Absenderadresse (Quellsubroutine) und immer einen Long wert(Daten/Befehle).
Ein einziger COG kümmert sich um den datenaustausch Konstant 2long.

Jeder Treiber nutzt dabei eine Art Slots/Postfächer zum Daten austausch
Jeder Treiber meldet sich dabei am Bus-COG an unt erhällt dafür einen Zeiger auf sein Postfach.
Übergeben werdendem Treiber an das Zielpostfach/Daten/ und Das Status byt wird mit 1 gesetzt als sendefreigabe.
Es besteht aber auch die Möglichkeit das Quellpostfach mit einer anderen Adresse zu versehen dan würde eine Art DMA zwichen anderen Bausteinen möglich sein.

Beide seiten wissen ob sie ein Byte/word oder Long übertragen werden.
es besteht auch die möglichkeit die Adressen von 65535 auf 32767 zu reduzieren um 2 Bit für die Daten größe zu erhalten.

Diese kurzen Pakete geben anderen Übertragungen die Möglichkeit Daten zu übertragen.

Die gesammte COG-Routine muss in einem COG hineinpassen(ASM) so das fast der gesamte hRam frei ist.

Das einzige was mir noch sorge bereitet ist des SRAM.

[PIC18F2550]

Meine Gedanken kreisen um eine Art Datenpaket in 8 Bit breite und 4 Steuerleitungen.

Holzweg nur 3 Steuerleitungen.

[PIC18F2550]

mal ein Gedanken zum Busablauf.
habe mal alles auf 256 Slot's reduziert ( reicht ja auch )
So könnte dier VGA-Treiber allein schon 2 Slotz nutzen.
1. Steuerbefehle
2. Daten

HIVE2-BUS.pdf

(55.52 KiB) 534-mal heruntergeladen

[drohne235]

Sieht interessant aus. Ich habs jetzt aber nur überflogen, deshalb die Frage: Welcher Baustein initiiert den Transfer? Interessant wäre noch, wie S0..2 erzeugt werden und welche physischen Signale sie belegen.

[PIC18F2550]

Keiner das macht alles ein COG und das ist der einzige der den Bus bedienen darf.

Geladen wird dieser aus dem EEPROM bein Starten und ist in allen Prop's der Gleiche.

Die Adressen 0-7 sind zur Kommunikation der BUS-COG's reservirert.
z.B. Laden eines Neuen Treibers mit vorangehender Prüfung ob Treiber schon im System vorhanden ist.

Nach dem Reset ist in allen Prop's nur der BUS-COG vorhanden außer Administra dort wirt ein 2. COG gestartet der ein Basissystem einrichtet. Nach dem einrichten wird dieser COG wieder freigegeben.
Prop-ID und Treibernummern könnten im RTC gespeichert werden.

Jeder Prop besitzt eine eindeutige ID die im EEPROM in BUS-COG hinterlegt ist.

Ein Slot besteht aus:

Byte Status
Byte frei
Byte Zieladresse
Byte Quelladesse (z.B. die eigene Adresse)
Long Daten

Jeder Treiber bekommt am anfang einen Slot zugeteilt und er kann im anschluß noch weitere anfordern.

Das maximum solte bei 32 liegen.


Vergleichbar wie der Postbote mit Häusen und mehreren Mietern .

[volkerp]

ich würde ein freies Bussystem ala i2c vorschlagen: Es gibt keinen Master, jeder kann anfangen zu senden. Das erste gesendete Byte benennt den Empfänger. Der Master hebt z.B. die Taktleitung auf Hi, der Empfänger bestätigt mit einem Acknowledge-Byte. Im ersten Byte könnte man noch mehr unterbringen, z.B. 3 Bit für die Empfängerkennung, 1 Bit lesen/schreiben und 4 Bit für die Blockgröße. Dann wird ein Block (also max. 16 Byte) übertragen und am Ende quittiert der Empfänger mit einem Acknowledge-Byte. Am Ende des Transfers wird der Bus wieder freigegeben, das müsste über ein spezielles Byte und Takt = Lo angezeigt werden.
Vorteil: Kompakte Kommunikation ohne großen Overhead, schnelle ÜBertragung mehrerer Bytes im Block; kein dedizierter Master nötig, jeder kann mit jedem kommunizieren. Es sind nur eine Taktleitung und die Datenleitungen nötig.

Mit dem Erkennen eines freien Busses und der Freigabe bin ich mir noch nicht ganz im Klaren; ich lese dazu momentan einiges über den Ablauf und die Besonderheiten von i2c auf http://www.i2c-bus.org/de/i2c-bus/.

Evl. braucht man ein Bit des ersten Bytes für die Buskennung. Aber 2 Bit für die Adressen sollten bei 3 Propellern auch reichen.

[PIC18F2550]

Mein System ist eine Mischung aus i2c und Parallel Bus von 8 Bus Teilnehmer mit Priorität Unterscheidung.
Es gibt eine Absender- und Empfängeradresse und konstant 1 long Daten.
Jede Routine erhält ein Postfach zum Datenaustausch zwischen den COG's.
Schau dir mal das PDF etwas näher an.

[Micha]

Hihi, ich bin im Augenblick ehrlich gesagt nicht ganz auf'm Laufenden. Ist die Hive-Hardware demokratie-tauglich oder redet ihr gerade über ne andere abstrakte Hardware?