CAN@home

In diesem Abschnitt werden die Konzepte und Konventionen für die Softwarerealisierung beschrieben.

Jedem der max. 100 Busteilnehmer wird eine Knotennummer zugeordnet (0-99). Diese Zuordnung wird zur Vereinfachung der ID-Vergabe getroffen. Für die 16 verfügbaren Nachrichtenspeicher (Message-Object 0-15, MO0-15) (Abbildung 3.1) eines Knotens werden IDs vergeben, die die Empfangsadressen für die angeschlossene Busteilnehmerhardware bilden. Für jeden Busteilnehmer können aus der Knotennummer somit eindeutig die für ihn reservierten IDs bestimmt werden.

CAN-Netzwerke verwenden prioritätsbehaftete Nachrichtenobjekte, hier jedoch werden die IDs als Adressen verwendet.

MO0 wird benutzt um zu versendende Telegramme auf den Bus zu schicken (daraus resultiert eine sich ständig ändernde ID). Die ID von MO0 wird mit einer Anfangs-ID von 0 vorbesetzt (Abbildung 3.2). Es wird festgelegt, daß ID=0 im Normalbetrieb nicht verwendet werden darf. MO1-MO13 werden applikationsspezifisch vorbelegt (Erklärung der spezifischen ID-Festlegung folgt später). MO14 ist als Broadcast-MO vorgesehen, und dient dem Zweck, daß alle Busteilnehmer gemeinsam/gleichzeitig über eine definierte ID (ID=1) angesprochen werden können. Dies kann z.B. für allgemeine Konfigurations- und Parametrierungsaufgaben genutzt werden. Über die MO15 zugeordnete ID kann jeder Knoten einzeln angesprochen werden, um in ihm implementierte Steuer- bzw. Konfigurationsbefehle auszuführen (siehe Knotenbefehlsliste im Anhang). Die ID für die Knotenadresse, die dann im ID-Bereich von MO15 abgelegt werden muß, kann wie folgt berechnet werden:

Die IDs für MO1-MO13 können von der Applikationshardware verwendet werden um eine gezielte Adressierung ihrer Komponenten zu erreichen. So kann z.B. jedem Relais eine eigene ID zugeteilt werden. Die IDs werden dann wie folgt gebildet:

a.) An Knoten 2 sei eine I/O-Applikation mit 4 Relais angeschlossen. Die ID Vorbelegung, die über die Akzeptanz der eintreffenden Telegramme entscheidet, soll ermittelt werden. MO1 wird Relais 1, MO2 wird Relais 2, MO3 wird Relais 3 und MO4 wird Relais 4 zugeordnet.

Aus den Gleichungen (3.3) und (3.4) ergibt sich folgende Tabelle für die MO-ID Vorbelegung in Knoten 2:

Die ermittelten IDs müssen in die 2 ID-Bytes je Message-Objekt (MO) des CAN-Controllers eingetragen werden. Die beiden ID-Bytes haben untenstehende Zusammensetzung:

Darin ist zusätzlich noch die Anzahl der zu übertragenden Datenbytes (DLC-Bits, Data Length Code), die zwischen 0 und 8 liegen kann, und das RTR (Remote Transmission Request-Bit), auf das hier nicht näher eingegangen werden soll, enthalten. (Hier: RTR=0)

Die IDs sind in einer Tabelle im Atmel µC EEProm abgelegt und werden beim Initialisieren in den CAN-Controller geladen. Folgende Abbildung veranschaulicht die Lage im EEProm:

Ab Adresse 4h beginnt das ID-Byte Paar (IDByte0, IDByte1) für MO0. Alle weiteren ID-Byte-Paare bis MO15 folgen (siehe umrahmter Bereich).

Nicht verwendete MO-IDs und das Sende-MO werden grundsätzlich mit ID=0 vorbelegt.

3.2 Wirkungskette Tasterbetätigung bis Relaisschaltvorgang (I/O-Applikation)

In dieser Wirkungskette wurde die Konzeption einer direkten Adressierung eines Relais durch eine Tasterbetätigung realisiert. Eine Tasterbetätigung löst den gezielten Versand eines Telegramms an ein bestimmtes Relais aus. Für eine andere Anwendung ist eine ereignisgesteuerte Kommunikation deshalb nicht ausgeschlossen (z.B. Temperaturmeßstelle gibt per Ereignistelegramm (bestimmtes Paket auf dem CAN-Bus) die aktuelle Temperatur bekannt; jeder daran interessierte Knoten kann darauf reagieren).

Auf der I/O-Applikation sind 4 Eingänge vorgesehen, die von der Busknotensoftware zyklisch abgefragt werden. Tritt an einem Eingang eine 0->1 Flanke auf, so werden vorgefertigte Bustelegramme aus dem µC-EEProm geladen und auf den CAN-Bus gesendet. Für jeden Tastereingang können bis zu 13 vordefinierte Telegramme im EEProm abgelegt werden. Ein solches Telegramm wird nach folgendem Schema definiert:

