Aus RN-Wissen.de
Version vom 29. Oktober 2006, 15:15 Uhr von PicNick (Diskussion | Beiträge)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche
Laderegler Test Tueftler Seite

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

Layer-0

Für die unterste Schicht, Layer-0, gibt es drei Versionen:

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.

Da wir für unser Projekt keine Messages verwenden wollen, die länger als 255 Byte sind, genügt es in der Praxis, erstmal nur ein Byte als Länge zu lesen, und den nächsten receive - request dann mit diesem Wert + 1 als LÄnge zu verwenden.


Layer-1 Version 0.1

Rncomlay1pc.png

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.Ä.


HBT Heartbeat

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

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


LiFePO4 Speicher Test