(→Siehe auch) |
|||
| (17 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | = | + | Routing ist die Methode, Nachrichten von einem Programm(teil) zu einem anderen zu transportieren. |
| + | =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. | ||
| + | <center>[[Bild:Rncomiam1.png]]</center> | ||
| + | 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: | ||
| + | <center>[[Bild:Rncomflow1.png]]</center> | ||
| + | ==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. | |
| + | <center>[[Bild:Rncomiam2.png]]</center> | ||
| − | ==Messages | + | ==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. | ||
| + | <center>[[Bild:Rncomflow2.png]]</center> | ||
| + | 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)== | ||
| + | <center>[[Bild:Rncomhbt1.png]]</center> | ||
| + | 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 [[Network_Controller/PC_Version_0.1#Messages|I2C Format]] gesendet, allerdings an die I2C-Addresse "GCA". Das ist einfach die Adresse NULL. | ||
| + | <center>[[Bild:Rncomhbt2.png]]</center> | ||
| + | 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. | |
| − | + | <center>[[Bild:Rncomnxt2.png]]</center> | |
| − | + | Durch die "NXT" Message wird am Atmega16 eine [[Network_Controller/PC_Version_0.1#Atmega16-Anmeldung|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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | ====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 | 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 | *High-Nibble: Anzahl Pfade Zieladresse | ||
| Zeile 178: | Zeile 69: | ||
| − | Der Vorteil: je kleiner ein µC ist (wenige Funktionen) desto kürzer sind auch die zu verarbeitenden Pfad-Angaben. | + | Der Vorteil: je kleiner ein µC ist (wenige Funktionen) desto kürzer sind auch die zu verarbeitenden Pfad-Angaben. |
| − | + | ||
| − | + | ||
| Zeile 188: | Zeile 77: | ||
=Siehe auch= | =Siehe auch= | ||
*[[Network Controller/PC]] | *[[Network Controller/PC]] | ||
| − | |||
| − | |||
*[[Network Controller/PC Spezifikationen]] | *[[Network Controller/PC Spezifikationen]] | ||
*[[Kommunikation/Protokolle]] | *[[Kommunikation/Protokolle]] | ||
Aktuelle Version vom 29. Oktober 2006, 15:03 Uhr
Routing ist die Methode, Nachrichten von einem Programm(teil) zu einem anderen zu transportieren.
Inhaltsverzeichnis
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.
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