HIVE-Project

Moin moin!
So manches mal passiert es mir, trotz wenig freier Zeit und unfertiger Projekte, daß mich Worte nicht nur zu Reimen sondern auch manchmal zu Gedankenspielen für Hardware verleiten. Diesmal war es das Wort "Borg-Cube". Siehe hier : http://hive-project.de/content/2914
Nun in meiner Neuronenmaschine mutierte das gleich zu Hive-Cube. Eindrücke von gestapelten PC/104-Platinen dümpelten vorüber und ein Clusterstapel von 16 Propellerboards zog seine Bahn. Gut bleiben wir auf dem Boden......
Aber so ganz nebenbei erwuchs die Idee den Hive mit DIL-ICs und bedrahteten Bauteilen, aufgeteilt in einzelne Subsyteme als Stapel von drei Platinen, auszuführen. Hier schlich sich natürlich der Hintergedanke ein, einzelne Subsysteme auch autark benutzen zu können.
Grundlegend haben wir 3 Subsysteme :
1. Regnatix mit SRAM
2. Bellatrix mit VGA, Video, Tastatur, Maus
3. Administra mit SD, Netzwerk, RTC
Mir fielen dazu einige Randbedingungen ein :
1. Ein möglichst hardwarenahes Gebilde zum urspünglichem Hive, um ohne Änderungen an der bestehenden Software auszukommen.
2. Erweiterungsplatinen können oben auf den 3-stöckigen Grundstapel gesteckt werden.
3. Alle 3 I2C Schnittstellen sollten auf dem Bus liegen.
4. Administra erhält alternativ einen 2. SD-Slot oder die SPI-Leitungen gehen auf den Bus.
5. Anschlüsse zur Außenwelt nur auf Front und Rückseite der Platinen.
6. Der Bus kommt ein-/beidseitig auf die Seiten der Platinen.
7. Busverbindung durch Stapelbuchsen wie beim Arduino.
8. Platinengröße zwischen 60mm x 60mm und 80mm x 80mm, wahrscheinlich aber eher letzteres. Damit können alle Benutzer von Eagle-Freeware eigene Zusatz-Platinen dazu entwickeln.
9. Die Administraeinheit kann als standallone Webserver dienen .
10. Bellatrix könnte mit einer zusätzlichen seriellen Schnittstelle als Terminal arbeiten oder mit einem eigenen SD-Slot als Einpropellermotherboard dienen.[Edit]Eventuell auch eine optionale RTC am I2-CBus auf dem Board. Muß ja nicht immer bestückt sein. [/Edit]
11. Alle drei Subsysteme würden jeweils über einen Stecker mit einem Propplug programmiert.
12. Das Regnatixmodul könnte vielleicht in mehrfacher Ausführung aber nur mit Kommunikationsleitungen als Cluster hochgestapelt werden. Ein Regnatixboard mit vollständig bestückten Bus könnte dann als Master den Kontakt vom Cluster zu Administra und Bellatrix herstellen.
13. Stromversorgung über ein 5V-Netzgerät die einzelnen Module bekommen jeweils eine eigene 3,3V Regelung.In diesem Sinne.....
14. Einsatz von 3,3V-SRAM-Bausteinen. Erspart die Widerstände.
15. Die Busanschlüsse sollten im 2,54mm Rastermaß bleiben um auch Lochrasterplatinen benutzen zu können.
Sodele vom Singlepropellerboard über Hive-Cube bis zum Propclustertower wäre damit einiges machbar. Wer mag kann ja hier noch ein wenig über diese Idee diskutieren, eigene Gedanken beisteuern oder diese Idee lizens- und kostenfrei für sich oder auch Andere weiterentwickeln und verwirklichen. Selber hab ich mittelfristig einfach keine Zeit um das weiter zu verfolgen. Es lauern mir noch verschiedene Projekte auf, zwecks Fertigstellung.
Ich wollte das erst in dem alten Ideenpool-Thread posten fand es aber doch eher hier bei der Hive-Hardware passend.

Gruß
TuxFan

1. Vom 8Bit Bus zum serielen (3leitungen).http://hive-project.de/board/viewtopic.php?f=15&t=877
2. Regnatix mit 2MB 3,3V SRAM
3. Bellatrix mit VGA, Video, Tastatur, Maus
4. Administra mit 2x SD, RTC
5. Netix mit 1x SD, Netzwerk
6. Soundix mit R2R netzwerk und Quadrosound
7. Alle EEproms sind doppelt so groß (für eventuellen Bootloader/zum zentralen programmieren über neuen Bus)
8. Verbindung der Stapelplattienen nur BUS + Spannung(5V)
9. jede Plattiene besitzt eigenen 3,3V Regler
10. Portix zur Anbindung an Verschiedene Hartware komponenten.

