Network Controller/PC Routing - Versionsgeschichte

PicNick: /* Siehe auch */

2006-10-29T14:03:50Z

‎Siehe auch

PicNick: /* Siehe auch */

2006-10-10T11:40:56Z

‎Siehe auch

PicNick am 10. Oktober 2006 um 11:39 Uhr

2006-10-10T11:39:53Z

PicNick: /* Pfadangaben */

2006-10-10T11:29:58Z

‎Pfadangaben

PicNick am 10. Oktober 2006 um 11:28 Uhr

2006-10-10T11:28:32Z

Änderungen zeigen

PicNick: /* Network Controller/PC Routing */

2006-09-18T10:58:24Z

‎Network Controller/PC Routing

PicNick am 18. September 2006 um 10:58 Uhr

2006-09-18T10:58:09Z

PicNick am 18. September 2006 um 10:49 Uhr

2006-09-18T10:49:01Z

PicNick: /* Messages (Nachrichten) */

2006-09-17T07:42:32Z

‎Messages (Nachrichten)

PicNick: /* Broadcast Message */

2006-09-17T07:35:57Z

‎Broadcast Message

@@ Zeile 77: / Zeile 77: @@
 =Siehe auch=
 *[[Network Controller/PC]]
 *[[Network Controller/PC Spezifikationen]]
 *[[Kommunikation/Protokolle]]

@@ Zeile 77: / Zeile 77: @@
 =Siehe auch=
 *[[Network Controller/PC]]
 *[[Network Controller/PC Schichten]]
 *[[Network Controller/PC Spezifikationen]]

@@ Zeile 1: / Zeile 1: @@
 Routing ist die Methode, Nachrichten von einem Programm(teil) zu einem anderen zu transportieren.
 =Generierung der Routing Tables=
 ==Atmega32-Anmeldung==

← Nächstältere Version		Version vom 10. Oktober 2006, 11:29 Uhr
Zeile 76:		Zeile 76:


−	~~====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====

← Nächstältere Version		Version vom 18. September 2006, 10:58 Uhr
Zeile 1:		Zeile 1:
−	~~=Network Controller/PC Routing=~~

	Routing ist die Methode, Nachrichten von einem Programm(teil) zu einem anderen zu transportieren.		Routing ist die Methode, Nachrichten von einem Programm(teil) zu einem anderen zu transportieren.

@@ Zeile 5: / Zeile 5: @@
 ==Messages (Nachrichten)==
 <center>[[Bild:Rncomformat.png]]</center>
 Je nach physikalischem Transportmittel wird die Message verschieden eingepackt.
@@ Zeile 28: / Zeile 14: @@
 *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.
-Uns interessiert eigentlich mal 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''' .
 ==Netzwerk==
 Und um die Sache zu diskutieren, nehmen wir einfach eine konkrete PC u. µC Konfiguration an

@@ Zeile 9: / Zeile 9: @@
 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
+*Zieladresse (Target)
-*Absender
+*Absender    (Source)
 *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.
+Uns interessiert eigentlich mal 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''' .
-−
-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.
+Zieladresse und Absender sind äquivalent. Sie beinhalten nicht '''einen''' Wert, sondern sind strukturierte '''Pfadangaben''' .
 ==Netzwerk==

@@ Zeile 212: / Zeile 212: @@
 =====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.
+Jeder Rechner schickt vom Start weg jede Sekunde (kann man auch variieren, wesentlich schneller ist allerdings kontraproduktiv) eine Broadcast-"HEartbeat" Message weg mit folgenden Aufbau.
-−
- Und, wohlgemerkt: Fürs Erste immer nur von der gleichen Funktion ! (Erklärung folgt)
 '''I2C-Format'''
@@ Zeile 220: / Zeile 218: @@
 *GCA
 *eigene I2C Adresse  (+1, s.o)
 *Pfad-Header
-**Ziel: void (leer)
+**Ziel: "HEARTBEAT"
-**Absender: Geräteindex einer Netzwerk-Funktion
+**Absender: void  (leer)
-*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'''
@@ Zeile 233: / Zeile 226: @@
 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
+**Ziel: "HEARTBEAT"
-**Absender: Geräteindex einer Netzwerk-Funktion
+**Absender: void  (leer)
-*Daten sind wie bei I2C
 '''IP'''