Fragen/Gedanken zum Hardwarekonzept des Hive

[Ingo]

Vorab kurz ein zuerst per PN geführter Dialog mit Drohne235

meine Frage:
Die konkrete Ausführung der Adressierung / Ansteuerung der SRAMs, d.h. die gesamte Erzeugung aller Steuersignale für den SRAM ist die nach Mustern von Parallax oder sonst wem erfolgt, folgt sie bestimmten Notwendigkeiten der Software?
Ich hätte an dieser Stelle Vorschläge zur Erweiterung der Möglichkeiten insbesondere zur erheblichen Erweiterung der Anschlussmöglichkeiten externer Hardware aber würde erstmal gern wissen, welche Freiheitsgrade bestehen.

Antwort von Drohne235

der Anschluss der externen RAM's unterlag keinen Zwängen. Von Parallax ist da auch nichts vorgesehen. Die einzige Grenze war dabei die Hardware, da nicht genug I/O-Pins zur Verfügung standen, musste ich auf ein Adresslatch zurückgreifen. Auch von der Software besteht da keine Richtlinie, da der Propeller, bzw. die RISC-Kerne, von sich aus schlicht und ergreifend überhaupt nicht auf den externen RAM zugreifen können... Man muß also den Zugriff per Software selbst realisieren. In dem einfachen TriOS ist das in Spin realisiert - die Routinen sind im IOS zu finden. Ansonsten besteht noch die Möglichkeit das in PASM zu machen. Dabei kommt man aber schon schnell an die Grenze der Zugriffsgeschwindigkeit der momentan verwendeten RAM's (55 nsec Zugriffszeit <--> 50 nsec Befehlszykluszeit der Kerne).

Nun zu meiner Frage/Überlegung:

Wäre es nicht evtl. sinnvoll/wünschenswert die Ansteuerung des SRAM in einer Art vorzunehmen, ähnlich wie dies z.B. beim Z80 erfolgte, d.h. unter Erzeugung der üblichen Steuersignale /MREQ, /RD,/WR?

Es könnten Pins dafür gewonnen werden, wenn die Adressen anders gelatched würden. Dann könnte ebenfalls ein /IORQ-Signal erzeugt werden, was den Anschluss von 256 und mehr IO-Geräten z.B. auch über Standard-PIOs ermöglichen würde.

Konkret könnte ich mir vorstellen dass die Adressierung folgendermaßen abläuft:
Auf den Adressbuss werden A8 bis A15 gelegt sowie gleichzeitig auf den Datenbus A16 bis A19 (max. bis A23). Dann wird der Latch-Clock angelegt, dann können A0 bis A7 auf den Bus. Die Auswahl der Ram-Chips erfolgt über das höchste genutzte Adressbit. Die jetzigen Pins für A8 bis A10 würden frei.
/RAM1, /RAM2 sind /MREQ1 /MREQ2 (/CS1 bzw /CS2 der RAMs), von den freien Pins könnte eines als /IORQ, eines als /RD (=/OE der RAMs) genutzt werden.

Somit könnte ein großer IO-Raum erschlossen werden.

Wofür?: z.B für einen Drucker
Ich könnte mir unter anderem vorstellen, A/D-Wandler anzuschließen. Damit wäre es möglich ein Softwareoszilloskop zu realisieren und das Parallelprozessing unter anderem dafür zu nutzen, die Daten in Echtzeit zu verrechnen (z.B. indem auf einem Kern eine FFT-Routine läuft, die die Echtzeitdarstellung von Spektren erlaubt). Eine solche Anwendung belegt auch, warum IO-Operationen (auch) an Regnatix stattfinden können sollten.

Gruß Ingo (Drohne103 - Hive-Aufbau gerade begonnen, nach eindrucksvoller Präsentation durch Drohne235 in Wittenberg ).

[Rainer]

Hi Ingo,

