Talbus: Unterschied zwischen den Versionen

Aus /dev/tal
Wechseln zu: Navigation, Suche
(Neues Protokoll)
Zeile 32: Zeile 32:
 
=== CAN-Schicht ===
 
=== CAN-Schicht ===
 
Wir benutzen CAN nach dem Standard 2.0B. Dank des in CAN enthaltenen CSMA/CR können Kollisionen auf dem Bus erfolgreich beseitigt werden.
 
Wir benutzen CAN nach dem Standard 2.0B. Dank des in CAN enthaltenen CSMA/CR können Kollisionen auf dem Bus erfolgreich beseitigt werden.
−
Da wir die beiden Bits EID17 und EID16 zu Steuerzwecken verwenden, ist es nötig, dass wir die Variante mit 29-Bit Identifier verwenden können, wenn besondere Nachrichten zur Steuerung an Nodes verteilt werden sollen. Zu der genauen Belegung dieser Steuerbefehle siehe auch den Abschnitt [[#Special-Control (SC)|Special-Control]].
+
Da wir die beiden Bits EID17 und EID16 für unser Protokoll verwenden, ist es nötig, dass wir die Variante mit 29-Bit Identifier verwenden können, wenn bestimmte Nachrichtentypen unterstützt werden sollen. Wird nur die 11-Bit Variante genutzt, sind eventuell nicht alle Features unseres Protokolls verwendbar. Generell können Nodes aber auch mit 11-Bit-Identifiern angesprochen werden.
−
Diese Befehle müssen nicht zwanghaft in allen Nodes implementiert werden. Daher können Nodes auch mit 11-Bit-Identifiern angesprochen werden.
+
 
Es muss aber sichergestellt sein, dass es keine Probleme mit den beiden unterschiedlichen Identifier-Längen im Bus gibt. Im Zweifelsfall ist es am besten, 29-Bit-Identifier zu unterstützen. Zusätzlich sollte es auch bei Frames mit kurzem Identifier zu keinen Fehlern im Bus kommen.
 
Es muss aber sichergestellt sein, dass es keine Probleme mit den beiden unterschiedlichen Identifier-Längen im Bus gibt. Im Zweifelsfall ist es am besten, 29-Bit-Identifier zu unterstützen. Zusätzlich sollte es auch bei Frames mit kurzem Identifier zu keinen Fehlern im Bus kommen.
  
−
Die gewählte Geschwindigkeit von 100kbit/s erlaubt es uns, das Netzwerk auf besonders lange Strecken auszuweiten und ist für unsere Zwecke vollkommen ausreichend.
+
Die gewählte Geschwindigkeit von 128kbit/s erlaubt es uns, das Netzwerk auf besonders lange Strecken auszuweiten und ist für unsere Zwecke vollkommen ausreichend.
  
 
Als CAN-Controller wird für den Anfang der MCP2515 verwendet. Der Vorteil davon ist, dass er relativ günstig ist und mit Spannungen von sowohl 5V als auch 3,3V läuft.
 
Als CAN-Controller wird für den Anfang der MCP2515 verwendet. Der Vorteil davon ist, dass er relativ günstig ist und mit Spannungen von sowohl 5V als auch 3,3V läuft.
Zeile 64: Zeile 63:
 
|||10||9||8||7||6||5||4||3||2||1||0||17||16||15||14||13||12||11||10||9||8||7||6||5||4||3||2||1||0
 
|||10||9||8||7||6||5||4||3||2||1||0||17||16||15||14||13||12||11||10||9||8||7||6||5||4||3||2||1||0
 
|-
 
|-
−
! talbus-Identifier || colspan="3" | VID || colspan="6" | MID || colspan="2" | DID || colspan="2" | SC || colspan="8" | Data-0 || colspan="8" | Data-1
+
! talbus-Identifier || colspan="8" | Address || colspan="3" | Protocol || Direction || - || colspan="8" | Data-0 || colspan="8" | Data-1
 
|}
 
|}
  
 
==== CAN-SID ====
 
