Der externe BUS ?

Alles zum Thema Hardware rund um die Propellerchips und den Hive.
Antworten
DJLinux

Der externe BUS ?

Beitrag von DJLinux »

Ich habe mir mal die Schaltungspläne angeschaut bin mir bei dem Bus aber noch nicht
im klaren wie externe Schaltungen realisiert werden.

Kriegt jedes am Bus hängende Gerät eine eindeutige Adresse und wird dann über Leitungen
wie WR/RD angesprochen oder werden Geräte in den Speicheradressbereich "gemapt"
wie die Ports an dem PC?

einen hab ich noch :)
sind Pfeile auf Eagle Pläne die nach oben zeigen immer Versorgungsspannung
und Pfeile nach unten Masse mit anderen Worten ist das eine Norm?

Grüsse Joshy
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Der externe BUS ?

Beitrag von drohne235 »

DJLinux hat geschrieben:Ich habe mir mal die Schaltungspläne angeschaut bin mir bei dem Bus aber noch nicht im klaren wie externe Schaltungen realisiert werden.

Kriegt jedes am Bus hängende Gerät eine eindeutige Adresse und wird dann über Leitungen
wie WR/RD angesprochen oder werden Geräte in den Speicheradressbereich "gemapt"
wie die Ports an dem PC?
Der Bus ist reine Software und insofern kann darüber gestritten werden wie es realisiert wird. Wir müssen nur für uns einen Standard finden der flexibel genug ist um uns nicht gegenseitig zu blockieren. Nichts wäre schlechter als zwei unabhängig voneinander entwickelte Erweiterungen, welche sich gegenseitig blockieren. Ein direktes Mapping ist so nicht möglich, da ja alle bisher beteiligten Bausteine (Administra, Bellatrix und die beiden RAM's) direkt IN Regnatix ausdekodiert werden. Sinnvoll erscheint es da auch die IO-Erweiterungen in direkter Weise durch Regnatix ausdekodieren zu lassen - dazu unten mehr.

Nun meine persönlichen Gedanken dazu. Ich denke prinipiell müssen wir zwei verschiedene Anbindungsarten betrachten, die aber durchaus gleichzeitig und gleichberechtigt nebeneinander Bestand haben können :

1. Anbindung über einen seriellen Bus (z.B. SPI)
2. Anbindung über den parallelen 8-Bit Bus.


Zu 1.
Hier bieten sich die freien Ports von Administra an, wobei Administra dabei das komplette Handling übernehmen muß damit es schnell genug ist, was sich dann in entsprechende ios-Routinen niederschlagen würde.

Zu 2.
Ein Problem was wir haben ist ein fehlendes Signal für eine I/O-Operation auf dem parallelen Bus. Alle schon existierenden Bausteine haben ja ihre fertig dekodierten Selektionssignale an Regnatix. Nun könnte man ein Bit von Administra dafür benutzen, aber das empfinde ich als umständlich und es wird auch langsam. Aber Regnatix ist voll belegt und hat kein Port mehr frei. Die einzige Möglichkeit wäre das HBeat-Signal als IO-Request zu verwenden, am LED werden dann halt IO-Operationen angezeigt. So hätte man ein schnelles Signal direkt an Regnatix, welches man mit maximaler Geschwindigkeit ansprechen kann. Das ist auch der Grund warum ich dieses Signal schon am Expansionsbus angelegt habe.

Wie würde dabei der Ablauf aussehen: Alle bisherigen Busteilnehmer außer Regnatix selbst haben eineigenes Selektionssignal (RAM1, RAM2, PROP1, PROP2) bekommen. Das IO-Signal würde jetzt aber potentiell alle irgendwie anschließbare Erweiterungen selektieren, was eine Adressierung nötig macht. Dem entsprechend müßte jede Karte eine eigene Adressdekodierung vornehmen.

Nehmen wir mal weiter an wir wollen auf den Erweiterungskarten zusätzliche Propeller anschließen. Dann brauchen wir folgende Signale:

/IO IO-Signal
D0-7 Daten
/WR Schreibsignal
CLK

Das Busprotokoll würde dann folgendermaßen aussehen:

Status Wait: Alle IO-Propeller warten auf die Aktivierung des IO-Signals.
Status Dekodierung: Bei der Aktivierung des IO-Signals liegt auf dem Datenbus die Adresse der zu aktivierenden Erweiterung.
Status Inaktiv (gültig nur für nicht adressierte Erweiterungen): Die nicht adressierten Propeller warten auf die Deaktivierung des IO-Signals, d.h. auf den Zeitpunkt bis die aktuelle IO-Operation abgeschlossen ist. Sobald das IO-Signal deaktiviert wird wechseln die nicht adressierten Propeller in den Zustand "Wait".
Status Aktiv: Der aktivierte Propeller kann jetzt in spezifischer und selbstbestimmter Weise mit Regnatix kommunizieren. Der Datenaustausch erfolgt ebenso wie bei Administra und Bellatrix über die restlichen Signale. Ist die spezifische Operation abgeschlossen geht der adressierte Propeller wieder in den Zustand "Wait" und Regnatix deaktiviert das IO-Signal.

Mit diesem Protokoll können bis zu 256 weitere Propeller adressiert werden und für die aktive Phase stehen alle Möglichkeiten offen. Für einen Propeller könnte man ein einfaches Framework bereitstellen welches alle grundlegenden Busoperationen enthält. Möchte man nicht so viele IO-Leitungen verschwenden, könnte man auf den SPI-Bus mit zwei belegten Leitungen ausweichen und hätte die maximale Portzahl zur Verfügung (26 freie Ports).

Fazit: Mit diesem Modell hätte man zwei unterschiedlich skalierte Busse auf dem Expansionsbus - SPI mit vielen freien Ports und langsamerer Übertragung und IOBus mit weniger freien Ports aber dafür einer schnelleren und direkteren Kommunikation.

Nachteil: Wenn die Erweiterungskarte nicht "intelligent" ist wird es so natürlich aufwändiger.

Alternative: Man verwendet die freien Ports von Administra zur Adressierung der Erweiterungen. Aber auch das erscheint mir prinzipiell umständlich: Bei einer IO-Operation muß Regnatix über eine Administrafunktion die Adresse an den Ports setzen und kann dann erst kommunizieren. Außerdem fände ich einen seriellen Bus wie SPI zusätzlich ganz spannend - diese Möglichkeit würde man sich ganz verbauen.
einen hab ich noch :)
sind Pfeile auf Eagle Pläne die nach oben zeigen immer Versorgungsspannung
und Pfeile nach unten Masse mit anderen Worten ist das eine Norm?
Die Pfeile kann man drehen wie man in Eagle drehen wie man will, entscheidend ist der Name - also VSS, VCC oder GND.
"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
Antworten