(→Siehe auch) |
|||
| (16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | + | Für das Projekt "Network Controller/PC" werden hier die ganz konkreten Spezifikationen angelegt. | |
| − | Für das Projekt "Network Controller/PC" werden hier die ganz konkreten Spezifikationen angelegt | + | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | == | + | =Layer-0= |
| + | Für die unterste Schicht, Layer-0, gibt es drei Versionen: | ||
| + | ==IP (TCP/IP)== | ||
| + | <center>[[Bild:Rncomformatip.png]]</center> | ||
| + | Die Länge ist "host-order" d.h. low-Byte zuerst, immer exklusive Länge, d.h. für 4 Bytes Layer-1 Daten werden insgesamt 6 Byte übertragen. | ||
| + | ==UART== | ||
| + | <center>[[Bild:Rncomformatrs.png]]</center> | ||
| + | [[Network_Controller/PC_RS232_mit_Windows#Network_Controller.2FPC_RS232_mit_Windows|RS232 mit Windows]] | ||
| + | |||
| + | ==I2C== | ||
| + | <center>[[Bild:Rncomformati2c.png]]</center> | ||
| + | *Fwd die Empfänger-I2C-Adresse. In der vorliegenden Version werden nur 7-Bit Adressen zugelassen. Für Broadcasts (HBT, ASK) wird GCA (= NuLL) verwendet. | ||
| + | *Bck ist immer die Absender-I2C-Adresse. Aus formalen Gründen wird immer das Bit 0 gesetzt. | ||
| + | |||
| + | Programmiertechnisch ist dazu wohl nicht viel zu sagen. | ||
| + | |||
| + | |||
| + | =Layer-1 Version 0.1= | ||
| + | Hier sind es zwei Ausprägungen: Für die PC-Seite und für die Microcontroller | ||
| + | ==PC== | ||
| + | <center>[[Bild:Rncomlay1pc.png]]</center> | ||
| + | In dieser Version gibt es keine Pfadangaben, sondern immer 16-Bit IDs. Da sich eine IP-Verbindung ja als point-to-point darstellt, ist der Bedarf an Routing-Pfaden nicht sosehr gegeben. | ||
| + | ===ID (Identifier)=== | ||
| + | Die ID sollte eine systemweit eindeutige Adresse für ein Gerät sein. Also zum Beispiel ein ganz bestimmter AD-Converter auf einem Kontroller im Netzwerk. Oder die Steuerung für einen bestimmten Schrittmotor o.Ä. | ||
| + | ==µC== | ||
| + | <center>[[Bild:Rncomlay1uc.png]]</center> | ||
| + | T-1, T-2, S-1, S-2 sind in dieser Version immer 8-Bit Pfadangaben. In dieser Version sind nur zwei Pfadangaben je Richtung erlaubt, die sind aber auch immer da, selbst wenn der Inhalt NULL ist (void). | ||
| + | <center>[[Bild:pathsmall.png]]</center> | ||
| + | ===Pfade=== | ||
| + | Die Referenzen 0-63 brauchen nur innerhalb eines Rechners eindeutig zu sein. | ||
| + | Die ersten 8 Werte sind allerdings vordefiniert und für alle Rechner gleich | ||
| + | ====HBT Heartbeat==== | ||
| + | 0 (&H01) (Broadcast) | ||
| + | Jeder Rechner, der RnCom-Messages verarbeiten kann, sendet periodisch (1-4 sek) einen Message an dieses Ziel. Wenn das Heartbeat Signal länger als 5 sekunden ausfällt, wird das Geräte und alles, was darunterhängt, aus den Routing Tabellen entfernt und gilt als nicht erreichbar. Wenn in der Zeit allerdings eine andere Message gesendet wurde, kann für diese Periode der Hearbeat auch unterbleiben. | ||
| + | ====NXT Next==== | ||
| + | 1 (&H05) Frage nach Geräteliste Daten: 8-Bit Geräteindex | ||
| + | Der Empfänger sendet von dem nächsten Gerät, das dem Geräteindex folgt, eine "IAM" Message. | ||
| + | ====IAM "I am"==== | ||
| + | 2 (&H09) Information über ein Gerät Daten: 8-Bit Device-Index, 16-Bit ID | ||
| + | Eine Meldung über ein Gerät, mit Index und ID. NACH dem letzen Gerät wird der Index "FF" gesendet und kEINE ID | ||
| + | ====ASK Suchen ID==== | ||
| + | 3 (&H0D) (Broadcast) Daten: 8-Bit NULL, 16-Bit ID | ||
| + | Eine Frage an alle Rechner, ob ihnen die ID bekannt ist. wenn ja, wird eine "IAM" Message von dort zurückgesendet | ||
| + | ====UART==== | ||
| + | 4 (&H11) Die UART (In Vers-0.1 wird von maximal 1 UART je Rechner ausgegangen) | ||
| + | Das aktuelle Ziel ist die UART, d.h. die Message wird dort weitergeleitet, ohne den restlichen Inhalt zu interpretieren. Es ist somit das Äquivalent zu einer I2C-Adresse. | ||
| + | ====VAL Meßwert==== | ||
| + | 5 (&H15) (Broadcast) Daten: Source-Abhängig | ||
| + | Geräte können mit dieser Message "an alle" einen aktuellen Meßwert bekanntgeben. Es ist Sache der Empfänger, diese Message zu interpretieren. | ||
| + | ====reserviert==== | ||
| + | *6 (&H19) | ||
| + | *7 (&H1D) | ||
| + | |||
| + | =Datenaufbau= | ||
| + | ==Kontroll-Byte== | ||
| + | Um nicht ein eigenes Feld Messagetyp zu benötigen, ist es zweckmäßig, das erste Byte der Nutzdaten immer als "Daten-Kontrollbyte" festzulegen. Dadurch ist ohne generelle Erweiterung auch eine "ACK/NACK" Benachrichtigung möglich. Denn solche Nachrichten müssen oft an Stellen generiert werden, die von den Dateninhalten eigentlich keine Ahnung haben. | ||
| + | |||
| + | Wenn wir also die beiden Werte ACK/NACK reservieren, können die anderen 254 Werte von den Applikationen frei verwendet werden (z.B. als Command-Byte), was in unserer dzt. Version wohl genügen sollte. | ||
| + | |||
| + | *'''&H00 - &HFD''' | ||
| + | Zur freien Verwendung | ||
| + | *'''&HFE''' ACK | ||
| + | Dieser Wert wird ausschließlich von End-Geräten als "ok" verwendet oder von I2C Agents, wenn die Übertragung technisch gklappt hat. Zusätzlich Daten sind möglich. | ||
| + | *'''&HFF''' (NACK/END) | ||
| + | Kann sowohl von Endgeräten als auch von Zwischenstationen erzeugt werden. Hier können zusätzlich noch für einen "Statuscode" Vereinbarungen zweckmäßig sein. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | =Autor= | ||
* [[Benutzer:PicNick|PicNick]] | * [[Benutzer:PicNick|PicNick]] | ||
| − | + | =Siehe auch= | |
*[[Network Controller/PC]] | *[[Network Controller/PC]] | ||
| − | *[[Network Controller/PC | + | *[[Network Controller/PC Praxis]] |
*[[Kommunikation/Protokolle]] | *[[Kommunikation/Protokolle]] | ||
*[[Betriebssystem für Bascom]] | *[[Betriebssystem für Bascom]] | ||
Aktuelle Version vom 15. Oktober 2006, 16:55 Uhr
Für das Projekt "Network Controller/PC" werden hier die ganz konkreten Spezifikationen angelegt.
Inhaltsverzeichnis
Layer-0
Für die unterste Schicht, Layer-0, gibt es drei Versionen:
IP (TCP/IP)
Die Länge ist "host-order" d.h. low-Byte zuerst, immer exklusive Länge, d.h. für 4 Bytes Layer-1 Daten werden insgesamt 6 Byte übertragen.
UART
I2C
- Fwd die Empfänger-I2C-Adresse. In der vorliegenden Version werden nur 7-Bit Adressen zugelassen. Für Broadcasts (HBT, ASK) wird GCA (= NuLL) verwendet.
- Bck ist immer die Absender-I2C-Adresse. Aus formalen Gründen wird immer das Bit 0 gesetzt.
Programmiertechnisch ist dazu wohl nicht viel zu sagen.
Layer-1 Version 0.1
Hier sind es zwei Ausprägungen: Für die PC-Seite und für die Microcontroller
PC
In dieser Version gibt es keine Pfadangaben, sondern immer 16-Bit IDs. Da sich eine IP-Verbindung ja als point-to-point darstellt, ist der Bedarf an Routing-Pfaden nicht sosehr gegeben.
ID (Identifier)
Die ID sollte eine systemweit eindeutige Adresse für ein Gerät sein. Also zum Beispiel ein ganz bestimmter AD-Converter auf einem Kontroller im Netzwerk. Oder die Steuerung für einen bestimmten Schrittmotor o.Ä.
µC
T-1, T-2, S-1, S-2 sind in dieser Version immer 8-Bit Pfadangaben. In dieser Version sind nur zwei Pfadangaben je Richtung erlaubt, die sind aber auch immer da, selbst wenn der Inhalt NULL ist (void).
Pfade
Die Referenzen 0-63 brauchen nur innerhalb eines Rechners eindeutig zu sein. Die ersten 8 Werte sind allerdings vordefiniert und für alle Rechner gleich
HBT Heartbeat
0 (&H01) (Broadcast) Jeder Rechner, der RnCom-Messages verarbeiten kann, sendet periodisch (1-4 sek) einen Message an dieses Ziel. Wenn das Heartbeat Signal länger als 5 sekunden ausfällt, wird das Geräte und alles, was darunterhängt, aus den Routing Tabellen entfernt und gilt als nicht erreichbar. Wenn in der Zeit allerdings eine andere Message gesendet wurde, kann für diese Periode der Hearbeat auch unterbleiben.
NXT Next
1 (&H05) Frage nach Geräteliste Daten: 8-Bit Geräteindex Der Empfänger sendet von dem nächsten Gerät, das dem Geräteindex folgt, eine "IAM" Message.
IAM "I am"
2 (&H09) Information über ein Gerät Daten: 8-Bit Device-Index, 16-Bit ID Eine Meldung über ein Gerät, mit Index und ID. NACH dem letzen Gerät wird der Index "FF" gesendet und kEINE ID
ASK Suchen ID
3 (&H0D) (Broadcast) Daten: 8-Bit NULL, 16-Bit ID Eine Frage an alle Rechner, ob ihnen die ID bekannt ist. wenn ja, wird eine "IAM" Message von dort zurückgesendet
UART
4 (&H11) Die UART (In Vers-0.1 wird von maximal 1 UART je Rechner ausgegangen) Das aktuelle Ziel ist die UART, d.h. die Message wird dort weitergeleitet, ohne den restlichen Inhalt zu interpretieren. Es ist somit das Äquivalent zu einer I2C-Adresse.
VAL Meßwert
5 (&H15) (Broadcast) Daten: Source-Abhängig Geräte können mit dieser Message "an alle" einen aktuellen Meßwert bekanntgeben. Es ist Sache der Empfänger, diese Message zu interpretieren.
reserviert
- 6 (&H19)
- 7 (&H1D)
Datenaufbau
Kontroll-Byte
Um nicht ein eigenes Feld Messagetyp zu benötigen, ist es zweckmäßig, das erste Byte der Nutzdaten immer als "Daten-Kontrollbyte" festzulegen. Dadurch ist ohne generelle Erweiterung auch eine "ACK/NACK" Benachrichtigung möglich. Denn solche Nachrichten müssen oft an Stellen generiert werden, die von den Dateninhalten eigentlich keine Ahnung haben.
Wenn wir also die beiden Werte ACK/NACK reservieren, können die anderen 254 Werte von den Applikationen frei verwendet werden (z.B. als Command-Byte), was in unserer dzt. Version wohl genügen sollte.
- &H00 - &HFD
Zur freien Verwendung
- &HFE ACK
Dieser Wert wird ausschließlich von End-Geräten als "ok" verwendet oder von I2C Agents, wenn die Übertragung technisch gklappt hat. Zusätzlich Daten sind möglich.
- &HFF (NACK/END)
Kann sowohl von Endgeräten als auch von Zwischenstationen erzeugt werden. Hier können zusätzlich noch für einen "Statuscode" Vereinbarungen zweckmäßig sein.
Autor
Siehe auch
