langsame Übertragung, ungeschirmtes Kabel -> welchen Bus nehmen

Genau für solche Fälle gibt es Sachen wie CAN.
Mit "zeitgesteuert" meinst du wohl sowas wie eine vereinbarte Bitrate? 
Ok, das ist eine Einschränkung. Aber damit kann man prima leben. Die 
wirklich freilaufenden (im Sinne von ziemlich undefinierter 
Taktfrequenz) MC-Systeme sind doch wirklich nicht das Argument bei 
Bus-Systemen. Ein Quarz/Resonator kostet nur wenige Cent. Im Gegenzug 
kannst du dir massiv Gedanken machen, wie du ein Multimaster-System 
wirklich perfekt (CAN ist nahe dran an "perfekt") ans Laufen bringst.
Entweder machst du da Abstriche oder an der Gesamtperformance (beliebig 
langsam kann man sich was gutes Ausknobeln). Es gibt nicht umsonst 
Sachen, die sich durchgesetzt haben. Das Rad immer wieder neu erfinden 
war/ist auch keine gute Strategie.
Soll jetzt nicht heissen, dass da kein Platz für Neues wäre. Aber wenn 
du so fragst, wie du fragst, bist du eher auf der Suche nach einer 
Sache, die es so nicht geben kann.

Dennis X. schrieb:
> Für deine Verwendung sollte sicher auch ein einfacher RS485 Bus reichen.

ja, das würde ich auch sagen.

> Protokoll kannst du dir ein eigenes Ausdenken oder du benutzt etwas wie
> Modbus etc..
> Für die Realisierung von Multi-Master könnte ein Token-Passing Verfahren
> vielleicht ganz gut passen.

andere Idee wenn auf dem Bus nicht so viel los ist:

du verwendest bei allen Teilnehmern Fault-protected Treiber (z.B. 
SN65HVD1781). Denen macht ein Kurzschluss nichts aus. Jetzt können die 
Teilnehmer lauschen was auf der Leitung los ist. Wenn nichts los ist und 
sie senden wollen fangen sie einfach an. Wenn ein anderer Teilnehmer im 
selben Moment anfängt zu senden gibts den Kurzschluss, den halten die 
Treiber aber aus.

Natürlich muss das Protokoll vom Empfänger eine Empfangsbestätigung 
fordern damit Du erkennen kannst daß was nicht sauber angekommen ist. Du 
sparst Dir so aber alle Mechanismen mit Token, festen Zeitschlitzen etc. 
Das macht das ganze wesentlich einfacher.

Du kannst so auch einfach IP-Pakete auf die Leitung geben. Musst halt 
eine Escape-Sequenz definieren. Aber das hat den Vorteil daß es für IP 
schon jede Menge fertige Stacks, Hilfsprogramme etc. gibt und Du kannst 
es von einem sehr einfachen Gateway aus auch sofort übers Internet 
weiter routen.

Gerd E. schrieb:
> Dennis X. schrieb:
>> Für deine Verwendung sollte sicher auch ein einfacher RS485 Bus reichen.
>
> ja, das würde ich auch sagen.

Ich habe bis jetzt noch keinen einfachen und funktionierenden 
RS485-Multimaster-Bus gesehen.
Versuche gabs viele. Und es gibt auch unter Extrembedingungen 
funktionierende (im Sinne von Kollisionen erkennende und sich wieder 
fangende) Lösungen. Einfach sind die nicht gerade...
Genial einfach/einfach genial sind RS485-Lösungen für single-master. Da 
kommt auch nichts anderes so schnell ran. Billig, schnell, universell. 
Multimaster ist anstrengend.

Eine witzige Idee gabs dazu im englischen Picaxe-Forum. Da hatte einer 
ungefähr 50m dreiadriges Kabel im Haus veteilt und hat darüber so 12-15 
uC's versorgt und mit 2400 baud kommunizieren lassen. TxD -> open 
collector mit hochohmigem pullup auf jedem Board an die Datenleitung. 
Diese über Schmitt-Trigger an RxD zurückgeführt. Kollision wird erkannt, 
wenn was anderes als das gesendete Byte zurückkommt.

H.Joachim Seifert schrieb:
> Ich habe bis jetzt noch keinen einfachen und funktionierenden
> RS485-Multimaster-Bus gesehen.
> Versuche gabs viele. Und es gibt auch unter Extrembedingungen
> funktionierende (im Sinne von Kollisionen erkennende und sich wieder
> fangende) Lösungen. Einfach sind die nicht gerade...

Meine Lösung für genau dieses Problem habe ich oben vorgestellt. Die 
eigentlichen Daten werden per TCP übertragen und wenn es zu einer 
Kollision kam gibt es vom TCP aus einen Retransmit.

Bei dieser Lösung hast Du natürlich keine Priorisierung zwischen den 
Hosts oder Nachrichtentypen wie bei CAN. Und wenn alle auf einmal senden 
wollen gibt es eine Verstopfung des Bus, dem kann man dann z.B. mit 
exponential Backoff mit etwas Beigabe von Zufallszeit beim Senden Herr 
werden.

Ein paar Sensoren und Aktoren ohne großartige Latenzgarantien kann man 
auf diese Weise sehr elegant und einfach verbinden, da die ganzen 
Bausteine der Lösung weit verbreitet, gut verfügbar und leicht zu 
handhaben sind.

Die Idee stammt übrigens nicht von mir, sondern von hier:
http://www.ethersex.de/index.php/ZBus_(Deutsch)
http://old.ethersex.de/index.php/ZBus_Protocol

Helge A. schrieb:
> Eine witzige Idee gabs dazu im englischen Picaxe-Forum. Da hatte einer
> ungefähr 50m dreiadriges Kabel im Haus veteilt und hat darüber so 12-15
> uC's versorgt und mit 2400 baud kommunizieren lassen.

Gerd E. schrieb:
> http://www.ethersex.de/index.php/ZBus_(Deutsch%29

Eine ähnliche Lösung gibt es hier, mit nur zwei Adern, wobei der Pull-Up 
auf der Datenleitung recht niederohmig ist und mit 150mA die µCs 
versorgt:

http://romanblack.com/blacknet/blacknet.htm

Es geht dabei um Reflexionen und die sind von der 
Signalanstiegsgeschwindigkeit und Laufzeit auf dem Medium abhängig. So 
generell ist Aussage RS485 nur als ein Strang, falsch!

Bei deiner Topologie sollte das funzen. Die anderen übrigens auch, also 
i2c, CAN, usw.

Darfst halt nicht zu schnell takten. Bei 0,5m gehen locker 100kbit/sec.