==== CAN-SID ====
  
−
Der Standard-Identifier, welcher 11 Bit lang ist und in beiden Varianten des CAN-Protokolls vorhanden ist teilt sich in verschiedene Werte auf, die zusammen eine eindeutige Adressierung der enthaltenen Nachricht und des Nachrichtentyps eines Geräts bieten.
+
Der Standard-Identifier, welcher 11 Bit lang ist und in beiden Varianten des CAN-Protokolls vorhanden ist teilt sich in verschiedene Werte auf, die zusammen eine eindeutige Adressierung des Geräts und des Protokolls bieten.
−
Es werden nicht unbedingt Anwendungen adressiert, wie es im normalen TCP/IP-Modell üblich ist, sondern es werden einzelne Nachrichtentypen adressiert.
+
Zusätzlich kann auch eine Richtung gesetzt werden. Mehr dazu siehe [[#Direction|unten]].
  
−
Bei der Adressierung sollte noch darauf geachtet werden, dass die Priorität der niedrigeren Identifier höher ist, als die der höheren IDs. Das liegt an der Kollisionslösung des CAN-Protokolls. Aus diesem Grund sollte für wichtige Nachrichten noch Platz unter den niedrigeren Adressen gelassen werden. Dies betrifft insbesondere VID und MID (s.u.).
+
Bei der Adressierung sollte noch darauf geachtet werden, dass die Priorität der niedrigeren Identifier höher ist, als die der höheren IDs. Das liegt an der Kollisionslösung des CAN-Protokolls. Aus diesem Grund sollten die wichtigeren Geräte und Protokolle möglichst geringe IDs haben.
  
−
===== VID (Version-ID) =====
+
===== Address =====
−
Als erstes ist im Standard-Identifier die 3-bit lange Version-ID zu finden.
+
Als erstes ist im Standard-Identifier die 8-bit lange Adresse zu finden, welche jedes Gerät identifiziert. Diese sollten in entsprechende Netze gruppiert werden. In der folgenden Tabelle sind Adressräume zu finden.
−
Diese kann zur Aufteilung des Netzes in logische Bereiche oder zur Unterscheidung verschiedener Versionen des Bussystems verwendet werden.
+
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! VID !! Binär !! Beschreibung !! Version
+
! Adressbereich !! Beschreibung / Protokolle
 
|-
 
|-
−
| 0x1 || 001 || Main Controller ||
+
| 0x00/8 || Reserved
 
|-
 
|-
−
| 0x4 || 100 || /dev/tal || 1.0
+
| 0x00/4 || Management / Gateway Devices (PiCAN)
 
|-
 
|-
−
| 0x5 || 101 || FabLab || 1.0
+
| 0x20/4 || /dev/tal Raum-Automatisierung 1.0
 +
|-
 +
| 0xF0/4 || Multicast
 +
|-
 +
| 0xFF/8 || Broadcast
 
|-
 
|-
 
|}
 
|}
  
−
===== MID (Message-ID) =====
+
Es folgt eine Liste aller vergebenen Geräte. Zusätzlich kann auch in der [[:Kategorie:talNode|Liste der talNode-Seiten]] nach Geräten gesucht werden.
−
Dann folgt die Message-ID. Dieser 5-bit lange Identifier bestimmt in Abhängigkeit mit der VID den genauen Inhalt der gesendeten Nachricht. Daher kann die Message-ID für verschiedene VIDs verschiedene Belegungen haben. Die folgende Tabelle sollte Aufschluss über die Belegungen geben:
+
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! rowspan="2" | MID !! rowspan="2" | binär !! colspan="2" | VID
+
! Adresse !! Beschreibung
 
|-
 
|-
−
! 0x4 !! 0x5
+
| 0x00 || Reserved
 
|-
 
|-
−
| 0x21 || 100001 || colspan="2" | Status
+
| 0x01 || [[Space-Bot]] (RPi)
 
|-
 
|-
−
| 0x22 || 100010 || colspan="2" | Licht
+
| 0x20 || [[TuerNode]]
 
