Home

News

Schnelleinstieg

Hintergrund

Doku

Bilder

Download

Forum

Kontakt

3 Konzeption und Konvention

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

3.1 Adressierungsmodell und ID-Vergabe

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.

Abbildung 3.1: Struktur eines Message-Objekts im CAN-Controller

 

MO0

MO1-MO13

MO14

MO15

Sende-MO

frei für Applikation

Broadcast-MO

Knotenadressen-MO

Anfangs-ID=0

Wenn ungenutzt: ID=0

feste ID (ID=1)

Knotenadresse

Abbildung 3.2: Standard ID-Vorbelegung für Busteilnehmer

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:

Knotenadresse := Knotennummer + 100         (3.3)

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:

ID := Knotennummer * 16 + MO<n> + 200               (3.4)

Beispiel:

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:

MO<n>

MO0

MO1

MO2

MO3

MO4

MO5-MO13

MO14

MO15

Verwendung

Sende-MO

Relais 1

Relais 2

Relais 3

Relais 4

keine

Broadcast-MO

Knotenadressen-MO

berechnete ID

0

233

234

235

236

0

1

102

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

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:

ID-Byte0

ID.Bit10

ID.Bit9

ID.Bit8

ID.Bit7

ID.Bit6

ID.Bit5

ID.Bit4

ID.Bit3

ID-Byte1

ID.Bit2

ID.Bit1

ID.Bit0

RTR-Bit

DLC.Bit3

DLC.Bit2

DLC.Bit1

DLC.Bit0

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

ID-Bereiche im Überblick

ID-Bereich

Verwendung

0

darf definitionsgemäß nicht verwendet werden

1-99

reserviert

100-199

Knotenadresse

200-215

Knoten 0

216-231

Knoten 1

...

...

1768-1783

Knoten 98

1784-1799

Knoten 99

1800-2048

reserviert

Abbildung 3.5: festgelegte ID-Einteilung

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:

  • 0: Relais ausschalten
  • 1: Relais einschalten
  • 2: Relais umschalten
  • 3: keine Relaiszustandsänderung

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.

Abbildung 3.6: Lage der vordefinierten Telegrammblöcke im EEProm

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:

  • 0: Relais ausschalten                            (0 0)
  • 1: Relais einschalten                             (0 1)
  • 2: Relais umschalten                            (1 0)
  • 3: keine Relaiszustandsänderung          (1 1)

Beispiel:

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.

Daraus ergibt sich das EEProm-Byte mit Adresse F5h für Taster 2: 0b10110111

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.

Abbildung 3.7: Wirkungskette Tastendruck - Relaisschaltvorgang


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:

 

<

Befehl

Byte 0

Byte 1

Byte 2

Byte 3

Byte 4

Byte 5

Byte 6

Byte 7

Byte 8

Byte 9

>

Bytenr.

1

2

3

4

5

6

7

8

9

10

11

12

13

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.

 

RS232-Befehlsliste:

  • RS232-Befehl 1: Telegramm senden (CAN-Telegramm)
  • RS232-Befehl 2: lokale CAN-Controller MO-ID-Tabelle umprogrammieren
  • RS232-Befehl 3: CAN-Register auslesen (lokaler RS232-Knoten)
  • RS232-Befehl 4: CAN-Register schreiben (lokaler RS232-Knoten)
  • RS232-Befehl 5: Knotenexemplarnummer auslesen (lokaler RS232-Knoten)

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.

Telegramm senden (CAN-Telegramm)

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

Lokale CAN-Controller MO-ID-Tabelle umprogrammieren

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

CAN-Register auslesen (lokaler RS232-Knoten)

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

CAN-Register schreiben (lokaler RS232-Knoten)

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

Knotenexemplarnummer auslesen (lokaler RS232-Knoten)

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


Exemplarische Verwendungszwecke der vorgestellten RS232-Befehle

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.

MO-ID-Initialisierungsstabelle für RS232-Knoten

MO<n>

MO0

MO1-MO12

MO13

MO14

MO15

Verwendung

Telegrammüberwachung/
SendeMO/MonitorMode

Telegrammüber-wachung

Telegrammüber-wachung

Broadcast

Knoten-adresse

berechnete ID

0

0

261

1

103

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:

Telegrammformat für zu versendende Knotenbefehle:

 

Befehl

Antwort-id-Byte0

Antwort-id-Byte1

Byte 0

(Byte 1)

(Byte 2)

Bytenr.

1

2

3

4

(5)

(6)

Telegrammformat für Antworten auf empfangene Knotenbefehle:

 

Befehl

KnotenadresseByte0

KnotenadresseByte1

Byte 0

Byte 1

(Byte 2)

Bytenr.

1

2

3

4

5

(6)

Knotenbefehlsliste:

  • Knotenbefehl 1: FernEEProm lesen
  • Knotenbefehl 2: FernEEProm schreiben
  • Knotenbefehl 3: FernCANRegister lesen
  • Knotenbefehl 4: FernCANRegister schreiben
  • Knotenbefehl 5: FernAtmelRegister lesen
  • Knotenbefehl 6: FernAtmelRegister schreiben

FernEEProm lesen

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

FernEEProm schreiben

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

FernCANRegister lesen

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

FernCANRegister schreiben

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

FernAtmelRegister lesen

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

FernAtmelRegister schreiben

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

Exemplarische Verwendungszwecke der vorgestellten Knotenbefehle

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

ID-Byte 0: 20h, ID-Byte 1: 48h

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

MO-ID-Bytes

Daten-Bytes

Byte0

Byte1

Byte0

Byte1

Byte2

Byte3

Byte4

Byte5-7

Knotenadresse von Knoten 2 - ID-Byte0

Knotenadresse von Knoten 2 - ID-Byte1

Befehl

Antwort-id-Byte0

Antwort-id-Byte1

EE-Adr.-high

EE-Adr.-low

 

0Ch

C8h

"1"

20h

48h

0h

F7h

leer

 

 



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)

MO-ID-Bytes

Daten-Bytes

Byte0

Byte1

Byte0

Byte1

Byte2

Byte3

Byte4

Byte5

Byte6-7

Antwortadresse von Knoten 3 - ID-Byte0

Antwortadresse von Knoten 3 - ID-Byte1

Befehl

Absender-id-Byte0

Absender-id-Byte1

EE-Adr.-high

EE-Adr.-low

ausgelesenes Byte

 

20h

48h

"1"

0Ch

C8h

0h

F7h

z.B. FEh

leer

 

 

 


Die Antwort liegt daraufhin in Knoten3, MO10 zur weiteren Verarbeitung bereit.


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.

Anfrage:

0Ch

C8h

"3"

1Ch

A8h

29h

Antwort:

1Ch

A8h

"3"

0Ch

C8h

29h

A0h (z.B.)

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.