Aus RN-Wissen.de
Wechseln zu: Navigation, Suche
Laderegler Test Tueftler Seite

(Reservierte ID)
 
Zeile 1: Zeile 1:
Hier sollen die PC-seitigen Vereinbarungen, die sich doch einigermaßen von der µC Seite unterscheiden, gesondert besprochen werden  
+
Hier sollen die PC-seitigen Vereinbarungen, die sich doch einigermaßen von der µC Seite unterscheiden, gesondert besprochen werden.
 +
 
  
 
=Layer-0=
 
=Layer-0=
 
<center>[[Bild:Rncomformatip.png]]</center>
 
<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. Eine der Möglichkeiten, sowas zu lesen (VB2005):
+
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.  
<pre>
+
    If netStream.DataAvailable Then
+
          bytesRead = netStream.Read(buffer, 0, 2) ' 2 Bytes lesen (d.i. das Längen-UShort)
+
          Required = buffer(0)              ' Für max. 255 Bytes reicht das low-order Byte des UShort
+
          bytesRead = netStream.Read(buffer, 0, Required) ' Jetzt die Message-Daten
+
' in "buffer" stehen nun nurmehr die Layer-1 Daten
+
' "bytesRead" beinhaltet die Länge davon
+
    End If
+
</pre>
+
  
 
=Layer-1=
 
=Layer-1=
Zeile 35: Zeile 27:
 
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.  
 
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'''
+
*'''&H01'''
Zur freien Verwendung
+
Das folgende Datenbereich beinhaltet KEY=VALUE Angaben, wie bei "logon" beschrieben
 +
*'''&H02 - &HFD'''
 +
dzt. fur freien Verwendung
 
*'''&HFE''' ACK
 
*'''&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.
 
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.

Aktuelle Version vom 13. November 2006, 13:17 Uhr

Hier sollen die PC-seitigen Vereinbarungen, die sich doch einigermaßen von der µC Seite unterscheiden, gesondert besprochen werden.


Layer-0

Rncomformatip.png

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.

Layer-1

Rncomlay1pc.png
  • Targ (target) ist die 16-Bit Zieladdresse (network order)
  • Srce (source) ist die 16-Bit Absenderaddresse (network order)
  • Daten ist der eigentlich Nachrichten-Inhalt

Target und Source sind systemweit eindeutige IDs. Also zum Beispiel ein ganz bestimmter AD-Converter auf einem Kontroller im Netzwerk. Oder die Steuerung für einen bestimmten Schrittmotor o.Ä.

Wenn auf eine Message eine Antwort erfolgt, tauschen Target und Source die Plätze

Reservierte ID

  • 0000 Broadcast. diese Message wird an alle Teilnehmer verteilt.
  • 0001 - 00FF diese Ziele sind für Funktionen des RN-SERVER reserviert.

Diese werden wohl im Zuge des Projekts immer mehr erweitert werden.

Layer-2 (Daten)

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.

  • &H01

Das folgende Datenbereich beinhaltet KEY=VALUE Angaben, wie bei "logon" beschrieben

  • &H02 - &HFD

dzt. fur 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.

Protokoll

Logon

Der Client setzt einen "connect request" an IpAddr/PortNr ab. Danach sendet er eine "Logon" Nachricht im Format Layer-0, der Datenteil beinhaltet die Identifikation des Client.

ID=nnnnn,NAME=name,DESCRIPT=aaaaaaaa

alternativ, wenn ID-Klasse und. Identifier gesondert angegeben werden sollen

IDC=nnn,IDI=nnn,NAME=name,DESCRIPT=aaaaaaaa

Messages

  • Nach dem Logon gilt das Layer-1 Format (Target, Source, Daten).
  • Der Client muß jederzeit (asynchron) Messages empfangen können.
  • Das Verhältnis Message/Response ist unbestimmt



Autor

Siehe auch


LiFePO4 Speicher Test