|-
 
|-
−
| 0x24 || 100100 || Message ||
+
| 0xFF || Broadcast
 
|-
 
|-
 
|}
 
|}
  
−
===== DID (Device-ID) =====
+
===== Protocol =====
−
Mit der abschließenden 2 Bit langen Device-ID kann sichergestellt werden, dass bis zu vier Nodes (gleichzeitig; in der Regel aber auch sonst) Nachrichten der selben ID verschicken kann. Beim Empfang der Nachrichten kann die Device-ID im Normalfall ignoriert werden, Beim Senden sollte sie jedoch zusammen mit dem restlichen SID zu einem Node passen. Soll eine Nachricht über das Webinterface gesteuert werden, ist es sinnvoll, den Device-Identifier 0 dafür freizuhalten, da auch dies im Endeffekt nur ein Node ist. Sollten die verbleibenden Device-IDs nicht ausreichen, so kann darüber nachgedacht werden, die Länge der Message-ID entsprechend zu variieren. Dies sollte aber im normalfall nicht vorkommen und sonst müsste man sich überlegen, wie man dieses Problem effektiv lösen könnte.
+
Dann folgt das entsprechende Protokoll. Dieser 3-bit lange Identifier bestimmt das Protokoll über den Inhalt der gesendeten Nachricht. Falls die Länge dieser ID nicht ausreicht, kann das Protokoll auch zusätzlich vom Adressfeld (bestimmte Adressbereiche für bestimmte Protokolle) festgelegt werden. Dies muss dann aber in den entsprechenden Protokollen definiert werden. Daher kann die Protokoll-ID für verschiedene Adressen verschiedene Belegungen haben.
  
−
Eine genaue Verteilung der DIDs und auch der gesamten SIDs ist in der auf der Seite des jeweiligen talNode zu finden.
+
{| class="wikitable"
−
 
+
! Protocol-ID !! Beschreibung
−
===== Filterung im Controller =====
+
|-
−
 
+
| 0x0 || Management (Ping/Flash/...)
−
Aufgrund der beschriebenen Aufteilung kann ein Node auf mehrere IDs reagieren. Dies ist dank einer Maskier- und Filterfunktion im CAN-Controller auch mit ein wenig Planung machbar. Der MCP2551 hat zwei Empfangspuffer mit unterschiedlichen Filtern. Wenn der Node auf mehr als zwei unterschiedliche Nachrichtentypen reagieren soll, müssen die MIDs aber auch entsprechend eingerichtet werden, sodass ein gezieltes Maskieren und Filtern möglich wird. Daher ist es immer sinnvoll, die MIDs davon abhängig zu machen, wie es implementiert werden soll. Beispielsweise kann ein Node, der nur Spacestatus und Licht-Nachrichten empfangen soll, seine Maske auf 0x7F0 setzen und den Filter auf 0x680. Damit werden die zwei niederwerigsten Bits des VID sowie der DID beim Filtern ignoriert.
+
|-
 +
| 0x1 || Raum-Automatisierung (Strom/Licht/Regeln/Sensoren/Zeit/Message)
 +
|-
 +
| 0x2 || Multimedia-Automatisierung (Beamersteuerung/Soundanlage)
 +
|-
 +
| 0x3 || Bus Messages / Log / Error / Info
 +
|-
 +
| 0x7 || Reserved
 +
|-
 +
|}
  
 
==== CAN-EID ====
 
==== CAN-EID ====
  