1. Byte	2. Byte	3. Byte	4. Byte
Ziel-ID-Byte0	Ziel-ID-Byte1	Nutzdatenbyte0	Nutzdatenbyte1

Die ersten beiden Bytes repräsentieren die dem zu schaltenden Relais zugeordnete ID. Byte3 beinhaltet die Schaltinformation für das Relais; gültige Werte dafür sind:

Byte 4 ist reserviert und wird hier nicht ausgewertet. Aus Speicherplatzgründen wurde hier von Telegrammen mit mehr als 2 Datenbyte abgesehen.

Die für Taster 1 bis 4 abgelegten Telegramme sind in 4 Tabellen zu je 13 Telegrammen organisiert. Jeder Stapel endet spätestens beim 13. Telegramm mit einem "NullTelegramm" (4 Byte 0x00). Das "NullTelegramm" signalisiert das Stapelende, das bedeutet es wurden alle Telegramme versendet. Die Lage der 4 Stapel im EEProm sind in der untenstehenden Abbildung veranschaulicht.

Der CAN-Controller kann nicht ein Telegramm auf den Bus senden und dieses gleichzeitig selbst empfangen. Deshalb ist es auch nicht möglich ein Telegramm an ein lokal vorhandenes Relais zu senden. Dies wird durch eine separate Softwareroutine abgefangen, die lokal durchzuführende Relaisschaltvorgänge ausführt. Die Schaltinformation dafür ist in 4 weiteren EEProm-Bytes hinterlegt. (Für jeden Taster ist ein Byte vorgesehen, das die Schaltbefehle der 4 lokalen Relais repräsentiert):

EEProm-Speicherstelle	Inhalt
F4h	lokale Relaisschaltvorgänge für Taster 1
F5h	lokale Relaisschaltvorgänge für Taster 2
F6h	lokale Relaisschaltvorgänge für Taster 3
F7h	lokale Relaisschaltvorgänge für Taster 4

Im jeweiligen EEProm-Byte wird der gewünschte Relaisschaltvorgang durch 2 Bit repräsentiert

EEProm-Speicherstelle	Bit 7/6	Bit 5/4	Bit 3/2	Bit 1/0
gewünschter Schaltvorgang für	Relais 4	Relais 3	Relais 2	Relais 1

Für die Bitkombinationen gelten auch hier die schon vorher getroffenen Festgelegungen:

Taster 2 soll zusätzlich zum Versenden seines Telegrammstapels auch das lokale Relais 2 einschalten und Relais 4 umschalten. Der Schaltzustand von Relais 1 und 3 (lokal) soll unverändert bleiben.

Wird von einem Knoten ein Telegramm empfangen, das für eines seiner Relais bestimmt ist, so löst der CAN-Controller am µC einen (Empfangs-)Interrupt aus. In der danach aufgerufenen Interruptroutine werden die Nutzdaten aus dem empfangenen Telegramm extrahiert und der so erhaltene Steuerbefehl löst den geforderten Schaltvorgang aus.

3.3 Kommunikation zwischen PC und RS232-Knoten

Busteilnehmer und Rechner sind durch den RS232-Knoten in der Lage, miteinander Daten auszutauschen. Um dies zu ermöglichen sind im RS232-Knoten softwaretechnisch fünf Steuer-/Kommunikationsbefehle (RS232 Befehle) implementiert. Um die Ausführung eines implementierten Befehls auszulösen, erwartet der RS232-Knoten über seine serielle Schnittstelle ein Datenpaket von 13 Byte, die er in seinem Speicher (SRAM) zur Auswertung zwischenpuffert. Jedes Datenpaket wird durch folgendes Format charakterisiert:

Das Befehlsanfangszeichen ‘<‘ leitet einen Befehl ein. Fehlt dieses Zeichen, dann werden die folgenden Zeichen verworfen, bis erneut ein Befehlsanfangszeichen ‘<‘ auftritt.

Danach wird das Befehlszeichen (1 Byte) übermittelt, gefolgt von den (genau) 10 Datenbytes (Datenbyte 0-9). Nicht jeder Befehl verwendet alle 10 Datenbytes; werden weniger benötigt muß das Paket mit beliebigen Zeichen auf 10 Datenbytes aufgefüllt werden (Diese Zeichen werden dann nicht interpretiert). Die konstante Befehlslänge vereinfacht die Kommunikationssoftware des RS232-Knotens.

Am Ende des Datenpakets steht das Befehlsendezeichen ‘>‘. Ein gültiger Befehl wird also immer von der Zeichenkette ‘< ... >‘ umschlossen. Erkennt der µC dieses Befehlsendezeichen nicht genau an Byteposition 13, so verwirft er das komplette Datenpaket.

