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.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.