Talbus - Versionsgeschichte

Endres am 28. Januar 2017 um 19:24 Uhr

2017-01-28T19:24:28Z

Endres: /* Address */

2014-09-05T17:24:56Z

‎Address

Endres: Einleitung sowie kleine Ergänzungen

2014-09-04T17:39:15Z

Einleitung sowie kleine Ergänzungen

Endres: /* Address */

2014-05-10T00:13:53Z

‎Address

Endres: Neues Protokoll

2014-05-09T23:27:08Z

Neues Protokoll

Änderungen zeigen

Endres am 15. März 2014 um 09:36 Uhr

2014-03-15T09:36:48Z

Endres: nur Kategorielink

2014-03-07T19:19:10Z

nur Kategorielink

Endres: Die Seite wurde neu angelegt: „== Schichtenmodell == {| class="wikitable" ! # !! talbus-Schicht !! ISO/OSI-Äquivalent |- | 4 || Anwendungsschicht || Anwendungsschicht - Transportschicht |-…“

2014-03-07T19:16:52Z

Die Seite wurde neu angelegt: „== Schichtenmodell == {| class="wikitable" ! # !! talbus-Schicht !! ISO/OSI-Äquivalent |- | 4 || Anwendungsschicht || Anwendungsschicht - Transportschicht |-…“

Neue Seite

== Schichtenmodell ==

{| class="wikitable"
! # !! 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.
[[Datei:talbus-wannenstecker.png|thumb|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<ref>[http://www.das-labor.org/wiki/CAN#Pinbelegung_neuer_Canbus_Stecker Pinbelegung des CAN-Bus im Labor in Bochum]</ref> 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 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]].
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.

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.

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 [[talnode|talnodes]] oder [[talpican|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 ===

[[Datei:Talbus-Frame.svg|frame|center|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:

{| class="wikitable"
! CAN-Identifier || colspan="11" | SID || colspan="18" | 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 || colspan="3" | VID || colspan="6" | MID || colspan="2" | DID || colspan="2" | SC || colspan="8" | Data-0 || colspan="8" | 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 der enthaltenen Nachricht und des Nachrichtentyps eines Geräts bieten.
Es werden nicht unbedingt Anwendungen adressiert, wie es im normalen TCP/IP-Modell üblich ist, sondern es werden einzelne Nachrichtentypen adressiert.

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

===== VID (Version-ID) =====
Als erstes ist im Standard-Identifier die 3-bit lange Version-ID zu finden.
Diese kann zur Aufteilung des Netzes in logische Bereiche oder zur Unterscheidung verschiedener Versionen des Bussystems verwendet werden.

{| class="wikitable"
! VID !! Binär !! Beschreibung !! Version
|-
| 0x1 || 001 || Main Controller ||
|-
| 0x4 || 100 || /dev/tal || 1.0
|-
| 0x5 || 101 || FabLab || 1.0
|-
|}

===== MID (Message-ID) =====
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"
! rowspan="2" | MID !! rowspan="2" | binär !! colspan="2" | VID
|-
! 0x4 !! 0x5
|-
| 0x21 || 100001 || colspan="2" | Status
|-
| 0x22 || 100010 || colspan="2" | Licht
|-
| 0x24 || 100100 || Message ||
|-
|}

===== DID (Device-ID) =====
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.

Eine genaue Verteilung der DIDs und auch der gesamten SIDs ist in der [[Kategorie:talNode|Liste der talNodes]] zu finden.

===== Filterung im Controller =====

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.

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

{| class="wikitable"
! colspan="18" | EID
|-
! 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
|-
| SC1 || SC2 || DB7 || DB6 || DB5 || DB4 || DB3 || DB2 || DB1 || DB0 || DB7 || DB6 || DB5 || DB4 || DB3 || DB2 || DB1 || DB0
|}

===== Special-Control (SC) =====
Mit diesem Datenfeld lassen sich besondere Steuernachrichten übermitteln. Damit ist es zum Beispiel möglich, bestimmte Nodes neuzustarten.
00 Normale Nachricht
01
10 Node neustarten
11
Um bestimmte Nodes damit zu Adressieren, muss einfach eine Nachricht mit einem Identifier gesendet werden, auf den dieser Node reagiert.
Im idealfall könnte es auch Broadcast-Adressen geben, dies muss jedoch erst implementiert werden.
In der Spezialnachricht muss als nulltes Datenbyte (EID15:8, siehe unten) ein eindeutiger Identifier (Node-ID) des bestimmten Nodes liegen. Dadurch wird es möglich, garantiert einen speziellen Node zu adressieren.
Die Zuweisung der NIDs sollte dann im Wiki vorgehalten werden, und wenigstens auf der Seite der jeweiligen Nodes zu finden sein.
Dies wird sich jedoch zeigen, sobald diese Zusatzfunktionalitäten implementiert werden.

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

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.
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 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 ==
<references />

← Nächstältere Version		Version vom 28. Januar 2017, 19:24 Uhr
Zeile 1:		Zeile 1:
		+	{\|
		+	\|<div style="font-size:32px;font-weight:bolder">
		+	'''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.		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.

@@ Zeile 104: / Zeile 104: @@
 | 0x00 || Reserved
 |-
-| 0x01 || [[Space-Bot]] (RPi)
+| 0x01 || [[Caninchen]] (RPi)
 |-
 | 0x21 || [[TuerNode]]

@@ Zeile 100: / Zeile 100: @@
 | 0x01 || [[Space-Bot]] (RPi)
 |-
-| 0x20 || [[TuerNode]]
+| 0x21 || [[TuerNode]]
 |-
 | 0xFF || Broadcast

@@ Zeile 1: / Zeile 1: @@
 == Schichtenmodell ==
 {| class="wikitable"
@@ Zeile 12: / Zeile 16: @@
 | 1 || Hardwareschicht || Bitübertragungsschicht
 |}
 === Hardwareschicht ===
@@ Zeile 63: / Zeile 69: @@
 |||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="8" | Address || colspan="3" | Protocol || Direction || - || colspan="8" | Data-0 || colspan="8" | Data-1
+! talbus-Identifier || colspan="8" | Address || colspan="3" | Protocol || Direction || Reserved || colspan="8" | Data-0 || colspan="8" | Data-1
 |}

@@ Zeile 108: / Zeile 108: @@
 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.
-Eine genaue Verteilung der DIDs und auch der gesamten SIDs ist in der [[:Kategorie:talNode|Liste der talNodes]] zu finden.
+Eine genaue Verteilung der DIDs und auch der gesamten SIDs ist in der auf der Seite des jeweiligen talNode zu finden.
 ===== Filterung im Controller =====
@@ Zeile 130: / Zeile 130: @@
 ===== Special-Control (SC) =====
 Mit diesem Datenfeld lassen sich besondere Steuernachrichten übermitteln. Damit ist es zum Beispiel möglich, bestimmte Nodes neuzustarten.
-	Normale Nachricht
+{| class="wikitable"
+! SC !! Bedeutung
-	Node neustarten
+|-
+| 0b00 || Normale Nachricht
-Um bestimmte Nodes damit zu Adressieren, muss einfach eine Nachricht mit einem Identifier gesendet werden, auf den dieser Node reagiert.
+|-
-Im idealfall könnte es auch Broadcast-Adressen geben, dies muss jedoch erst implementiert werden.
+| 0b01 ||
-In der Spezialnachricht muss als nulltes Datenbyte (EID15:8, siehe unten) ein eindeutiger Identifier (Node-ID) des bestimmten Nodes liegen. Dadurch wird es möglich, garantiert einen speziellen Node zu adressieren.
+|-
-Die Zuweisung der NIDs sollte dann im Wiki vorgehalten werden, und wenigstens auf der Seite der jeweiligen Nodes zu finden sein.
+| 0b10 || Node neustarten
-Dies wird sich jedoch zeigen, sobald diese Zusatzfunktionalitäten implementiert werden.
+|-
 ===== Datenfelder =====
@@ Zeile 151: / Zeile 156: @@
 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 ==
 <references />