Der Empfang und die erfolgreiche Abarbeitung der Befehle 1 und 2, die der RS232-Knoten erhält, wird durch die Zeichenkette <*> von ihm quittiert. Die Befehle 3, 4 und 5 werden durch ihre geforderte Antwort quittiert.

... wird benutzt, um vom Rechner aus ein CAN-Telegramm auf den CAN-Bus zu senden. Der RS232-Knoten fungiert dabei nur als transparenter Protokoll- und Medienkonverter. Der RS232-Knoten extrahiert aus dem empfangenen 13 Byte-Datenpaket (vom PC) das darin enthaltene 8 Byte lange CAN-Telegramm samt der Ziel-Adresse (2 Byte Ziel-ID) und versendet es. Das Befehlsformat ist im Anhang näher erläutert.

... wird benutzt, um vom Rechner aus die ID Bytes eines Message Objects (MO) neu zu besetzen. Dies wird im RS232-Knoten genutzt, um mit Hilfe von MO0-MO12 bestimmte Telegramme zu überwachen (Telegrammüberwachung). Befehlsformat siehe Anhang.

... wird benutzt, um vom Rechner aus Lesezugriff auf sämtliche lokalen CAN-Register zu erhalten. Damit können alle Registerinhalte des CAN-Controllers vollständig über den Rechner ausgelesen/überwacht werden. (Beispiel: Kontrolle über die I/O-Ports, usw.). Befehlsformat siehe Anhang.

... wird benutzt, um vom Rechner aus Schreibzugriff auf sämtliche lokalen CAN-Register zu erhalten. Damit kann der CAN-Controller des RS232-Knoten vollständig vom Rechner aus konfiguriert werden. (Beispiel: Interruptmaskierung verändern, usw.). Befehlsformat siehe Anhang.

... wird benutzt, um vom Rechner aus die Knotenexemplarnummer vom RS232-Knoten auszulesen. Befehlsformat siehe Anhang.

Ein Programmabschnitt (Telegrammüberwachung) der RS232-Knotensoftware sendet auf MO0-MO12 eingetroffene Telegramme direkt an den angeschlossenen PC (in ein entsprechendes Format gebracht <a..>-Befehl, Beschreibung in Kapitel 3.4). Die Grundeinstellung der IDs für MO0-MO12 ist ID=0 und da ID=0 per Definition für CAN-Telegramme nicht verwendet werden darf (es kann also kein Telegramm mit ID=0 eintreffen), wird im Grundzustand dieser Softwareteil nicht ausgelöst. Um die Telegrammüberwachung zu aktivieren, muß einfach die zu protokollierende ID in den ID-Bereich des gewünschten MessageObjects (MO0-MO12) geschrieben werden (Verwendung von RS232-Befehl 2).

In Verbindung mit der Telegrammüberwachungsfunktion und der BasicCAN-Funktionalität des CAN-Controllers (MonitorMode; sämtliche Telegramme auf dem Bus in MO0 schreiben, ohne Akzeptanzprüfung) kann eine komplette Überwachung des Busses mittels PC realisiert werden. Es kann dann der gesamte Busverkehr zur Auswertung mitprotokolliert werden. So lassen sich Fragen nach der Zuverlässigkeit einzelner Komponenten beantworten, wie zum Beispiel die Anzahl der Schaltspiele eines Relais, Betriebsstundenzahl usw..

Um den MonitorMode zu aktivieren, müssen einige Registerinhalte im CAN-Controller verändert werden; hierfür ist RS232-Befehl 4 geeignet.

MO13 bietet die Möglichkeit, daß ein Busteilnehmer einen angeschlossenen PC gezielt erreichen kann. Die vorbelegte ID darf deshalb nicht verändert werden.

3.4 Kommunikation zwischen Busteilnehmern

Zusätzlich zum normalen Busdatenverkehr können die Busteilnehmer implementierte Steuer/Parametrierungsbefehle (Knotenbefehl 1-6) senden und empfangen. Anhand dieser Befehle kann ein Busteilnehmer vollständig von einem anderen Busteilnehmer über den CAN-Bus konfiguriert werden - dazu ist kein spezieller RS232-Knoten nötig.

Diese Befehle haben ein definiertes Format, dessen Länge allerdings variieren kann:

... ermöglicht es ein Daten-Byte aus dem µC-EEProm des adressierten Busteilnehmers auszulesen. Der Busteilnehmer, der diesen Befehl absendet, erhält vom Ziel-Busteilnehmer ein entsprechendes Antworttelegramm. Befehls- bzw. Antwortformat siehe Anhang.