−
Der EID kann für bestimmte Steuernachrichten verwendet werden. Des weiteren bietet er Platz für zwei zusätzliche Datenbytes im CAN-Frame.
+
Der wichtigste Vorteil von dem EID ist, dass er neben 16 Bits (für zwei weitere Datenbytes im CAN-Frame) noch zwei weitere Bits zur Verfeinerung des talbus-Protokolls beinhaltet. Mit dem ersten dieser beiden Bits kann die Datenrichtung festgelegt werden. Das zweite Bit ist noch reserviert und kann eventuell ein Indikator für zukünftige talbus-Versionen sein.
  
 
{| class="wikitable"
 
{| class="wikitable"
Zeile 123: Zeile 133:
 
! 17 !! 16 !! 15 !! 14 !! 13 !! 12 !! 11 !! 10 !! 9 !! 8 !! 7 !! 6 !! 5 !! 4 !! 3 !! 2 !! 1 !! 0
 
! 17 !! 16 !! 15 !! 14 !! 13 !! 12 !! 11 !! 10 !! 9 !! 8 !! 7 !! 6 !! 5 !! 4 !! 3 !! 2 !! 1 !! 0
 
|-
 
|-
−
| colspan="2" | SC || colspan="8" | Data-0 || colspan="8" | Data-1
+
| colspan="2" | || colspan="8" | Data-0 || colspan="8" | Data-1
 
|-
 
|-
−
| SC1 || SC2 || DB7 || DB6 || DB5 || DB4 || DB3 || DB2 || DB1 || DB0 || DB7 || DB6 || DB5 || DB4 || DB3 || DB2 || DB1 || DB0
+
| DIR || - || DB7 || DB6 || DB5 || DB4 || DB3 || DB2 || DB1 || DB0 || DB7 || DB6 || DB5 || DB4 || DB3 || DB2 || DB1 || DB0
 
|}
 
|}
  
−
===== Special-Control (SC) =====
+
===== Direction =====
−
Mit diesem Datenfeld lassen sich besondere Steuernachrichten übermitteln. Damit ist es zum Beispiel möglich, bestimmte Nodes neuzustarten.
+
Dieses Bit ist dafür zuständig, ob eine Nachricht gerade von der gegebenen Adresse kommt, oder an die angegebene Adresse gesendet werden soll. Aufgrund der Struktur von CAN reicht es allerdings prinzipiell aus, dass Nodes bereits auf Ihre eigene Adresse reagieren. Sollen aber bestimmte Nachrichten als Broadcast versendet werden, so kann dieses Bit eine "1" enthalten. Das bedeutet dann dass die Nachricht an alle Nodes gerichtet ist, die Nachrichten ''von'' der angegebenen Adresse erwarten.
 
{| class="wikitable"
 
{| class="wikitable"
−
! SC !! Bedeutung
+
! Direction-Bit !! Bedeutung
 
|-
 
|-
−
| 0b00 || Normale Nachricht
+
| 0 || Dieses Paket ist '''an''' die im SID gegebene Adresse gerichtet.
 
|-
 
|-
−
| 0b01 ||
+
| 1 || Dieses Paket kommt '''von''' der im SID gegebenen Adresse.
−
|-
+
−
| 0b10 || Node neustarten
+
−
|-
+
−
| 0b11 ||  
+
 
|}
 
|}
−
Die Adressierung kann je nach SC unterschiedlich sein. Für normale Nachrichten wird der Identifier wie oben beschrieben genutzt. Soll eine Node neugestartet werden oder wird sie gerade geflasht, so enthalten die höchsten 10 Bit des Standard Identifiers eine eindeutige ID der Node (Node-ID). Dadurch wird es möglich, garantiert einen speziellen Node zu adressieren. Die restlichen Adressbits können dann ignoriert werden.
+
 
−
Im Idealfall könnte es für bestimmte Nachrichten auch Broadcast-Adressen geben, dies muss jedoch erst implementiert werden.
+
===== Reserved =====
−
Die Zuweisung der Node-IDs ist weiter unten zu finden.
+
Dieses Bit ist bisher noch reserviert und muss daher eine "0" enthalten.
  
 
===== Datenfelder =====
 
===== Datenfelder =====
 
Das Datenfeld fängt nach dem CAN-Standard üblicherweise erst nach dem Identifier und der Längenangabe des Datenfeldes an.
 