Welche Buchsen willst du nehmen die vom PC104 sind viel zu groß.

PC104 - war mir bisher unbekannt, coole Sache.

Geschickt gewählt könnte man einiges mit so einem System machen.

Moin moin!

PIC18F2550 hat geschrieben:1. Vom 8Bit Bus zum serielen (3leitungen).

Persönlich seh ich da nur den Vorteil eingesparter Übertragungsleitungen, ob die Übertragungsgeschwindigkeit bei einem seriellen Bus höher ist, wage ich ohne Tests erstmal zu bezweifeln. Ob sie in manchen Fällen ausreichend schnell ist will ich nicht bezweifeln. Ein Geschwindigkeitstest und -vergleich mit optimierter Software wäre da nicht schlecht.
Die vorhandene Software sollte vom Hive weiterhin unverändert auf dem Cube benutzt werden können, bzw. auch vom Cube auf den Hive unverändert übertragbar sein. Dies wäre in meinen Augen ideal. Dazu müßte der Bus aber so bleiben wie er ist. Innerhalb eines Clusters könnte er aber durch Umdefinieren der Leitungen zu einem seriellen Bus geändert werden.

PIC18F2550 hat geschrieben:......Welche Buchsen willst du nehmen die vom PC104 sind viel zu groß.

...und derer zu viele. Ich dachte da an die Stapelbuchsen des Arduino (10-, 8- und 6-polig, unten Stecker und oben Buchse). Siehe z.B. hier : http://www.watterott.com/de/Stapelbare-Buchsenleisten
Diese kann man in ausreichender Menge bei einigen Versendern bekommen. Die Anzahl der Buchsen bestimmt natürlich die Menge der erforderlichen Leitungen.

drohne235 hat geschrieben:PC104 - war mir bisher unbekannt, coole Sache.
Geschickt gewählt könnte man einiges mit so einem System machen.

Borgmäßig sozusagen. Baugruppen und teile in anderem Zusammenhang integrieren.
Die PC104 Architektur ist für meinen Begriff eigentlich der Urvater der Stapelcomputer lange bevor der Arduino mit seinen Shields aufkam.
Hier mal ein paar Bilder zu diesem System :
http://www.google.de/search?q=pc104&cli ... d=0CF4QsAQ
Leider fehlt mir im Moment die Zeit da etwas hardwaremäßig zu entwickeln ohne das etwas anderes liegenbleibt.
Gruß
TuxFan

Lacht nicht.
So etwas bin ich zur Zeit auch am frickeln.

Jedoch nehme ich keinen Platinenstapel sondern ein Steckkartensystem mit Backplane.
Als Steckverbinder wollte ich 2x60 Pol PCI-Slots nehmen. Die sind kompakt, billig und haben mehr als genug Kontakte.
Sogar so viele, dass ich bisher jeden zweiten Pol als Masse/Supply Pin vorgesehen habe.
(Schema GND Signal 5V Signal GND Signal 3V3 Signal GND Signal 5V ...) Das sollte einigermaßen störsicher werden.

TuxFan hat geschrieben: 1. Regnatix mit SRAM
2. Bellatrix mit VGA, Video, Tastatur, Maus
3. Administra mit SD, Netzwerk, RTC

Ich hatte eine etwas abweichende Aufteilung im Sinn.

• 1. Regnatix mit SRAM und "MMU"
  2. Bellatrix mit VGA und Video
  3. Administra mit Sound, Netzwerk und Erweiterungslogik (optional SD)
  4. "Arachne" mit 2xPS2 (Tastatur+Maus), USB-Host, RS232(oder FT232 Wandler) und sonstiges (HID, Joystick etc.)

Die ganzen IO-Geschichten welche viele Pins brauchen aber wenig Durchsatz haben sollen auf einen separaten Prop gepackt werden, welcher aber nicht am normalen 8bit-Systembus hängt sondern über SPI oder I²C angesprochen wird.
Mir ist auf die schnelle kein anderer passender Frauenname eingefallen. Ich dachte halt der Chip vernetzt halt mit schmalen Verbindungen Alles mit Allem, ähnlich wie eine Spinne mit ihrem Netz.

