Talbus
Achtung! Diese Seite ist nicht mehr aktuell und wird im Laufe der Entwicklung des Projektes weiter überarbeitet werden. Informationen können teils nicht relevant und falsch sein. Dies liegt daran, dass an dem Projekt für eine sehr lange Zeit nicht weitergearbeitet wurde. |
Der Talbus ist das Herzstück der sich entwickelnden Automatisierung des /dev/tals. Er basiert auf dem CAN-Bussystem welches von Bosch entwickelt wurde und somit weite Verbreitung findet und zunehmend bereits in Mikroprozessor-Systemen integriert ist. Das Bussystem arbeitet differenziell, was lange Übertragungsstrecken erlaubt. Außerdem kann jedes Teilnehmende Gerät einfach mit den Datenleitungen verbunden werden, um mit dem Bus interagieren zu können. Somit ist dieser aus Anwendungssicht ein relativ einfacher Bus zur Kommunikation zwischen mehreren eigenständigen Systemen. Wir erweitern den CAN-Bus mit unserem eigenen Talbus-Protokoll, weshalb diese Seite hauptsächlich unser Schichtenmodell des Talbus erläutert.
Inhaltsverzeichnis
Schichtenmodell
Wie bei Netzwerken üblich, ist unser Talbus auch in verschiedene Schichten eingeteilt, welche zusammen mit den jeweiligen ISO/OSI-Äquivalenten der folgenden Tabelle entnommen werden können.
| # | talbus-Schicht | ISO/OSI-Äquivalent |
|---|---|---|
| 4 | Anwendungsschicht | Anwendungsschicht - Transportschicht |
| 3 | talbus-Schicht | Netzwerkschicht |
| 2 | CAN-Schicht | Sicherungsschicht |
| 1 | Hardwareschicht | Bitübertragungsschicht |
Es folgt eine erläuternde Differenzierung der einzelnen Schichten und ihrer Eigenschaften:
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.
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
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 | Reserved | 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 | Caninchen (RPi) |
| 0x21 | 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.