Das Datenfeld fängt nach dem CAN-Standard üblicherweise erst nach dem Identifier und der Längenangabe des Datenfeldes an.
−
Da wir aber aufgrund der Special-Control-Bits schon auf den Extended-Identifier angewiesen sind, und diese die Maximallänge eines CAN-Frames um einige Bits erhöhen, kann man die verbleibenden 16 Bits des EID auch dazu nutzen, um das Frame um weitere Datenbytes zu erweitern.
+
Da wir aber aufgrund der weiteren Kontrollbits schon den Extended-Identifier verwenden, und dieser die Maximallänge eines CAN-Frames um einige Bits erhöhen, kann man die verbleibenden 16 Bits des EID auch dazu nutzen, um das Frame um weitere Datenbytes zu erweitern.
  
−
Die Mindestlänge eines Frames ist somit auf 2 Bytes festgelegt, weil die Längenangabe des CAN-Frames hierbei keine Beachtung trägt. Die Längenangabe ist also nur für alle Datenbytes nach den ersten beiden Bytes zuständig. Insgesamt kann somit ein Frame zwischen 2 und 10 Bytes Nutzdaten enthalten.
+
Die Mindestlänge eines Frames ist somit auf 2 Bytes festgelegt, weil die Längenangabe des CAN-Frames hierbei keine Beachtung trägt. Die Längenangabe ist also nur für alle Datenbytes nach den ersten beiden Bytes zuständig. Insgesamt kann somit ein Frame mit  zwischen 2 und 10 Bytes Nutzdaten enthalten.
 
Braucht ein Protokoll der nächsthöheren Schicht weniger als zwei Bytes, so muss dies dafür sorgen, dass die Länge der Daten entsprechend richtig ist. Dies kann beispielsweise durch ein zusätzliches Längenfeld innerhalb der Datenbytes implementiert werden. Übertragen werden dann aber dennoch mindestens 2 Bytes Daten.
 
Braucht ein Protokoll der nächsthöheren Schicht weniger als zwei Bytes, so muss dies dafür sorgen, dass die Länge der Daten entsprechend richtig ist. Dies kann beispielsweise durch ein zusätzliches Längenfeld innerhalb der Datenbytes implementiert werden. Übertragen werden dann aber dennoch mindestens 2 Bytes Daten.
  
 
=== Anwendungsschicht ===
 
=== Anwendungsschicht ===
−
Hier werden Protokolle implementiert, die den Bus dazu nutzen, um Daten auszutauschen.
+
Hier werden die Protokolle implementiert, die den Bus dazu nutzen, um Daten auszutauschen.
  
 
Bisher wurde leider noch kein Protokoll entwickelt. In näherer Zukunft sollten aber Protokolle zu Space-Status, Lichtsteuerung und Nachrichten bzw. Zeit entwickelt werden.
 
Bisher wurde leider noch kein Protokoll entwickelt. In näherer Zukunft sollten aber Protokolle zu Space-Status, Lichtsteuerung und Nachrichten bzw. Zeit entwickelt werden.
−
 
−
== Liste aller Nodes ==
 
−
Siehe auch [[:Kategorie:talNode|Liste der talNode-Seiten]]
 
−
 
−
{| class="wikitable"
 
−
! Node-ID !! Node
 
−
|-
 
−
| 0x00 || [[Space-Bot]]
 
−
|-
 
−
| 0x20 || [[TuerNode]]
 
−
|}
 
  
 
== Referenzen ==
 
== Referenzen ==
 
<references />
 
<references />

Version vom 10. Mai 2014, 00:27 Uhr

Schichtenmodell

# talbus-Schicht ISO/OSI-Äquivalent
4 Anwendungsschicht Anwendungsschicht - Transportschicht
3 talbus-Schicht Netzwerkschicht
2 CAN-Schicht Sicherungsschicht
1 Hardwareschicht Bitübertragungsschicht

Hardwareschicht