Busse:

• (Adressbus : Regnatix optional)
  8bit par Bus : Regnatix + Bellatrix + Administra + (Zusatzprops optional)
  I²C Bus A : Regnatix + Arachne geteilt mit Reg.-EEPROM
  I²C Bus B : Bellatrix + Arachne geteilt mit Bel.-EEPROM
  I²C Bus C : Administra + Arachne geteilt mit Adm.-EEPROM
  I²C Bus D : Arachne geteilt mit Ara.-EEPROM (erweiterung I²C Bus)
  SPI Bus A : Administra geteilt mit Netzwerk-Chip
  SPI Bus B : Administra + Arachne(als Slave) geteilt mit SD-Card-Slot

Die ganzen TTL-RS232 Busse wollte ich evt. auch auf separate Busleitungen legen welche dann über einen CPLD (als Gluelogic) zusammengefasst werden.. Dann könnten die Props dann zuerst wie gewohnt Programmiert werden und im Betrieb dann als schneller serieller Ringbus verwendet werden.

TuxFan hat geschrieben: Mir fielen dazu einige Randbedingungen ein :
1. Ein möglichst hardwarenahes Gebilde zum urspünglichem Hive, um ohne Änderungen an der bestehenden Software auszukommen.

Absolute Zustimmung. Ich habe eine völlige Abwärtskompatibilität im Sinn. Originale Hive Software läuft genau so wie auf dem original Hive.
Das geht sogar soweit das man Tastatur und Maus (welche bei mit auf einen anderen Prop gewandert sind) optional zurück auf Belatrix umleiten kann.

TuxFan hat geschrieben: 14. Einsatz von 3,3V-SRAM-Bausteinen. Erspart die Widerstände.

Hatte etwas ähnliches vor. Ich wollte eine kleine Zusatzplatine nehmen (Xula50; Xula200 oder Xula200)
Das Ding ist 3,3V Volt kompatibel und hat neben dem Programmer auch ein FPGA, Flash und 4-32 MB SDRAM onboard.
Dadurch schlägt man drei Fliegen mit einer Klappe.

• Man wirft den lästigen 5V Teil vom Bus runter.
  Man hat mehr Speicher bleibt aber im sockel- und lötbaren PDIP-Format.
  Man kann den FPGA als Decoder, MMU und Memorycontroller (SDRAM->SRAM Interface) verwenden.

Mit einer MMU könnte man beschleunigte Busprotokolle realisieren (wie z.B. schnelle DMA-Zugriffe von den Slaveprops) bliebe aber immer noch abwärtskompatibel zum 74HC573N Latch.

PIC18F2550 hat geschrieben:1. Vom 8Bit Bus zum serielen (3leitungen).http://hive-project.de/board/viewtopic.php?f=15&t=877
2. Regnatix mit 2MB 3,3V SRAM
3. Bellatrix mit VGA, Video, Tastatur, Maus
4. Administra mit 2x SD, RTC
5. Netix mit 1x SD, Netzwerk
6. Soundix mit R2R netzwerk und Quadrosound
7. Alle EEproms sind doppelt so groß (für eventuellen Bootloader/zum zentralen programmieren über neuen Bus)
8. Verbindung der Stapelplattienen nur BUS + Spannung(5V)
9. jede Plattiene besitzt eigenen 3,3V Regler
10. Portix zur Anbindung an Verschiedene Hartware komponenten.

Hier hab ich ein paar Anmerkungen und Fragen

• zu Punkt 1 : Hierbei geht leider die Abwärtskompatibilität völlig flöten.
  zu Pkt. 4,5,6 : reichlich neue Firmware notwendig, welche dann auch noch miteinander zusammen funktionieren muss.
  zu. Punkt 4 : was soll Adminstra dann noch machen?
  zu. Punkt 5,6 : wozu separate Props für Sound und Netzwerk? Ist Adminstra so überlastet?
  zu. Punkt 7 : Was spricht dagegen nicht auch min original Hive größere EEPROMs zu verwenden?
  zu. Punkt 9 : unnötig, eine stromhungrige oder rauschempfindliche Platine kann ja optional einen eigenen Regler haben

Bis dann
machts gut
Hauke

P.S.
Bisher bin ich erst soweit, das Buslayout zu machen.

bereinigt.

Aber das haben wir ja auch bei jeder neuen revision.

