Inhaltsverzeichnis
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.
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.
Autor
Siehe auch