Version vom 29. August 2006, 18:11 Uhr

Network Controller/PC Routing

Das Routing ist ganz einfach die Methode, Nachrichten von einem Programm(teil) zu einem anderen zu transportieren.

Messages (Nachrichten)

Je nach physikalischem Transportmittel wird die Message verschieden eingepackt.

Der Vergleich mit einer Briefsendung ist zulässig, da wie dort gibt es

• Zieladresse
• Absender
• Daten

Uns interessiert eigentlich mal nur, wie eine solche Nachricht vom Sender zum Empfänger kommt, daher können uns die Daten selbst erst einmal völlig egal sein.

Zieladresse und Absender sind äquivalent. Sie beinhalten nicht einen Wert, sondern sind strukturierte Pfadangaben .

Bei der Zustellung eines Briefes ist der Pfad klar:

• Postleitzahl / Ortsname, wobei dieser eigentlich redundant ist
• Straße
• Hausnummer
• Türnummer / Familienname, auch der dient in den meisten Fällen nur zur besseren Lesbarkeit
• Vorname

Damit ist dann (üblicherweise) ein Empfänger eindeutig

Das reicht aber nur, weil die Leute bei der Post ein System haben, wodurch sie wissen, 
wie ein Brief von der Postleitzahl A zur Postleitzahl B kommt. 

So ein System können wir bei unserem Netzwerk erstmal nicht voraussetzen.

Netzwerk

Und um die Sache zu diskutieren, nehmen wir einfach eine konkrete PC u. µC Konfiguration an

• Es gibt auf einem PC zwei Programme (Applikationen), die über IP (mit Sockets) mit einem "Server" verbunden sind,
• der wiederum über COM1 mit einem µC Kontakt hat. (an COM2 hängt was anderes)
• dieser µC hat auch einen I2C Anschluss
• Auf diesem Bus hängt ein weiterer µC,
• der über die UART mit dem nächsten µC redet.
• Der hat auch I2C, aber einen anderen Bus
• und da drauf hängt noch ein Controller, der hat sonst aber nix.

Und ausgerechnet auf diesem letzten gibt es zwei Programmfunktionen (Func1 u. 2), die Nachrichten vom PC empfangen sollen.

Dynamische Pfade

Wenn jetzt nicht bei jedem Rechner ein "Postleitzahlverzeichnis" aufliegt, müssen wir wohl bei den Adressen klitzeklein angeben, wie und wo es weitergeht.

Wenn wir nicht ausschliessen, daß der PC-Server auch mehrere COM-Ports hat, braucht auch der eine Angabe. Das Einzige, was sicher ist, ist die Verbindung Applic <-> PC-Server

• Der vollständige Pfad von "APPLIC" nach "FUNC-1" wäre also

COM(1) / I2C(0x8D) / UART () / I2C (0x8A) / FUNC-1

• Und für die Antwort:

I2C (0x8C) / UART () / I2C (0x8E) / RS232 () / IP (Sock-1) / APPLIC

Würde sich dagegen "FUNC-" gleich auf dem ersten µC befinden, wäre der Pfad wsentlich kürzer:

 COM(1) / FUNC-1

bzw.

 RS232 () / IP (Sock-1) / APPLIC

das ist die schlechte Nachricht.

Jetzt aber eine gute:

• Da die Wege hin und zurück immer die gleichen sind, können wir die Absenderadresse auch erst unterwegs aufbauen, denn jeder Rechner weiß ja, wer er ist, kann also seine Adresse selbst einfügen.
• Auf der anderen Seite kann man nach jedem "Hop" die Zieladresse um den schon erledigten Schritt verkürzen.

d.h. Unterwegs wird die Zieladresse immer kürzer, die Rücksendeadresse immer länger, in Summe also etwa gleich.

Ich habe im Schema verschiedene Stellen mit Ziffern bezeichnet, mal sehen, wie die Adressangaben da jeweils aussehen:

1 Ziel: COM(1) / I2C(0x8D) / UART () / I2C (0x8A) / FUNC-1 Absender: APPLIC (A)

2 Ziel: I2C(0x8D) / UART () / I2C (0x8A) / FUNC-1 Absender: IP (Sock-1) / APPLIC (A)

3 Ziel: UART () / I2C (0x8A) / FUNC-1 Absender: RS232 () / IP (Sock-1) / APPLIC (A)

4 Ziel: I2C (0x8A) / FUNC-1 Absender: I2C (0x8E) / RS232 () / IP (Sock-1) / APPLIC (A)

5 Ziel: FUNC-1 Absender: I2C (0x8C) / UART () / I2C (0x8E) / RS232 () / IP (Sock-1) / APPLIC (A)