Nicht ganz: die Software ist nach wie vor selbst auf meinem ersten Hive auf Lochrasterplatine lauffähig. Bei den Revisionen haben sich nur Details am Erweiterungsstecker geändert, nicht das grundlegende Busprotokoll.

Gedanken dazu:

1. Der 8 Bit Bus ist auch in Spin programmiert erträglich schnell und belegt so keine Cog. Und Spin ist dank seiner Einfachheit durchaus ein Argument, sonst hätte sicher schon jemand mal einen PASM-Backbone programmiert. Eine serielle Schnittstelle dagegen ist nur unter Verwendung von PASM in einer dedizierten Cog in jedem Chip mit sinnvoller Geschwindigkeit nutzbar. Wer das möchte, könnte das ja durchaus auch jetzt schon am Hive machen, da der parallele Bus ja nur Software ist.

2. Der 8 Bit Bus bietet auch noch das Potential für Erweiterungen: Dafür könnte das ungenutzte HBeat-Signal sinnvoll verwendet werden um weitere Props zu adressieren.

Aber egal wie, ein modularer Hive wäre natürlich wirklich eine faszinierende Idee.

PIC18F2550 hat geschrieben: Das Netix kümmert sich um die verschiedenen Netzwerkkomponenten Bluetooth Ethernet, CAN, RS232C, .....
Soundix soll das Software & Hardware Soundinterface sein manche brauchen da schon mal etwas mehr Rechenleistung.(Raumklang)

Man kann ja das beste aus beiden Vorschlägen kombinieren.
Ich hatte ja explizit optionale Erweiterungskarten vorgesehen.
Die könnten über 8bit Parallel (Master: Regnatrix) oder SPI (Master: Adminstra) oder Ringbus oder I²C angebunden sein, je nach Bandbreitenbedarf.

Man muss halt nur mal vorsichtig Durchkalkulieren wie viele Cardselect man für den 8bit-Bus und die SPI-Busse realisieren kann. So wäre es auch ohne weiteres möglich mehrere CS für SPI pro Slot bereit zu stellen.

drohne235 hat geschrieben: 2. Der 8 Bit Bus bietet auch noch das Potential für Erweiterungen: Dafür könnte das ungenutzte HBeat-Signal sinnvoll verwendet werden um weitere Props zu adressieren.

Das ist gar nicht notwendig.
Es gibt haufenweise illegale/unbenutzte Kombinationen aus den Signalen RAM1, RAM2, ALE, P1, P2 welche man durch einen Decoder aufschlüsseln kann. Dieser sollte jedoch aus Gründer der Kompatibilität abschaltbar sein.
Im Bootzustand wäre der Decoder inaktiv. D.h. die RAM1, RAM2, ALE, P1, P2 Signale werden 1:1 durchgereicht.
Erst mit einer Aktivierungssequenz (z.B. an einen PCF8574 am Regnatrix I²C wird ein Pin aktiviert) schaltet er in den erweiterten Modus um.
Dadurch bleibt man in beide Richtungen kompatibel.

Orginal SW auf Modul HW

• Die Software kennt diesen PCF8574 nicht, dieser wird nicht umgeschaltet.
  Der Decoder bleibt im "Legacy"-Modus.
  Alles läuft wie gehabt

Modul SW auf Orginal HW

• Die Software versucht den PCF8574 anzusprechen.
  Dieser auf einem original Hive nicht vorhanden.
  Die Software merkt das Sie nicht auf einem Modularhive läuft und reagiert entsprechend.
  Entweder wird eine Fehlermeldung angezeigt oder es wird eine alternative Legacy Firmware verwendet
  (oder es wird ein Link angezeigt wo man sich einen Modulhive bestellen kann )

cu
Hauke

Ein paar Anmerkungen :
Gut daß ich nicht alleine bin mit solchen Ideen.

Jeder Platine/Ebene einen eigenen 3,3V-Regler zu verpassen macht schon Sinn, da man so die Verlustleistung (Wärmeabgabe) an den Reglern klein halten kann und diese Ebene gegebenenfalls autark oder mit eigenen Zusatzplatinen laufen lassen kann. Eventuell kein oder nur sehr kleines Kühlblech. Z.B. Administra als Webserver oder mit passivem Aufsatz mit VGA, Tastatur, Mausanschluß als eigenenständigen Rechner laufen läßt. Bellatrix könnte parallel dazu als autarker Rechner laufen.

