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.
- Für µC-Programme liegt der Schwerpunkt vorerst auf Bascom, C-Libraries der Kern-Funktionen sind aber vorgesehen.
- PC-seitig soll der RN-Server erstmal den Abschluß bilden, die eigentlichen Anwendungen muß ich mangels VB-Erfahrung den Spezialisten überlassen, soweit sie mitspielen wollen. Ich selbst kann nur know-how für MS Visual C++ liefern.
Inhaltsverzeichnis
Das Netzwerk
Teilnehmer
- Ein RNBFRA 1.2 Board, mit
- Powerport
- Outputport
- Expansionport (Input)
- AT90S2313 als Coprozesser, mit dem Servoprogramm "RNSXNET". Das ist eine Abwandlung des RNS-Servers für Netzwerke
- Ein Zusatzboard (Eigenbau) mit einem Atmega16
- Ein PC, der mit COM1 (RS232) mit dem RNBFRA Board verbunden ist
- das PC-Programm "RN_SERVER.EXE, das das Routing übernimmt
- mehrere PC-Anwendungen
Konzept 0.1
- Für die PC-Anwendungen ist der Aufbau des Controller-Netzwerkes transparent, d.h. die Adressierung erfolgt (normalerweise) mit 16-Bit ID-Codes
- µC seitig sind fix 2 Ziel- und Absenderpfadangaben festgelegt. In dieser Version generell in der 8-Bit Variante, die den (7-Bit) I2C-Adressbereich abdeckt und für maximal 64 µC Anwendungen ausreicht.
Diese Restriktionen vereinfachen die Programmentwicklung doch sehr und sollten trotzdem für kleinere Systeme ausreichen.
Details zu Messages:
Routing Tables
Diese Tabelle(n) führt das PC-Programm "RN_SERVER". Wenn eine Message über IP hereinkommt, wird
- Target-ID in der Ziel-Tabelle gesucht, die Message wird dann mit den gefundenen Pfadangaben über COM(1) weitergeschickt.
- Für Source-ID wird ein Tabelleneintrag generiert bzw. ein bestehender verwendet, die Referenz wird als Absende-Pfad eingetragen, der zweite Source-Pfad bleibt leer (NULL).
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.
Weblinks/Download
http://www.oldformation.at/electronic/download/down.htm
Autor
Siehe auch