das Thema wurde schon heiß diskutiert. Da hat wohl jeder seinen eigenen Ansatz.
Ich tendiere persönlich eher zu dem Ansatz, den auch die Industrie geht (die machen ja auch nicht immer alles falsch ).
Parallel ist out, seriell ist in.
Man bekommt seriell einfach die bedeutend höheren Durchsatzraten hin .. siehe SATA, USB 3, usw.
Kein Gedöns mit Timingproblemen auf Parallelen Bus'en, kleinerer Pin-Bedarf, kein Problem mit Adressräumen (bei 32 Bit Prozessoren kann ich schon einiges anschließen ).

Ich habe das für mich noch ein bischen zurückgestellt im Moment.
Ich tendiere aber wirklich zu einem seriellen High-Speed (Standard-)-Bus-System für den Hive.

Gruß.
Rainer

[laserjones]

Man bekommt seriell einfach die bedeutend höheren Durchsatzraten hin .. siehe SATA, USB 3, usw.

Wobei ich ehrlich gesagt nie verstanden habe, warum. Von der Logik her müsste man über n Leitungen ja ungefähr n-mal so schnell übertragen können wir über eine einzelne Leitung ... zumindest wenn die Abschirmung gleich gut ist, was bei parallelen Leitungen natürlich ungleich aufwendiger ist.

[drohne235]

Wobei ich ehrlich gesagt nie verstanden habe, warum. Von der Logik her müsste man über n Leitungen ja ungefähr n-mal so schnell übertragen können wir über eine einzelne Leitung ... zumindest wenn die Abschirmung gleich gut ist, was bei parallelen Leitungen natürlich ungleich aufwendiger ist.

@laserjones: Das ist in der Tat unlogisch. Aber letztlich bedeutet es bloß, das die neuen seriellen Schnittstellen wie PCI-E schneller sind als die alten parallelen. In der Praxis gibt es dann aber durchaus auch mehrere serielle Schnittstellen parallel bei PCI-E - die sogenannten Lanes. Somit ist die Welt wieder logisch und in Ordnung.

@ingo:
An sich ist der Adressraum ja intern auch größer, da ja die Signale /RAM1, /RAM2 bzw. /PROP1 und /PROP2 intern schon per Software ausdekodiert werden. Das hätte man auch problemlos extern mit einem Adressdekoder machen können, aber den Chip wollte ich halt sparen um die Hardware so einfach wie möglich zu machen.

Für die IO-Peripherie gibt es mehrere verschiedene Ansätze:

- SPI über Administra
- Ein getrenntes /IOREQ-Signal an Regnatix (mein Favorit). Für dieses Signal habe ich zwei Leitungen ins Auge gefasst:

1. BUSCLK - Bei geschickter Programmierung der Busroutinen wäre es evtl. möglich diese Leitung frei zu machen, aber das müsste man
noch testen.
2. HBEAT von Regnatix - Diese Leitung ist quasi frei, da die LED nur Kosmetik ist. Wenn man das Signal als IOREQ verwendet, blinkt halt
das LED bei jedem I/O-Vorgang - wäre ja auch schick. Ansonsten wäre es einfach völlig "rückstandsfrei" und unbedenklich.

Bei Aktivierung der IOREQ-Leitung erwarten alle Peripherieschaltkreise als erstes Byte eine entsprechende I/O-Adresse auf dem Datenbus. So kann man problemlos 256 zusätzliche Propeller adressieren - das sollte reichen denk ich...

Allerdings muß ich gestehen, dass ich als verantwortungsvolle Drohne nur Propeller als Peripherieschaltkreise vorsehe, die dann entsprechenden eigenen Puffer und die nötige Eigenintelligenz mitbringen. Ein bisschen Spincode und fertig ist das LPT-Port oder der Speicheroszi usw. Die nötigen Signale, inklusive dem HBEAT/IOREQ von Regnatix, liegen am Expansionsport an, der Rest ist nur Software. Wenn man die Erweiterungskarte mit Propeller/EEProm gleich noch stapelbar macht, kann man etliche Module übereinander stecken - sofern man die entsprechenden elektrischen Randbedingungen betrachtet (Stromverbrauch etc.).