Ich hatte zwischendurch auch an einen Backplane Passivbus gedacht,wie Hauke bei seiner Planung. Aber da ich in der Vergangenheit bei den PCs oft einen manchmal auch zwei Karten-Slots zu wenig hatte, bin ich doch bei dem Gedanken mit den Stapelsteckern verblieben, da hier immer genügend BUS-Plätze frei sind.

Hauke, da hast Du ja etwas größeres vor. Die Xula-Bausteine sind ja recht komplex und nicht gerade billig. Nenn doch einfach "Arachne" in "Thekla" um. Du bleibst dann bei der Gattung, und hast einen richtigen Namen. Kennt jemand Thekla nicht ? ist hiervon nicht allzuweit weg

Was auf Administra-Ebene eventuell zu erweitern wäre ist der SPI-Bus der SD-Karte. Man könnte hier einen Flashbaustein einsetzen der das eigentliche Betriebssystem enthält und bei fehlender SD-Karte als Bootmedium fungiert. Dann kann man auch 32k große EEProms verwenden. Das könnte allerdings mit der Hivesoftware kollidieren.

Gruß
TuxFan

TuxFan hat geschrieben:Ein paar Anmerkungen :
Gut daß ich nicht alleine bin mit solchen Ideen.

Danke

TuxFan hat geschrieben: Jeder Platine/Ebene einen eigenen 3,3V-Regler zu verpassen macht schon Sinn, da man so die Verlustleistung (Wärmeabgabe) an den Reglern klein halten kann und diese Ebene gegebenenfalls autark oder mit eigenen Zusatzplatinen laufen lassen kann. Eventuell kein oder nur sehr kleines Kühlblech.

Kann man so machen. Ich wollte halt nur die benötigten Bauteile (zahlenmäßig) klein halten. Daher finde ich es sinnvoll eine gemeinsame 3,3V Versorgungsleitung wenigstens anzubieten. Bei Karten mit höheren Ansprüchen muss dann natürlich ein dezidierter Spannungsregler drauf.

TuxFan hat geschrieben: Ich hatte zwischendurch auch an einen Backplane Passivbus gedacht,wie Hauke bei seiner Planung. Aber da ich in der Vergangenheit bei den PCs oft einen manchmal auch zwei Karten-Slots zu wenig hatte, bin ich doch bei dem Gedanken mit den Stapelsteckern verblieben, da hier immer genügend BUS-Plätze frei sind.

Man kann ein Busboard auch erweitern. Das einzige was einem Grenzen setzt wäre der Platz im Gehäuse und die Kapazität der Bustreiber. Und diese beiden Probleme hättest du mit Stapelplatinen genauso.

TuxFan hat geschrieben: Hauke, da hast Du ja etwas größeres vor. Die Xula-Bausteine sind ja recht komplex und nicht gerade billig.

Naja, für das was drauf ist sind die ziemlich Preiswert. Und lötbares SRAM in 3,3V gibt es auch nicht gerade geschenkt.
Ich habe grad' mal nachgeschaut. Für den Preis eines eines Xula200 bekommt man bei Farnell gerade 4,5MB SRAM (9 Chips á 512k*8).
Und für die 285€ welche die 32MB auf dem Xula2 als SRAM kosten würden bekommt man fast drei Xula2.
Zusätzlich zum SRAM braucht man wiederum Adressdekoder und Adresslatch., und vermutlich Bustreiberbausteine.
Der Bus wäre nämlich mit mindestens 8 Bausteinen (2x Slave-Prop + 74HC573N + Adressdekoder + 2MB-SRAM) schon recht recht hoch belastet.
Von einem IC-Grab mit 64x512kB für 32MB will ich erst gar nicht reden.

Und was die Komplexität angeht, so kann man ja erst einmal mit einfachen Designs anfangen. Wie z.B. die Funktion eines erweiterten Latches+Decoder. Das ist zwar am Anfang reine Verschwendung im Angesicht der Möglichkeiten des FPGAs, aber später kann man meinetwegen ja auch noch einen numerischen Copro oder Ähnliches entwickeln.

TuxFan hat geschrieben: Nenn doch einfach "Arachne" in "Thekla" um. Du bleibst dann bei der Gattung, und hast einen richtigen Namen. Kennt jemand Thekla nicht ? ist hiervon nicht allzuweit weg

Ich kenne Tekla aber der Name gefällt mir nicht so sehr. Arachne ist ein Frauenname aus dem Altgriechischem. http://de.wikipedia.org/wiki/Arachne

cu
Hauke