ich beschäftige mich gerade mit Bussystemen mit denen ich verschiedene langsame Temperatursensoren abfragen soll.
Was mir beim CAN-Bus auffällt, das der Bus als echtzeitfähig gilt. Worauf ist denn die Echtzeitfähigkeit gebunden? Klar, ich kann per ID die Priorität festlegen. Der Hardwarearbiter wird dem Teilnehmer den Vorzug geben der die höchste Priorität besitzt. Was passiert aber, wenn ein Sensor wichtige Daten loswerden will oder muss und ein anderer Teilnehmer, mit einer höheren Priorität, belegt ständig die Leitung. Der Sensor mit der niedrigen Priorität wird eventuell irgendwann seine Daten los, dann sind die Daten aber wertlos weil diese Daten zu diesem späten Zeitpunkt für den laufenden Prozess unbrauchbar sind.
Hängt also die Echtzeitfähigkeit auch von anderen Faktoren ab, mit dem ich einen echtzeitfähigen Bus also derart vermurksen kann das der dann diese Eigenschaft nicht mehr erfüllt?
Echtzeitfähig ist immer ein relativer Begriff. Eines ist jedoch darin üblicherweise enthalten, nämlich dass es (konforme Nutzung vorausgesetzt) /garantierte/ Reaktionszeiten bzw. Bandbreiten gibt. Wie hoch die sind, ist eine andere Sache.
Bussysteme, die zwar typischerweise schnell sind, aber im Allgemeinen kein garantiertes Worst-Case-Verhalten haben, sind hingegen nicht echtzeitfähig. Z.B. Ethernet ohne besondere Protokolle. Ein Token-Ring reagiert schon wesentlich gleichmäßiger, obwohl er auch nicht echtzeitfähig ist.
Eine alternative Methode sind, von einem einzigen Host-Controller strikt kontrollierte Bussysteme. Der Controller kann dann natürlich die Zeitvergabe vollständig steuern und damit auch Garantien erfüllen, so er die Anforderung hinreichend genau kennt. USB ist theoretisch so ein Kandidat. Diese Methode setzt allerdings einige Kooperativität in den Softwarekomponenten voraus.
Natürlich muss ich mich immer an die Spielregeln des jeweiligen Systems auf Hard- und Softwareprotokollebene halten. Und dazu gehören u.U. auch, dass nur eine bestimmte maximale Busnutzungsdauer am Stück erlaubt ist, oder auch nur eine bestimmte zugesicherte bzw. ausgehandelte Bandbreite pro Device verwendet werden darf.
Ein defektes Gerät kann einen Bus aber eigentlich immer runterziehen - deswegen ist es ein /Bus/ und keine Punkt zu Punkt Verbindung. Manche Busse kennen allerdings Maßnahmen, um die Auswirkungen in Grenzen zu halten. Und schon wieder fällt mir der "Tote" Ring ein, wo ein defektes Gerät vom Ringleitungsverteiler knallhart ausgekoppelt werden kann (in Grenzen...).
Gerade für relativ kleine Datenraten ist eine hostkontrollierte Lösung nicht das schlechteste. Damit kann man am einfachsten garantierte Zyklen gewährleisten, so einem denn keine fremden Softwarekomponenten dazwischenfunken.
In article , Rolf_Bombach writes: |> Ralph A. Schmid, dk5ras schrieb: |> > Marcel Müller wrote: |> > |> >> USB ist theoretisch so ein |> >> Kandidat. |> > |> > Doch USB ist kein Bus, sondern eine reine Punkt-zu-Punkt-Verbindung. |> |> Und manchmal auch das nur nach längerem Warten. Latenzzeiten |> gemäss Mittwochslotterie.
Manchmal auch gar nicht. zB. dann, wenn der SiS-USB-Controller spontan meint, dass das Gerät abgesteckt wurde und erst wieder nach dem Reset (Treiber neu laden reicht nicht) merkt, dass was dranhängt.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Oder der ICH4 meint, daß er mit zwei USB2.0-Geräten überfordert ist. Der ausdauernde Leser hier mag sich noch erinnern; wir haben das mainboard geerdet, die neuen Geräte kommen jetzt mit neuem board daher.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.