|
|
| Zeile 33: |
Zeile 33: |
| | <center>[[Bild:Rncomtable.png]]</center> | | <center>[[Bild:Rncomtable.png]]</center> |
| | | | |
| − | =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 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.
| |
| | | | |
| | =Weblinks/Download= | | =Weblinks/Download= |
In dieser Version werden die Festlegungen getroffen, die für ein kleines Controller/PC Netzwerk erforderlich sind. Beispielprogramme, Templates und Libraries für PC und µC sind teilweise fertig, teilweise in Entstehung, und können dann mit Download geholt werden.
Diese Restriktionen vereinfachen die Programmentwicklung doch sehr und sollten trotzdem für kleinere Systeme ausreichen.
Diese Tabelle(n) führt das PC-Programm "RN_SERVER".
Wenn eine Message über IP hereinkommt, wird
