Der Omnibus kommt!

[Philipp S. (philipp)]

Hallo zusammen,

ich habe es hier schon mal angedeutet, wenn jemand auf der Suche nach
einem geeigneten Bus für Zweck XY fragte: ich habe mir vor langer,
langer Zeit (noch im Studium) einmal einen universellen Bus überlegt,
den ich damals noch auf dem Apple II implementieren wollte, es aber nie
vollendet habe.

Heute -- großer Tag für mich, kleiner Tag für die Menschheit -- habe
ich den ersten Schritt getan und die ersten fehlerfreien Datenpakete
übertragen, mit 20 kByte/s über 2 20 Meter lange Adern zwischen zwei
unbeschalteten und unkalibrierten tiny13. Nicht gerade sensationell,
aber ein wichtiger Anfang.

Ziel war es,
* mehrere Controller (also z.B. keine RS-232)
* einfach (also kein Ethernet)
* ohne besondere Hardware (also kein CAN)
* ohne Quarz oder Kalibrierung (also kein RS-485)
* schnell (also kein 1-wire-Bus)
* über längere Strecken (also kein I2C)
zu übertragen.

Jetzt ist schonmal ein Anfang gemacht (auch wenn damit noch nichts
praktisches anzufangen ist) und bei Interesse kann ich den Code und die
Pläne hier auch vorstellen. Schon einmal grob das Konzept:

* Die Übertragung geschieht (natürlich) differentiell. Die zwei
Leitungen verbinden die Differenzeingänge der Controller (analog
comparator); zum Senden werden die beiden als Ausgänge abwechselnd high
und low gesetzt
* Jedes Senden beginnt mit einer Kalibrierungssequenz, anhand der die
Empfänger den Takt zum Abtasten bestimmen
* Ein "Busmanager" verteilt die "Redezeit" an alle. Um die
Reaktionszeiten gering zu halten, gibt es "gemischte" Bytes, in denen
acht Teilnehmer "ihr" Bit setzen können, wenn sie etwas zu senden
haben
* Der Bus organisiert sich selbst; die Teilnehmer werden durch eine
eindeutige ID identifiziert (ähnlich 1wire), bekommen dann aber eine
kurze Kennung zugeteilt, mit der sie angesprochen werden. So wird der
"Verwaltungs-Overhead" gering gehalten

Neben den Vorteilen (praktisch jeder Controller darf mitspielen, man
braucht keine Verabredungen von Bitrate oder Busorganisation, der Bus
ist sehr flexibel, alles ist frei von Urheberrechten oder Patenten)
will ich auch die Nachteile nicht verschweigen:

* Das ganze ist bei hoher Geschwindigkeit CPU-intensiv. In meinem Test
war der Empfänger über die halbe Zeit mit dem Bus beschäftigt.
* Andere Interrupts sind Gift, es sei denn, die Architektur läßt
Interruptprioritäten zu. Diese Einschränkung ist für viele Anwendungen
natürlich heftig, ist bei Softwareimplementierungen von Schnittstellen
aber schwer zu vermeiden
* Ich kann nicht sagen, wann es fertig wird. Nach über zehn Jahren für
das erste kleine bißchen sieht das erstmal nicht gut aus, aber
letztlich ist der Schritt an ein paar freien Abenden der letzten Wochen
entstanden und ich kann die nächsten kaum abwarten. Außerdem kann ich es
auch bei der Arbeit aktuell gut gebrauchen

Warum schreibe ich das jetzt schon? Weil ich hoffe, daß sich selbst in
diesem Stadium schon ein paar Interessenten finden könnten, die jetzt
noch die Chance hätten, grundsätzliche Ideen einzubringen. In dem Fall
gehe ich gerne noch auf die Details ein, die ich mir überlegt habe.

Würde mich über Reaktionen freuen.

[Jörn G. aus H. (Gast)]

Hört sich interessant an.
Wäre schön, wenn du uns berichtest, wenn du weitere Erfahrungen mit der
Implemenetierung deiner Bus-Idee hier berichtest.

jörn

[Jörn G. aus H. (Gast)]

[äh quatsch] ...gewonnen hast - wollte ich schreiben.