Talbus: Unterschied zwischen den Versionen

Version vom 15. März 2014, 10:36 Uhr

Schichtenmodell

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

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:

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 auf der Seite des jeweiligen talNode 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.

Special-Control (SC)

Mit diesem Datenfeld lassen sich besondere Steuernachrichten übermitteln. Damit ist es zum Beispiel möglich, bestimmte Nodes neuzustarten.

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. Die Zuweisung der Node-IDs ist weiter unten zu finden.

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.

Liste aller Nodes

Siehe auch Liste der talNode-Seiten

Referenzen

1. ↑ Pinbelegung des CAN-Bus im Labor in Bochum