Das ganze würde völlig ohne Änderung am Hive auskommen - wenn ich deine Idee richtig verstanden hab, wäre dafür doch eine Hardwareänderung nötig oder? Wenn du vorhast eine IO-Karte zu basteln beteilige ich mich in jedem Fall daran, da ich das eh vorhatte. Bei Bedarf bekommen wir sicher auch wieder eine entsprechende Menge für eine ordentliche Sammelbestellung einer professionell gefertigten Platine hin. So ein Aufsteck-Experimentier-IO-Board wäre mit Sicherheit für viele interessant! Bis jetzt waren wir ein wenig mit anderen Themen beschäftigt, weshalb ich die I/O-Sache noch nicht angegangen bin...

P.S. Hilf mir bitte auf die Sprünge, ich hab mir die Namen nicht so gemerkt: Welcher Spectrummania warst du?

[Ingo]

P.S. Hilf mir bitte auf die Sprünge, ich hab mir die Namen nicht so gemerkt: Welcher Spectrummania warst du?

In Deiner Bildersammlung Bild 11/20 mit recht hellen Haaren.

Noch ein Wort zum Thema High-Speed serial Verbindung:
Ich denke das würde dem Konzept ein wenig entgegenlaufen, hohe Performance aber schwer nachzuvollziehen für den Bastler. Da sind die guten alten Parallelschnitstellen oder RS232 schon Anwenderfreundlicher (sie benötigen eben keinen USB-Host).

Gruß Ingo/Drohne103.

[DJLinux]

Serielle Busse sind nur schneller gegenüber parallelen weil ... genau

Z.B. 40 Leitungen im IDE Kabel würden bei 1GHz nur noch Datenschrott produzieren (Übersprechen, Induktion, ... bin kein "elektro man")
Die Kosten für ein 40 Pol. HighSpeed Kabel sind 3 mal höher als für ein "platzsparendes" gut abgeschiermtes serielles Kabel INKLUSIVE I/O Chip für den Hersteller.

Grüsse aus einem der Paralleluniversen (an der seriellen Galaxi links vorbei)

Joshy

[Rainer]

P.S. Hilf mir bitte auf die Sprünge, ich hab mir die Namen nicht so gemerkt: Welcher Spectrummania warst du?

In Deiner Bildersammlung Bild 11/20 mit recht hellen Haaren.

Noch ein Wort zum Thema High-Speed serial Verbindung:
Ich denke das würde dem Konzept ein wenig entgegenlaufen, hohe Performance aber schwer nachzuvollziehen für den Bastler. Da sind die guten alten Parallelschnitstellen oder RS232 schon Anwenderfreundlicher (sie benötigen eben keinen USB-Host).

Gruß Ingo/Drohne103.

Da hast Du Recht. Allerdings waren das ja auch nur Beispiele. Ich brauche auch keinen USB-Host auf dem Hive ... SATA-Platten anschließen fände ich allerdings ziemlich witzig .. so als Machbarkeitsstudie.

Mit dem seriellen Objekt in der OBEX von Parallax erreichst Du bis zu 2 MBaud .. was schon ganz anständig ist. Wenn ich mich recht erinner hat da jemand das Ding bis auf 4 MBaud aufgebohrt ... und das ist alles noch RS232.
Ein Parallax-Mitarbeiter hat ein serielles Objekt entwickelt, das bis zu 20 MBaud schafft ... über 2 Leitungen und ein paar Meter Leitungslänge. Finde blos den Thread gerade nicht.

High-Speed heißt ja nicht zwangsläufig kompilziert und Hobby-Untauglich.

Warum parallele Schnittstellen ihre Grenzen erreicht haben, kannst Du in Wikipedia nachlesen:

"Bei parallelen Bussen wird es bei höheren Übertragungsraten immer schwieriger, den Datenfluss auf allen Leitungen synchron zu halten bzw. das Übersprechen zwischen den einzelnen Leitungen in den Griff zu bekommen. Der beim ATA-Bus (IDE-Bus) nicht spezifizierte Busabschluss und die massebezogenen Signale schränken zudem die verwendbare Kabellänge stark ein. Serial ATA nutzt das LVDS (Low voltage differential signaling) für die Signalgebung, ähnlich der seit langem bei SCSI bewährten LVD-Technik."