Diese Schicht besteht aus den Kupferleitungen zwischen den Nodes. Dank des entsprechenden Modus in der CAN-Schicht ist es möglich, dass der Bus theoretisch eine Kabellänge von 500m oder sogar mehr erreichen kann. Dabei sollte darauf geachtet werden, dass für längere Strecken Twisted-Pair-Kabel verwendet werden, da CAN mit Differenzsignalen arbeitet, die sich in Twisted-Pair-Verkabelung am besten ausbreiten können.

Belegung des Flachbandkabels

Dennoch ist es wesentlich einfacher und intuitiver, auf Flachbandkabel und Wannenstecker zu setzen. Das hat unter anderem den Vorteil, dass an beliebiger Stelle im Bus einfach ein neuer Node eingefügt werden kann, indem an dieser Stelle im Flachbandkabel eine Pfostenstecker-Buchse eingezahnt wird. Diese Belegung hat sich schon in bestehenden CAN-Netzen[1] bewährt und sollte daher auf kürzeren Strecken, wie zum Beispiel innerhalb des /dev/tals verwendet werden, um die maximale Kompatibilität zu gewähren.

Um alle möglichen Verbindungsmöglichkeiten offenzuhalten, wurden auf der talnode-Platine verschiedene Möglichkeiten für Verbindungen zum CAN-Bus entworfen, die sich allerdings aus Platzgründen teils überschneiden. Beispielsweise ist es möglich, Schraubklemmen auf dem Node zu montieren. In dem Fall ist es wiederum nicht möglich zusätzlich noch einen Wannenstecker zu verlöten. Generell ist es möglich, Wannenstecker (Belegung siehe oben), schraubbare Anschlussklemmen im Rastermaß 5mm (bevorzugt für feststehende Verbindungen zwischen Hauptnodes) vierpolige Buchsenleisten, Stiftleisten bzw. Leiterplattenverbinder (wie bei PC-Lüftern verwendet) im Rastermaß 2,5mm aufzulöten. Die genaue Pinbelegung ist im zweifelsfall dem Schaltplan der talnodes zu entnehmen.

Bei der talpican-Platine ist es derzeit nicht möglich, einen Wannenstecker aufzulöten. Außerdem beträgt das Rastermaß für die Schraubklemmen dabei im Gegensatz zu den talnodes 3,5mm.

Weitere Informationen zu der verwendeten Hardware gibt es auf den Seiten zu den Platinen talnode und talpican.

CAN-Schicht

Wir benutzen CAN nach dem Standard 2.0B. Dank des in CAN enthaltenen CSMA/CR können Kollisionen auf dem Bus erfolgreich beseitigt werden. Da wir die beiden Bits EID17 und EID16 für unser Protokoll verwenden, ist es nötig, dass wir die Variante mit 29-Bit Identifier verwenden können, wenn bestimmte Nachrichtentypen unterstützt werden sollen. Wird nur die 11-Bit Variante genutzt, sind eventuell nicht alle Features unseres Protokolls verwendbar. Generell können Nodes aber auch mit 11-Bit-Identifiern angesprochen werden. Es muss aber sichergestellt sein, dass es keine Probleme mit den beiden unterschiedlichen Identifier-Längen im Bus gibt. Im Zweifelsfall ist es am besten, 29-Bit-Identifier zu unterstützen. Zusätzlich sollte es auch bei Frames mit kurzem Identifier zu keinen Fehlern im Bus kommen.

Die gewählte Geschwindigkeit von 128kbit/s erlaubt es uns, das Netzwerk auf besonders lange Strecken auszuweiten und ist für unsere Zwecke vollkommen ausreichend.

Als CAN-Controller wird für den Anfang der MCP2515 verwendet. Der Vorteil davon ist, dass er relativ günstig ist und mit Spannungen von sowohl 5V als auch 3,3V läuft. Falls andere Controller verwendet werden sollen, vor dauerhafter Einbindung in das Netzwerk bitte ausreichend testen, damit das System auch weiterhin funktioniert. Über eine Erweiterung dieses Abschnittes bei neuen Kenntnissen, was andere Controller oder sonstige CAN-Hardware angeht, wäre man überdies auch sehr dankbar.

