Aus RN-Wissen.de
Wechseln zu: Navigation, Suche
LiFePO4 Speicher Test

 
(→‎Siehe auch)
 
(18 dazwischenliegende Versionen von 2 Benutzern 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
+
====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.  
  
−
<center>[[Bild:rncom_conf.PNG]]</center>
+
Das hieße, es können maximal 15 "Hops" in einer Richtung angegeben werden, das sollte aber reichen.  
  
−
*Es gibt auf einem PC zwei Programme (Applikationen), die über IP (mit Sockets) mit einem "Server" verbunden sind,
 
−
*der wiederum über die RS232 mit einem µC Kontakt hat.
 
−
*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===
+
Der Vorteil: je kleiner ein µC ist (wenige Funktionen) desto kürzer sind auch die zu verarbeitenden Pfad-Angaben.
−
====logische Darstellung====
+
−
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
 
−
 
−
2 '''Ziel''': I2C(0x8D) / UART () / I2C (0x8A) / FUNC-1  '''Absender''': IP (Sock-1) / APPLIC
 
−
 
−
3 '''Ziel''': UART () / I2C (0x8A) / FUNC-1  '''Absender''': RS232 () / IP (Sock-1) / APPLIC
 
−
 
−
4 '''Ziel''': I2C (0x8A) / FUNC-1  '''Absender''': I2C (0x8E) / RS232 () / IP (Sock-1) / APPLIC
 
−
 
−
5 '''Ziel''': FUNC-1  '''Absender''':  I2C (0x8C) / UART () / I2C (0x8E) / RS232 () / IP (Sock-1) / APPLIC
 
−
 
−
In der Zeichnung habe ich die "5" auch mit "4" bezeichnet. buuh !
 
−
 
−
====physikalische Darstellung====
 
−
Das ist natürlich so oder so ein ellenlanger Graus. 
 
−
 
−
<center>[[Bild:path.PNG]]</center>
 
  
 
=Autor=
 
=Autor=
Zeile 107: 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]]

Aktuelle Version vom 29. Oktober 2006, 15:03 Uhr

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.

Rncomiam1.png

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:

Rncomflow1.png

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.

Rncomiam2.png

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.

Rncomflow2.png

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)

Rncomhbt1.png

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.

Rncomhbt2.png

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.

Rncomnxt2.png

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

Von „https://rn-wissen.de/wiki/index.php?title=Network_Controller/PC_Routing&oldid=9440“

LiFePO4 Speicher Test