http://de.wikipedia.org/wiki/Serial_ATA

Gruß.
Rainer

[laserjones]

Mit USB würde ich beim HIVE gar nicht erst anfangen - schon weil man da in einer Grauzone agiert, wenn man keine USB-Vendor-ID-besitzt. Und die kostet vierstellig. Man kann sich natürlich einfach eine ausdenken, aber das kann (wenn auch eher theoretisch) zu Kollisionen mit existierenden Geräten und/oder legalen Problemen führen. Ist zwar alles eher unkritisch im Hobbybereich, wäre mir aber trotzdem unsympathisch. Dann lieber ein eigenes System (nennen wir es SHIP - Serial HIVE Interconnection Protocol ) oder ein bestehendes, das völlig frei nutzbar ist.

Zwar wäre es cool, beliebige USB-Geräte am HIVE nutzen zu können. Andererseits wäre es wohl absolut nichttrivial bis unmöglich, die Treiber dafür zu schreiben, wenn es keine ganz simplen HID-Geräte (Maus etc.) sind.

[Ingo]

Die Vorteile serieller Schnittstellen bei hohen Übertragungsraten sind mir schon klar. Aber wie schnell brauchen wir es? Eine Parallelschnittstelle braucht halt z.B. bei 8 Datenbits und einem Strobe nur ein Register und dahinter können 8 Leitungen gesteuert werden. An einem seriellen Interface hängt je nach Protokoll wieder ein Controller ...

Wo ich mir alledings eine serielle Schnittstelle gut vorstellen könnte, wäre, wenn die Datenübertragung drahtlos erfolgen würde - entweder mit einem eigenen Protokoll oder unter Nutzung von Bluetooth oder ähnlichem.

Was ich als Peripherie im Übrigen auch ganz witzig fände, wäre ein Sprachprozessor, der eine schön computerquakige Sprachausgabe von Ascii-Texten realisiert (falls das nicht jemand als Softwarebibliothek coden möchte) - etwas so wie der Computer von Prof. Falken in "War games". Spracherkennung (einiger Befehlsworte) wäre auch ganz lustig.
Ein solches Feature würde den Hive noch mehr zu einem "Freund" machen...

Gruß Ingo/Drohne103

/edit: habe ich gerade noch gefunden:

http://www.robotikhardware.de/chips.html
http://www.magnevation.com/pdfs/speakjetusermanual.pdf
http://www.speakjet.com/

Demo: http://video.google.de/videosearch?q=sp ... e&resnum=4#
edit/

/nochmal edit:

gerade noch gesehen, es gibt eine softwarelösung für den Propeller:
http://forums.parallax.com/forums/defau ... 1&m=152683

nochmal edit/

[Rainer]

Die Vorteile serieller Schnittstellen bei hohen Übertragungsraten sind mir schon klar. Aber wie schnell brauchen wir es? ........

Nun ja ... ich will es mal so ausdrücken ... so schnell, wie es der Hive zulässt.
Ist und war das nicht immer der Sinn bei Homecomputern ? ... ausreizen was geht ?

Außerdem macht genügend Geschwindigkeit "Gelassen", was das programmieren angeht und einiges erst möglich. Mir ist auch klar dass der HIVE einen Homecomputer "simuliert" und wir ihn nicht zur Simulation von Kernprozessen einsetzen wollen, trotzdem muß man ihn ja nicht unbedingt mit Absicht langsam machen.

Welche Technik man bei Schnittstellen einsetzt liegt wohl auch stark vom Gerät ab daß man ansprechen will.
Sobald ein anderer Mikrokontroller (AVR/Propeller/Pic) das Endgerät ist, würde ich seriell einsetzen ... bei anderer Hardware ohne I2C,SPI,JTAG, usw. bleibt wohl sowieso nichts anderes als parallel.

Sprachausgabe hatte ich eigentlich bis jetzt auf so gut wie jedem Homecomputer ... beim TI 99/4a sogar als Hardwaremodul. Bei Spracheingabe habe ich leider überhaupt keine Erfahrung. Außerdem finde ich es als etwas befremdlich mit meinem Computer zu reden

Gruß.
Rainer