(→Konzept 0.1) |
|||
| Zeile 25: | Zeile 25: | ||
'''Details zu Messages:''' | '''Details zu Messages:''' | ||
*[[Network Controller/PC Spezifikationen]] | *[[Network Controller/PC Spezifikationen]] | ||
| + | |||
| + | |||
| + | ==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> | ||
=Routing Tables= | =Routing Tables= | ||
Version vom 10. Oktober 2006, 12:30 Uhr
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:
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.
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).
Weblinks/Download
http://www.oldformation.at/electronic/download/down.htm
Autor
Siehe auch