Anmerkung: UARTs gibt's natürlich potentiell auch immer mehrere

Router

Einer der Rechner ist dann ein Router, wenn er die Information

 Symbolischer-Zielname (ID-Code)   Pfad-Liste   

in Tabellen führt. Für den Absender verkürzt sich dann die erforderliche Pfadangabe, aber zumindest bis zum Router muß natürlich alles da sein.

Gibt es so einen Router nicht, muß der jeweilige Absender die Pfade kennen, zu denen er senden will.

Technische Umsetzung

Folgende Dinge sind also zu lösen:

• Weitgehend automatischer Aufbau und Wartung der Pfad-Tabellen (Eine gewisse Selbstorganisation wäre wünschenswert)
• Technische Darstellung der (variablen) Pfadangaben innerhalb der Message

Einschränkungen helfen immer:

• Die Endunkte jedes Message-Pfades

TARGET.pfad1.pfad2....pfadx.SOURCE

müssen die Programm selber wissen. Also, warum Applic-A ausgerechnet an FUNC-1 senden will, ist hier nicht das Thema.

• Wir betrachen vornehmlich die Verbindungen IP, RS232 u. I2C. (Wenn möglich, wollen wir aber für weitere Kommunikationsarten die Türen offen lassen(CAN, CBUS, etc.).
• Beim I2C-Bus nehmen wir an, daß ein Rechner immer nur an einem Bus hängt
• weiters gehen wir bei I2C von 7-Bit Adressen aus

Address-Header

Entgegen den ersten Ansätzen wird die Sache doch etwas komplizierter. Dieser Header besteht aus zwei Pfadangaben unterschiedlicher Länge (Ziel-Pfad u. Absender). Überall, wo eine Message ankommt, ist folgendes zu tun:

• Abtrennen der ersten Ziel-Pfad-Angabe und Interpretation
• Einfügen der aktuellen Retour-Pfad-Angabe an die ersten Stelle der Absenderadresse
• Weitersenden (oder Durchführung) der Message

Die anderen Teile der Pfadangaben sind an dieser Stelle uninteressant und brauchen auch nicht "verstanden" zu werden.

Damit ist schon mal klar, daß wir sowohl für den Ziel- als auch den Absenderpfad eine Längenangabe brauchen werden

Beispiel:

4 Ziel: I2C (0x8A) / FUNC-1

Absender: I2C (0x8E) / RS232 () / IP (Sock-1) / APPLIC (A)

• Diese Message kommt bei der UART 1 (die einzige) rein.
• die neue erste Stelle des Retour-Pfades ist also UART (1)
• Die an dieser Stelle erste Pfadangabe I2C(0x8A) heißt, daß das I2C-Modul etwas tun muß, nämlich senden an 0x8A
• dadurch gibt es eine weitere neue erste Stelle des Retour-Pfades, nämlich die eigene I2C-Adresse

Weitergeschickt wird also

Ziel: FUNC-1

Absender: I2C (0x8C) / UART () / I2C (0x8E) / RS232 () / IP (Sock-1) / APPLIC (A)

Und natürlich die Nutz-Daten.

Pfadangaben

Was ist denn (dzt.) in einer einzelnen Pfadangabe darzustellen ?

• Typ und Wert
  • I2C u. Adresse (7-Bit)
  • UART u. ev. eine Nummer 1, 2,..
  • RS232 das ist eigentlich das Gleiche wie UART oder COM
  • IP u. Socket da müßte man schon mit einem 16-Bit Wort rechnen
  • Funktions-ID. Auch da haben wir bisher 16 Bit festgelegt.

Wenn man da noch die Möglichkeit einer vollständigen IP-Adresse dazunimmt, würden wir auch noch entweder Text ("www.nirwana.com") oder eine IP-Addresse (32-Bit) + Port (16-Bit) unterbringen.

Was heißt denn eigentlich "Typ" ? Nun, im Grunde muß daraus nur eine bestimmte Programm-funktion abgeleitet werden, die dann auch ihren "Wert" bekommen kann. Wie kann man eine sowas identifizieren ?

• Einfach ein Index (die soundsovielte Funktion)
• Eine Direktadresse (wohl nur theoretisch)
• Eine ID (mit Tabelle)

Damit wir nicht irgendeinen kleinen Controller als Zwischenstation durch zu lange Messages oder Tabellen überfordern, ist es wohl ratsam, ein wenig Bits zu quetschen (Huffman läßt grüßen).

• I2C Adressen haben im LSB-Bit immer NULL (das ist ja das R/W Bit), also sagen wir einfach, ein Pfad-Byte, dessen LSB = 0 ist, ist grundsätzlich Typ=I2C und gleichzeitig die Adresse.
• Ist das LSB = 1, kommts jetzt auf das nächste Bit an.
• ist das NULL, gelten die restlichen 6 Bit als Funktionsindex, also eine Zahl 0-63. Das wird bei kleinen µC meistens auch schon reichen. Wenn wir noch festlegen, daß Index 0-3 immer eine UART (RS232 od. COM) bezeichnet, kommen wir auch da mit einem Byte aus. Das ist ja schon mal fein.
• es geht weiter wie dargestellt.
• "reserved" ist im Moment noch offen, da könnten wir z.B. sagen, daß die verbliebenen 4 Bit im ersten Byte eine Längenangabe sind, wieviele Type- und Wert-Bytes noch folgen.

Pfadlänge

Wenn im Adress-Header die Pfadlängen nicht als Byteanzahl angegeben werden, sondern als "Anzahl Pfadangaben", können wir mit einem Längenbyte auskommen

• High-Nibble: Anzahl Pfade Zieladresse
• Low-Nibble: Anzahl Pfade Absender.

Das hieße, es können maximal 15 "Hops" in einer Richtung angegeben werden, das sollte aber reichen.

Der Vorteil: je kleiner ein µC ist (wenige Funktionen) desto kürzer sind auch die zu verarbeitenden Pfad-Angaben.

Pfad-Tabellen

Bei einer gleichbleibenden Netzwerk-Konfiguration ist es natürlich denkbar, daß die Tabelle mit den Pfadangaben, die ja vornehmlich von den PC-Programmen gebraucht wird, auch als Konfigurations-File gespeichert und gewartet wird.

Doch gerade, wenn man noch beim Entwickeln ist, kann sich doch laufend etwas daran ändern. Und da ja über IP auch die Teilnahme von irgendeinem PC von weiss-gott-wo möglich ist, ist es mühsam, alles immer auf dem neuesten Stand zu halten.

Wie gesagt, auf µControllern ist Speicherplatz immer knapp und die haben ja auch noch was anderes zu tun. Doch gerade der "RN-SERVER" auf dem PC (s.o.) ist ein guter Platz, solche möglicherweise recht umfangreiche Tabellen zu führen und zu speichern. Doch, abgesehen von der Möglichkeit einer manuellen Eingabe, wie kommt so ein Programm zu den ganzen Pfad-Angaben ?

Offensichtlich müßte (beim Startup) jeder Rechner eine Liste der Funktionen, die er anbietet, bei dem "Router" abliefern. Dazu müßt er aber erstmal den Pfad zum Router wissen.

Startup

Broadcast

Ein Broadcast ist eine Message ohne Zielangabe, was heißt: "an alle". Und jede Station, die sowas empfängt, leitet diese Message ( + Verlängerung des Retour-Pfades) auf allen ihr zur Verfügung stehenden Kommunikationswegen weiter (natürlich nicht dort, wo der Broadcast reingekommen ist).

Bei I2C wird ein Broadcast als GCA (General Call Address) formuliert. Das ist ganz einfach die I2C-Adresse NULL. Und sowas können alle Slaves gleichzeitig empfangen. Das folgenden Byte muss dann die Absenderadress mit R/W Bit = "1" haben, dann ist das Ganze auch wirklich I2C Standard (die restliche Message dürfen wir frei definieren, was wir auch tun).

Diese Messages landen dann letztlich auch beim Router. Und der kann nun seine "Routing-Tables" anlegen.

Wenn also jeder Rechner so einen Broadcast für jede Funktion z.B. beim Starten macht, könnte ja die Sache damit erledigt sein.

Probleme:

• die Kommunikation über eine Uart ist dramatisch langsamer als auf dem I2C-Bus. Bei, angenommen, 9600 Baud wird in einer mS gerade mal ein Byte transportiert, auf dem I2C-Bus sind das aber bei 400 kHz in der selben Zeit etwa 50 Byte. D.h., an jedem Übergang zu einer UART entsteht ein ziemlicher Stau.
• Wenn die einzelnen Rechner nicht zur gleichen Zeit gestartet werden, ist es ziemlich ungewiß, ob es auch wirklich alle Broadcast Messages bis zu unserem Router geschafft haben.
• Ähnlich, wenn eine Verbindung (Rs232 od. I2C) überhaupt erst später hergestellt wird.

Autor

• PicNick

Siehe auch

• Network Controller/PC
• Network Controller/PC Vermittlung
• Network Controller/PC Schichten
• Network Controller/PC Spezifikationen
• Kommunikation/Protokolle