Für den Transceiver wird bei Geräten mit 5V-Pegelspannung (AVR) der MCP2551 verwendet. Bei 3,3V-Pegeln (ARM) kann auf den SN65HVD230D ausgewichen werden. Transceiver benötigen für die Wahl der Flankensteilheit einen Widerstand, hier haben wir zunächst auf 33kΩ gesetzt.

Die Chips MCP2515, MCP2551 und SN65HVD230D sollten in ausreichender Stückzahl in den Elektro-Sortierkästen zu finden sein. Falls nicht, einfach Endres fragen. Falls nicht gerade die üblichen talnodes oder picans verwendet werden, kann dennoch auf deren Schaltpläne verwiesen werden, um eine Beispielschaltung vor sich zu haben. Auch der Sourcecode darf natürlich auf die eigenen Bedürfnisse angepasst werden. Zu finden ist beides auf den entsprechenden Seiten.

talbus-Schicht

Talbus-Daten-Frame mit elektrischen Pegeln ohne Stuffbits

Das talbus-Protokoll wird auf das übliche CAN-Protokoll aufgesetzt. Dabei wird besonders das Format des Nachrichten-Identifiers vereinheitlicht, sodass eine einfache Kommunikation über das Bussystem möglich wird.

Dank CAN kann jeder Node jedem anderen Node Nachrichten schicken, was in anderen Systemen nicht so leicht umsetzbar wäre. Das hat den Vorteil, dass wenn ein Node (zum Beispiel das Hauptgateway) ausfällt, nicht gleich der ganze Bus ausfällt, sondern als autonomes System weiterarbeiten kann. Natürlich muss dann auf die Funktionalität des Nodes, welches ausgefallen ist, verzichtet werden, aber für eine rudimentäre Funktion sollte das Bussystem weiterhin herhalten können. Genau diese Eigenschaft sollte überall dort wo dies auch sinnvoll möglich ist, eingesetzt werden. Als abstraktes Beispiel sollte also der Lichtschalter immer der Lampe Nachrichten senden können, die den aktuellen Schaltzustand enthalten um die Lampe entsprechend zu steuern. Daher verwenden wir ein einheitliches Format der Nachrichten-Identifier, damit gewährleistet wird, dass jeder Node mit bestimmten Nachrichten erreicht werden kann.

Aufteilung der Identifier:

CAN-Identifier SID EID
10 9 8 7 6 5 4 3 2 1 0 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
talbus-Identifier Address Protocol Direction - Data-0 Data-1

CAN-SID

Der Standard-Identifier, welcher 11 Bit lang ist und in beiden Varianten des CAN-Protokolls vorhanden ist teilt sich in verschiedene Werte auf, die zusammen eine eindeutige Adressierung des Geräts und des Protokolls bieten. Zusätzlich kann auch eine Richtung gesetzt werden. Mehr dazu siehe unten.

Bei der Adressierung sollte noch darauf geachtet werden, dass die Priorität der niedrigeren Identifier höher ist, als die der höheren IDs. Das liegt an der Kollisionslösung des CAN-Protokolls. Aus diesem Grund sollten die wichtigeren Geräte und Protokolle möglichst geringe IDs haben.

Address

Als erstes ist im Standard-Identifier die 8-bit lange Adresse zu finden, welche jedes Gerät identifiziert. Diese sollten in entsprechende Netze gruppiert werden. In der folgenden Tabelle sind Adressräume zu finden.

Adressbereich Beschreibung / Protokolle
0x00/8 Reserved
0x00/4 Management / Gateway Devices (PiCAN)
0x20/4 /dev/tal Raum-Automatisierung 1.0
0xF0/4 Multicast
0xFF/8 Broadcast

Es folgt eine Liste aller vergebenen Geräte. Zusätzlich kann auch in der Liste der talNode-Seiten nach Geräten gesucht werden.

Adresse Beschreibung
0x00 Reserved
0x01 Space-Bot (RPi)
0x20 TuerNode
0xFF Broadcast
Protocol

