Routing ist die Methode, Nachrichten von einem Programm(teil) zu einem anderen zu transportieren.
Inhaltsverzeichnis
Messages (Nachrichten)
Je nach physikalischem Transportmittel wird die Message verschieden eingepackt. Anm. IP: Das Längenwort (16-Bit) beinhaltet die Länge der Daten exklusive Längenwort. D.h, um z.B. vier Byte zu übertragen, werden insgesamt 6 Byte weggeschickt.
Der Vergleich mit einer Briefsendung ist zulässig, da wie dort gibt es
- Zieladresse (Target)
- Absender (Source)
- Daten
Uns interessiert zuerst einmal nur, wie eine solche Nachricht vom Sender zum Empfänger und ggf. wieder zurückkommt, 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 .
Generierung der Routing Tables
Atmega32-Anmeldung
Die Devices vom Atmeg32 melden sich aktiv beim Router an (Das Verfahren wird noch näher erläutert). Die Geräte direkt im Atmega32 vom RNBFRA-Board senden eine Message an das Pseudo-Target "IAM" (I am = "Ich bin") Als Absender wird die Kurzreferenz des Gerätes gesendet, die Daten beinhalten die 16-Bit ID des Gerätes.
Anm: Dass diese Meldung über "COMx" hereingekommen ist, wird vom Router ergänzt.
Messages an Atmega32
Wird nun über IP diese ID als Target angesprochen, wird die UART-Message so aufgebaut:
Atmega16-Anmeldung
Auch diese Devices melden sich aktiv. Der Atmega32 empfängt diese Message und leitet sie weiter wie dargestellt. dabei ergänzt er aber den Absender um die I2C Adresse des Atmega16, die ja als Backlink in der I2C-Message steht.
Beim PC landet diese Message genauso wir eine vom Atmega32, nur daß der Pfad aus zwei Einträgen besteht.
Messages an Atmega16
Völlig analog zu Messages an dem Atmega32, die Tatsache, daß dann über I2C weitergeroutet wird, ist für der PC unerheblich.
Auch hier wird der Sourcepfad um den Eintrag "UARTx" erweitert. Denn wenn eine Antwort kommen sollte, muß ja klargestellt sein, daß das Ziel über die UART zu erreichen ist.
Rückmeldungen
Wenn das Device nach Verarbeitung der Message-Daten etwas zurücksenden will, werden Target- und Source-Pfade vertauscht, der Ablauf ist dann analog wie beim Wegsenden der IAM Message, nur daß diesmal nicht mittels GCA, sondern gezielt an die I2C Backlink-Adresse gesendet wird.
Heartbeat (HBT)
Einige Fragen könnten da aufgetaucht sein
- Woher weiß der Atmega16 (oder der AT90S2313), daß er sein "IAM" Messages an den Atmega32 schicken muß bzw. soll ?
- Und woher kennt er dessen I2C Adresse ?
Um wirklich zu einem "Plug n'Play" Netzwerk zu kommen, sendet jeder RNCOM Rechner, das sind in der konkreten Konfiguration
- Atmega32
- Atmega16
- AT90S2313
regelmäßig (etwa jede Sekunde) eine Message mit dem Target "Heartbeat" (HBT) auf jeder ihm zur Verfügung stehenden Leitung weg. Zuerstmal:
Heartbeat UART (Atmega32)
Durch diese Message erfährt "Rnrouter" am PC, daß auf dem Com1-Port tatsächlich ein aktiver Rechner angeschlossen ist. Mehr eigentlich im Moment nicht.
Heartbeat I2C (Atmega16 u. 32, AT90S2313)
Auf I2C werden diese Heartbeats im I2C Format gesendet, allerdings an die I2C-Addresse "GCA". Das ist einfach die Adresse NULL.
6E*: Aus formalen Gründen (I2C Standard) wird bei GCA Messages dort immer das Bit 0 gesetzt. d.h. genaugenommen steht dort 6F. Das weiß aber auch der Empfänger und kann dieses Bit maskieren.
Durch die Ergänzung des Source-Pfades um die I2C-Backlink Adresse und Weiterleitung über UART erfährt der PC nun zwei Dinge:
- Es gibt einen I2C Bus
- Es gibt dort einen Rechner mit der I2C Adresse 6E (Atmega16) bzw. 68 (AT90S2313)
Next Device (NXT)
Mit diesen Weisheiten sendet nun "RNROUTER" am PC eine "NXT" Message ganz gezielt an die Pfade, von denen er nun Kenntnis hat. An den Atmega16 sendet er z.B.
Durch die "NXT" Message wird am Atmega16 eine eine "IAM" Message zurück generiert. In den Daten steht nun die ID (16-Bit) und eine Device-Nummer (0-FF), wobei FF heißt, es gibt keine IDs mehr.
Der PC trägt dieser Gerät nun in seine Tabellen ein. Und sofort danach sendet er wieder eine "NXT" Messager los, diesmal aber statt "0" in den Daten die Device-Nummer, die er gerade gekriegt hat (Außer bei "FF" natürlich, da hört er damit auf).
Dadurch bekommt er nach und nach sämtliche IDs, die auf dem Atmega16 zur Verfügung stehen.
Anmerkung
Wenn alle Mikrocontroller gleichzeitig eingeschaltet werden, ist natürlich dann Einiges auf dem Netz los. Das "Bottleneck" sind natürlich die UART-Verbindungen. Da aber kein Rechner eine "IAM" Meldung auf die Reise schickt, ohne daß er vorher ein "NXT" bekommen hat, regeln die UARTs den zulässigen Traffic gewissermaßen selbst.
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.
Autor
Siehe auch