|
|
| (9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| − | =Network Controller/PC Routing= | + | 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. |
| | | | |
| − | Das Routing ist ganz einfach die Methode, Nachrichten von einem Programm(teil) zu einem anderen zu transportieren.
| + | 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 (Nachrichten)== | + | ==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. |
| | | | |
| − | <center>[[Bild:msglevel.PNG]]</center>
| + | =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 ? |
| | | | |
| − | Je nach physikalischem Transportmittel wird die Message verschieden eingepackt.
| + | 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) |
| | | | |
| − | Der Vergleich mit einer Briefsendung ist zulässig, da wie dort gibt es
| + | =Next Device (NXT)= |
| − | *Zieladresse
| + | 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. |
| − | *Absender
| + | <center>[[Bild:Rncomnxt2.png]]</center> |
| − | *Daten
| + | 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). |
| | | | |
| − | 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.
| + | Dadurch bekommt er nach und nach sämtliche IDs, die auf dem Atmega16 zur Verfügung stehen. |
| | | | |
| − | Zieladresse und Absender sind äquivalent. Sie beinhalten nicht '''einen''' Wert, sondern sind strukturierte '''Pfadangaben''' .
| + | ==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. |
| | | | |
| − | 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
| |
| − |
| |
| − | <center>[[Bild:rncom_conf.PNG]]</center>
| |
| − |
| |
| − | *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
| |
| − |
| |
| − |
| |
| − | <center>'''Offensichtlich braucht es für Ziel- und Absenderadressen variable Längen'''</center>
| |
| − |
| |
| − | 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.
| |
| − |
| |
| − | <center>[[Bild:path.PNG]]</center>
| |
| | | | |
| | ====Pfadlänge==== | | ====Pfadlänge==== |
| Zeile 183: |
Zeile 71: |
| | 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. |
| | | | |
| − | ===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.
| |
| − |
| |
| − | <center>'''Ziel ist also so eine Art "Plug & Play" Methode'''</center>
| |
| − |
| |
| − |
| |
| − | =====Broadcast Message=====
| |
| − | Jeder Rechner schickt vom Start weg jede Sekunde (kann man auch variieren, wesentlich schneller ist allerdings kontraproduktiv) eine Broadcast-"Enlist" Message weg mit folgenden Aufbau.
| |
| − |
| |
| − | Und, wohlgemerkt: Fürs Erste immer nur von der gleichen Funktion ! (Erklärung folgt)
| |
| − |
| |
| − | '''I2C-Format'''
| |
| − |
| |
| − | *GCA
| |
| − | *eigene I2C Adresse (+1, s.o)
| |
| − | *Typ="ENLIST" (codiert)
| |
| − | *Pfad-Header
| |
| − | **Ziel: void (leer)
| |
| − | **Absender: Geräteindex einer Netzwerk-Funktion
| |
| − | *Daten
| |
| − | **Netzwerk-Funktion-ID
| |
| − | **Geräteindex der vorher verteilten Netzwerk-Funktion (Am Anfang NULL, weils die erste ist)
| |
| − | **Optional:Gerätebeschreibung (darüber muß man noch reden, ist hier aber mal egal)
| |
| − |
| |
| − | '''UART-Format'''
| |
| − |
| |
| − | Bei point-to-point gibt's ja in dem Sinne keinen Broadcast, also geben wir als Ziel einen für das Enlisting vereinbarten und reservierten Geräteindex 0-63 an.
| |
| − | *Pfad-Header
| |
| − | **Ziel: Enlisting-Index
| |
| − | **Absender: Geräteindex einer Netzwerk-Funktion
| |
| − | *Daten sind wie bei I2C
| |
| − |
| |
| − | '''IP'''
| |
| − | Auch socket-socket ist ja point-to-point, also gleich wie Uart-Format.
| |
| − |
| |
| − | Dadurch, daß jeder Rechner das regelmäßig wegschickt, wird auch bei nachträglichem Verbindungsaufbau oder Startup irgendwann mal bei jedem Router (wenn es mehrere Router gibt) eine solche Message auftauchen.
| |
| | | | |
| | =Autor= | | =Autor= |
| Zeile 247: |
Zeile 77: |
| | =Siehe auch= | | =Siehe auch= |
| | *[[Network Controller/PC]] | | *[[Network Controller/PC]] |
| − | *[[Network Controller/PC Vermittlung]]
| |
| − | *[[Network Controller/PC Schichten]]
| |
| | *[[Network Controller/PC Spezifikationen]] | | *[[Network Controller/PC Spezifikationen]] |
| | *[[Kommunikation/Protokolle]] | | *[[Kommunikation/Protokolle]] |
Routing ist die Methode, Nachrichten von einem Programm(teil) zu einem anderen zu transportieren.
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.
Wird nun über IP diese ID als Target angesprochen, wird die UART-Message so aufgebaut:
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.
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.
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.
Um wirklich zu einem "Plug n'Play" Netzwerk zu kommen, sendet jeder RNCOM Rechner, das sind in der konkreten Konfiguration
regelmäßig (etwa jede Sekunde) eine Message mit dem Target "Heartbeat" (HBT) auf jeder ihm zur Verfügung stehenden Leitung weg. Zuerstmal:
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.
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:
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.
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.
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.
Wenn im Adress-Header die Pfadlängen nicht als Byteanzahl angegeben werden, sondern als "Anzahl Pfadangaben", können wir mit einem Längenbyte auskommen
Das hieße, es können maximal 15 "Hops" in einer Richtung angegeben werden, das sollte aber reichen.
