Kommunikation/Protokolle: Unterschied zwischen den Versionen

Aktuelle Version vom 4. März 2006, 18:42 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.

LAN-Typen

Da gibt es drei Grundformen für die Verdrahtung:

Ring-Verdrahtung

• Die Nachrichten gehen immer von einer Station zur nächsten, bis die eigentlich adressierte Station erreicht wird. Zwischenstationen müssen die Nachrichten, die sie nicht betreffen, weiterreichen
• Es müssen alle Teilnehmer immer ansprechbar sein, eben damit sie fremde 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 einflechten

Ein wesentlicher Nachteil ist der, daß der Ausfall einer Station das gesamte Netz lahmlegt

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 brauchen Nachrichten, die sie nichts angehen, nur zu ignorieren

Bus Verdrahtung

• Hier kann jeder mit jedem, Station können fremde Nachrichten einfach 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 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.

Medium-Zugriff bei I2C Dieses Problem stellt sich nur im "Multimaster-Betrieb". Nach einer Stopp-Bedingung ist der Bus frei, d.h. jeder Master kann jetzt versuchen, die Kontrolle zu übernehmen, indem er eine "Start-Bedingung" generiert. Dabei kann es aber immer noch Konflikte geben. Für diese Fälle gibt es ein festgelegtes "Arbitrierungs-Protokoll"

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
• Network Controller/PC
• Bascom_UART_Input
• Betriebssystem für Bascom