Aus RN-Wissen.de
| (8 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | 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, [[Network_Controller/ | + | 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, [[Network_Controller/PC#Weblinks/Download|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. | *Für µC-Programme liegt der Schwerpunkt vorerst auf Bascom, C-Libraries der Kern-Funktionen sind aber vorgesehen. | ||
| Zeile 17: | Zeile 17: | ||
**mehrere PC-Anwendungen | **mehrere PC-Anwendungen | ||
| − | |||
| − | |||
| − | |||
| − | + | =Messages (Nachrichten)= | |
| + | <center>[[Bild:Rncomformat.png]]</center> | ||
| − | + | 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 (Target) | |
| − | + | *Absender (Source) | |
| − | *Target | + | *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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | '''Details zu Messages:''' | |
| − | + | *[[Network Controller/PC Spezifikationen]] | |
| − | == | + | ==Adressen== |
| − | + | Für die PC-Anwendungen ist der Aufbau des Controller-Netzwerkes transparent, d.h. die Adressierung erfolgt (normalerweise) mit 16-Bit ID-Codes | |
| − | + | ||
| − | + | ||
| − | = | + | ==Pfade== |
| − | + | Was ist denn 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> | |
| − | |||
| − | |||
| − | |||
=Weblinks/Download= | =Weblinks/Download= | ||
| Zeile 98: | Zeile 73: | ||
=Siehe auch= | =Siehe auch= | ||
*[[Network Controller/PC Routing]] | *[[Network Controller/PC Routing]] | ||
| − | |||
*[[Network Controller/PC Spezifikationen]] | *[[Network Controller/PC Spezifikationen]] | ||
| + | *[[Network Controller/PC Praxis]] | ||
*[[Kommunikation/Protokolle]] | *[[Kommunikation/Protokolle]] | ||
Aktuelle Version vom 10. Oktober 2006, 13:13 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
Messages (Nachrichten)
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 (Target)
- Absender (Source)
- 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.
Details zu Messages:
Adressen
Für die PC-Anwendungen ist der Aufbau des Controller-Netzwerkes transparent, d.h. die Adressierung erfolgt (normalerweise) mit 16-Bit ID-Codes
Pfade
Was ist denn 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.
Weblinks/Download
http://www.oldformation.at/electronic/download/down.htm
Autor
Siehe auch