... ermöglicht es ein Daten-Byte in das µC-EEProm des adressierten Busteilnehmers zu schreiben. Der Busteilnehmer, der diesen Befehl absendet, erhält vom Ziel-Busteilnehmer ein entsprechendes Antworttelegramm. Befehls- bzw. Antwortformat siehe Anhang.

... ermöglicht es ein Daten-Byte aus einem CAN-Register des adressierten Busteilnehmers auszulesen. Der Busteilnehmer, der diesen Befehl absendet, erhält vom Ziel-Busteilnehmer ein entsprechendes Antworttelegramm. Befehls- bzw. Antwortformat siehe Anhang.

... ermöglicht es ein Daten-Byte in ein CAN-Register des adressierten Busteilnehmers zu schreiben. Der Busteilnehmer, der diesen Befehl absendet, erhält vom Ziel-Busteilnehmer ein entsprechendes Antworttelegramm. Befehls- bzw. Antwortformat siehe Anhang.

... ermöglicht es ein Daten-Byte aus einem Atmel-µC-Register des adressierten Busteilnehmers auszulesen. Der Busteilnehmer, der diesen Befehl absendet, erhält vom Ziel-Busteilnehmer ein entsprechendes Antworttelegramm. Befehls- bzw. Antwortformat siehe Anhang.

... ermöglicht es ein Daten-Byte in ein Atmel-µC-Register des adressierten Busteilnehmers zu schreiben. Der Busteilnehmer, der diesen Befehl absendet, erhält vom Ziel-Busteilnehmer ein entsprechendes Antworttelegramm. Befehls- bzw. Antwortformat siehe Anhang.

Beispiel 1: Zur Laufzeit möchte Knoten 3 von Knoten 2 erfahren, welche Relais lokal in Knoten 2 durch Taster 4 geschaltet werden. Die interessierende EEProm-Adresse hierfür lautet F7h (nachzuschlagen im Abschnitt "Wirkungskette Tasterbetätigung bis Relaisschaltvorgang (I/O-Applikation)"). Dazu sendet Knoten 3 einen "FernEEProm lesen"-Befehl an die Knotenadresse von Knoten 2; die Antwort hierauf erwartet Knoten 3 beispielsweise in seinem MessageObject10 (MO10); in MO10 (Antwort-ID-Byte0/1) steht definitionsgemäß als ID: 258dez. Daraus ergeben sich die beiden ID-Byte 0 und 1 (in Kombination mit DLC=8 und RTR-Bit=0):

Aufbau des gesendeten CAN-Bus Telegrammes: (Speicherabbild des SendeMOs (MO0) von Knoten 3)

Daraufhin sendet Knoten 2 seine Antwort an die ihm übermittelte Adresse (in diesem Fall ID-MO 10, Knoten 3).

Aufbau des Antwort CAN-Bus Telegrammes: (Speicherabbild des SendeMOs (MO0) von Knoten 2)

Beispiel 2: Ein RS232-Knoten (Knoten 1) soll per "FernCANRegister lesen"-Befehl den Zustand von Port0 (Tastereingänge der I/O-Applikation, P0PR, 29h) an Knoten 2 auslesen und die Antwort an die Adresse des MO13 des RS232-Knotens senden. Denn alle auf MO13 eines RS232-Knotens eintreffenden Pakete werden automatisch unverändert über die RS232-Schnittstelle ausgegeben. Ein daran angeschlossener PC kann die so übermittelte Antwort dann auswerten.

Beispiel 3: Durch die Kontrolle über die AtmelRegister im entfernten Knoten kann auch direkter Einfluß auf dessen I/O-Ports genommen werden. So kann zum Beispiel eine Hardware angeschlossen werden, für die die Knotensoftware noch nicht vorbereitet ist.

Der notwendige Softwareteil kann im entfernten Atmel-µC durch die Steuerbefehle eines zweiten, steuernden Knotens simuliert werden.

Da der Buskoppler eine offene Applikationsschnittstelle besitzt ist es möglich, weitere Applikationshardware über die bereits dargelegten Module hinaus zu entwickeln. So ist es beispielsweise denkbar, daß ein bestimmter Knoten als Zeitschaltglied fungiert und so zeitgesteuerte Vorgänge auslösen kann. Ein anderer Knoten könnte als Szenarioknoten bestimmte Einstellungen speichern und bei Bedarf gewisse Schaltsituationen/konfigurationen herstellen. (Lampen ein, Jalousie zu, Heizung auf 20°C stellen).

Temperaturmeßstellen könnten die aktuelle Temperatur an ein Display zur Anzeige weiterleiten oder an einen PC übermitteln.

3 Konzeption und Konvention

3.1 Adressierungsmodell und ID-Vergabe

3.2 Wirkungskette Tasterbetätigung bis Relaisschaltvorgang (I/O-Applikation)

3.3 Kommunikation zwischen PC und RS232-Knoten

3.4 Kommunikation zwischen Busteilnehmern