Dann folgt das entsprechende Protokoll. Dieser 3-bit lange Identifier bestimmt das Protokoll über den Inhalt der gesendeten Nachricht. Falls die Länge dieser ID nicht ausreicht, kann das Protokoll auch zusätzlich vom Adressfeld (bestimmte Adressbereiche für bestimmte Protokolle) festgelegt werden. Dies muss dann aber in den entsprechenden Protokollen definiert werden. Daher kann die Protokoll-ID für verschiedene Adressen verschiedene Belegungen haben.

Protocol-ID Beschreibung
0x0 Management (Ping/Flash/...)
0x1 Raum-Automatisierung (Strom/Licht/Regeln/Sensoren/Zeit/Message)
0x2 Multimedia-Automatisierung (Beamersteuerung/Soundanlage)
0x3 Bus Messages / Log / Error / Info
0x7 Reserved

CAN-EID

Der wichtigste Vorteil von dem EID ist, dass er neben 16 Bits (für zwei weitere Datenbytes im CAN-Frame) noch zwei weitere Bits zur Verfeinerung des talbus-Protokolls beinhaltet. Mit dem ersten dieser beiden Bits kann die Datenrichtung festgelegt werden. Das zweite Bit ist noch reserviert und kann eventuell ein Indikator für zukünftige talbus-Versionen sein.

EID
17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Data-0 Data-1
DIR - DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0 DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
Direction

Dieses Bit ist dafür zuständig, ob eine Nachricht gerade von der gegebenen Adresse kommt, oder an die angegebene Adresse gesendet werden soll. Aufgrund der Struktur von CAN reicht es allerdings prinzipiell aus, dass Nodes bereits auf Ihre eigene Adresse reagieren. Sollen aber bestimmte Nachrichten als Broadcast versendet werden, so kann dieses Bit eine "1" enthalten. Das bedeutet dann dass die Nachricht an alle Nodes gerichtet ist, die Nachrichten von der angegebenen Adresse erwarten.

Direction-Bit Bedeutung
0 Dieses Paket ist an die im SID gegebene Adresse gerichtet.
1 Dieses Paket kommt von der im SID gegebenen Adresse.
Reserved

Dieses Bit ist bisher noch reserviert und muss daher eine "0" enthalten.

Datenfelder

Das Datenfeld fängt nach dem CAN-Standard üblicherweise erst nach dem Identifier und der Längenangabe des Datenfeldes an. Da wir aber aufgrund der weiteren Kontrollbits schon den Extended-Identifier verwenden, und dieser die Maximallänge eines CAN-Frames um einige Bits erhöhen, kann man die verbleibenden 16 Bits des EID auch dazu nutzen, um das Frame um weitere Datenbytes zu erweitern.

Die Mindestlänge eines Frames ist somit auf 2 Bytes festgelegt, weil die Längenangabe des CAN-Frames hierbei keine Beachtung trägt. Die Längenangabe ist also nur für alle Datenbytes nach den ersten beiden Bytes zuständig. Insgesamt kann somit ein Frame mit zwischen 2 und 10 Bytes Nutzdaten enthalten. Braucht ein Protokoll der nächsthöheren Schicht weniger als zwei Bytes, so muss dies dafür sorgen, dass die Länge der Daten entsprechend richtig ist. Dies kann beispielsweise durch ein zusätzliches Längenfeld innerhalb der Datenbytes implementiert werden. Übertragen werden dann aber dennoch mindestens 2 Bytes Daten.

Anwendungsschicht

Hier werden die Protokolle implementiert, die den Bus dazu nutzen, um Daten auszutauschen.

Bisher wurde leider noch kein Protokoll entwickelt. In näherer Zukunft sollten aber Protokolle zu Space-Status, Lichtsteuerung und Nachrichten bzw. Zeit entwickelt werden.

Referenzen

  1. ↑ Pinbelegung des CAN-Bus im Labor in Bochum
Von „https://devtal.de/w/index.php?title=Talbus&oldid=2462“