Kommunikation/Protokolle: Unterschied zwischen den Versionen

Version vom 28. November 2005, 11:43 Uhr

Protokolle

Damit Controller miteinander Daten austauschen können, müssen sie natürlich mit Leitungen verbunden werden und es müssen Regeln eingehalten werden, damit auch immer der richtige Controller die richtige Nachricht bekommt.

Da gibt es drei Grundformen:

Ring-Verdrahtung

Die Nachrichten gehen immer von einer Station zur nächsten, bis die eigentlich adressierte Station erreicht wird. Zwischenstationen müssen also Nachrichten, die sie nix angehen, immer weiterreichen Es müssen alle Teilnehmer immer ansprechbar sein, damit sie für die sie irrelevante Nachrichten sofort weitergeben können. Trotzdem entsteht eine gewisse Laufzeit, bis eine Message tatsächlich ankommt. Andereseits gibt es hier keine Probleme mit dem Zugriff auf das Medium, denn jeder Teilnehmer hat seine Sendeleitung exklusiv für sich. Die Nachrichten, die eine Station selbst wegschicken will, muß sie in den Datenstrom gewissermaßen "einflechten"

Stern-Verdrahtung

Hier gibt es in der Mitte eine Art Verteilerknoten, der (als "HUB") jede von irgendeiner Station eingehende Nachricht an ALLE anderen weiterleitet. Stationen müssen Nachrichten, die sie nix angehen, ignorieren

Bus Verdrahtung

Hier kann jeder mit jedem, Station müssen Nachrichten, die sie nix angehen, ebenfalls ignorieren. Der Weg von einer Station zu einer anderen ist auch bei grossen Systemen direkt und kurz. Das große Problem, für das es verschiedene Lösungen gibt, ist die Regelung, wann der Bus gerade frei ist und man seine Nachricht wegschicken kann.

I²C (TWI) Bus

(Single-Master, multi-Slave)

Hier kann nur der "Master" aktiv Kontakt mit seinen "Slaves" aufnehmen. Wie bei allen Bussen, ignorieren die Slaves alles, was sie nicht betrifft.

Messages

(Nachrichten). Bei allen Verbindungsarten muß offensichtlich jede Station genau wissen, an wen eine Nachricht gerichtet ist. Und dazu muß es möglichst leicht bei allen Bytes, die da herumhuschen, erkennbar sein, was davon die Adresse ist, oder, anders gesagt, wo eine Message anfängt und wo sie aufhört. Und natürlich muß die Ziel-Adresse auch immer an der gleichen Stelle in der Nachricht stehen.

minimale Anforderung

• Daten Das sind die "Nutzdaten", das eigentliche Transportgut
• Header
  • HDR Ist ein eindeutiges Kennzeichen, daß hier die Message beginnt. Das könnt ja nun einfach irgendein besonders Zeichen "X" sein. Ja, aber dann dürfte diese Zeichen woanders in der Nachricht nicht mehr vorkommen, sonst hat man nix davon.
  • Ziel ist die Zieladresse

SPI / UART

Bei SPI und UART Protokollen gibt es das Verfahren, grundsätzlich ein 9-Bit Datenformat zu verwenden. An diesem 9. Bit kann man erkennen, ob die anderen 8 Bit Nutz-Daten sind oder ob es sich um die Zieladresse und damit gleichzeitig um den Anfang einer neuen Message handelt.

I²C / TWI

Beim diesem Bus gibt es besondere Zustände auf der Daten- und Clock-Leitung: "START", "repeated START" und "STOP". Immer nach jeder Startbedingung folgt die Zieladdresse. "STOP" ist eigentlich weniger dazu da, das Nachrichten-Ende zu bezeichnen, als den Bus für andere Master freizugeben (auch wenn die bei Single-Master Betrieb garnicht da sind).

Plain Text

Wenn auf die Übermittlung von transparenten Daten verzichtet werden kann (der Dateninhalt ist z.B. nur "druckbare Zeichen") kann man natürlich auch die gängigen Steuerzeichen wie <CR>, <LF>, <STX>, <ETX> etc. zur Kontrolle verwenden. Gerade bei Internetverbindungen wird oft einiger Aufwand getrieben, binären Daten so umzuwandeln, damit das erreicht wird ("BASE64").

EDI

Es gibt auch noch ein Verfahren, Steuerzeichen UND transparente Daten zu übermitteln, das wird bei EDI (electronic data interchange) angewandt. Dabei können auch Nachrichten variabel strukturiert werden. Durch XML etc. ist EDI allerdings ein wenig verdrängt worden.

Übertragungs-Sicherung

Bei den genannten Methoden gibt es nur bei I²C bzw. TWI eine direkte Rückantwort, ob die Nachricht auch einen Abnehmer gefunden hat, das sind die ACK-Bit, die der Empfänger für jedes einzelne transferierte Byte aktiv generieren muß.

Alles andere stellt reinen "forward" Betrieb dar, d.h. der Absender muß sich selbst irgendwie darum kümmern, ob seine Nachricht angekommen und verstanden worden ist.

Siehe auch

I2C

Weblinks