4 \section{Sockets für den Broadcast-Manager}
7 Der \BCM\ stellt Funktionen zur Verfügung, um Nachrichten
8 auf dem CAN-Bus einmalig oder periodisch zu senden, sowie um
9 (inhaltliche) Änderungen von (zyklisch) empfangenen CAN-Frames mit
10 einer bestimmten CAN-ID zu erkennen.\\
12 Dabei muss der \BCM\ folgende Anforderungen erfüllen:
14 \textbf{\\Sendeseitig:}
17 \item Zyklisches Senden einer CAN-Botschaft mit einem gegebenen Intervall
18 \item Verändern von Botschaftsinhalten und Intervallen zur Laufzeit
19 (z.B. Umschalten auf neues Intervall mit/ohne sofortigen Neustart
21 \item Zählen von Intervallen und automatisches Umschalten auf ein
23 \item Sofortige Ausgabe von veränderten Botschaften, ohne den
24 Intervallzyklus zu beeinflussen ('Bei Änderung sofort')
25 \item Einmalige Aussendung von CAN-Botschaften
28 \textbf{Empfangsseitig:}
31 \item Empfangsfilter für die Veränderung relevanter Botschaftsinhalte
32 \item Empfangsfilter ohne Betrachtung des Botschaftsinhalts (CAN-ID-Filter)
33 \item Empfangsfilter für Multiplexbotschaften (z.B. mit Paketzählern
35 \item Empfangsfilter für die Veränderung vom Botschaftslängen
36 \item Beantworten von RTR-Botschaften
37 \item Timeoutüberwachung von Botschaften
38 \item Reduzierung der Häufigkeit von Änderungsnachrichten (Throttle-Funktion)
42 \subsection{Kommunikation mit dem Broadcast-Manager}
45 Im Gegensatz zum RAW-Socket (Kapitel \ref{rawsocket}) und den
46 Transportprotokoll-Sockets (Kapitel \ref{tpsocket}) werden über den
47 Socket des \BCM\ weder einzelne CAN-Frames noch längere - zu
48 segmentierende - Nutzdaten übertragen.\\
50 Der \BCM\ ist vielmehr ein programmierbares Werkzeug, dass über
51 besondere Nachrichten vom Anwender gesteuert wird und auch Nachrichten
52 an den Anwender über die Socket-Schnittstelle schicken kann.\\
54 Für die Anwendung des \BCM\ muss die Include-Datei \verb+bcm.h+
57 Ein Socket zum \BCM\ wird durch
60 s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);
65 Mit dem \textsf{connect()} wird dem Socket das CAN-Interface eindeutig
66 zugewiesen. Möchte ein Prozess auf mehreren CAN-Bussen agieren, muss
67 er folglich mehrere Sockets öffnen. Es ist allerdings auch möglich,
68 dass ein Prozess mehrere Instanzen (Sockets) des \BCM\ auf einem
69 CAN-Bus öffnet, wenn dieses für den Anwendungsprogrammierer zur
70 Strukturierung verschiedener Datenströme sinnvoll ist. Jede einzelne
71 Instanz des \BCM\ ist in der Lage beliebig viele Filter- und/oder
72 Sendeaufträge zu realisieren.
75 addr.can_family = AF_CAN;
76 strcpy(ifr.ifr_name, "can0");
77 ioctl(s, SIOCGIFINDEX, &ifr);
78 addr1.can_ifindex = ifr.ifr_ifindex;
80 connect(s, (struct sockaddr *)&addr, sizeof(addr));
83 Alle Nachrichten zwischen dem (Anwender-)Prozess und dem \BCM\
84 besitzen die selbe Struktur. Sie besteht aus einem Nachrichtenkopf mit
85 dem Steuerungskommando und der für diesen Socket/CAN-Bus eindeutigen
90 int opcode; /* command */
91 int flags; /* special flags */
92 int count; /* run 'count' times ival1 then ival2 */
93 struct timeval ival1, ival2; /* intervals */
94 canid_t can_id; /* 32 Bit SFF/EFF. MSB set at EFF */
95 int nframes; /* number of following can_frame's */
96 struct can_frame frames[0];
100 Der Wert \verb+nframes+ gibt an, wie viele Nutzdaten-Frames dem
101 Nachrichtenkopf folgen. Die Nutzdaten-Frames beschreiben den
102 eigentlichen Nachrichteninhalt einer CAN-Botschaft:
106 canid_t can_id; /* 32 bit CAN_ID + EFF/RTR flags */
107 __u8 can_dlc; /* data length code: 0 .. 8 */
108 __u8 data[8] __attribute__ ((aligned(8)));
112 Der \verb+opcode+ definiert, um was für eine Nachricht es sich
113 handelt. Nachrichten vom Anwender an den \BCM\ steuern die Operationen
114 des \BCM, Nachrichten vom \BCM\ an den Anwender signalisieren bestimmte
115 Änderungen, Timeouts, etc.\\
117 Der Sende- und Empfangszweig des \BCM\ sind dabei zwei eigenständige
120 Für den Sendezweig existieren die Opcodes
123 \item[TX\_SETUP] zum Einrichten und Ändern von Sendeaufträgen
124 \item[TX\_DELETE] zum Löschen von Sendeaufträgen
125 \item[TX\_READ] zum Auslesen des aktuellen Sendeauftrags (zu Debug-Zwecken)
126 \item[TX\_SEND] zum einmaligen Senden einer CAN-Botschaft
130 Für den Empfangszweig existieren die Opcodes
133 \item[RX\_SETUP] zum Einrichten und Ändern von Empfangsfiltern
134 \item[RX\_DELETE] zum Löschen von Empfangsfiltern
135 \item[RX\_READ] zum Auslesen des aktuellen Empfangsfilters (zu Debug-Zwecken)
139 Als Antwort schickt der \BCM\ Nachrichten in der gleichen Form, wie er
140 selbst die Anforderungen erhält. Dabei sendet der \BCM\ die Opcodes
143 \item[TX\_STATUS] als Antwort auf TX\_READ
144 \item[TX\_EXPIRED] wenn der Zähler \verb+count+ für \verb+ival1+
145 abgelaufen ist (nur bei gesetztem Flag \verb+TX_COUNTEVT+, s.u.)
146 \item[RX\_STATUS] als Antwort auf RX\_READ
147 \item[RX\_TIMEOUT] wenn der zeitlich überwachte Empfang einer
148 Botschaft ausgeblieben ist
149 \item[RX\_CHANGED] wenn die erste bzw. eine geänderte CAN-Nachricht
154 Jede dieser durch einen \verb+opcode+ bestimmten Funktionen wird eindeutig
155 mit Hilfe der \verb+can_id+ referenziert.\\
157 Zusätzlich existieren noch optionale \verb+flags+, mit denen der \BCM\ in
158 seinem Verhalten beeinflusst werden kann:
161 \item[SETTIMER :] Die Werte \verb+ival1+, \verb+ival2+ und
162 \verb+count+ werden übernommen
163 \item[STARTTIMER :] Der Timer wird mit den aktuellen Werten von \verb+ival1+,
164 \verb+ival2+ und \verb+count+ gestartet. Das Starten des Timers
165 führt gleichzeitig zur Aussendung eines \verb+can_frame+'s.
166 \item[TX\_COUNTEVT :] Erzeuge die Nachricht TX\_EXPIRED, wenn \verb+count+
168 \item[TX\_ANNOUNCE :] Eine Änderung der Daten durch den Prozess wird zusätzlich
169 unmittelbar ausgesendet. (Anforderung aus 'Bei Änderung Sofort' -
171 \item[TX\_CP\_CAN\_ID :] Kopiert die \verb+can_id+ aus dem
172 Nachrichtenkopf in jede der angehängten \verb+can_frame+'s. Dieses ist
173 lediglich als Vereinfachung der Benutzung gedacht.
174 \item[TX\_RESET\_MULTI\_IDX :] Erzwingt das Rücksetzen des
175 Index-Zählers beim Update von zu sendenden von Multiplex-Nachrichten
176 auch wenn dieses aufgrund der gleichen Länge nicht nötig wäre. Siehe
177 Seite \pageref{txsendmux}.
178 \item[RX\_FILTER\_ID :] Es wird keine Filterung der Nutzdaten
179 ausgeführt. Eine Übereinstimmung mit der empfangenen \verb+can_id+
180 führt automatisch zu einer Nachricht RX\_CHANGED. {\bf Vorsicht also bei
181 zyklischen Nachrichten!} Bei gesetztem RX\_FILTER\_ID-Flag {\it kann}
182 auf das CAN-Frame beim RX\_SETUP verzichtet werden (also \verb+nframes=0+).
183 \item[RX\_RTR\_FRAME :] Die im Filter übergebene CAN-Nachricht wird
184 beim Empfang eines RTR-Frames ausgesendet. Siehe Seite \pageref{rxrtrframe}.
185 \item[RX\_CHECK\_DLC :] Eine Änderung des DLC führt zu einem RX\_CHANGED.
186 \item[RX\_NO\_AUTOTIMER :] Ist der Timer ival1 beim RX\_SETUP ungleich
187 Null gesetzt worden, wird beim Empfang der CAN-Nachricht automatisch
188 der Timer für die Timeout-Überwachung gestartet. Das Setzen dieses
189 Flags unterbindet das automatische Starten des Timers.
190 \item[RX\_ANNOUNCE\_RESUME :] Bezieht sich ebenfalls auf die
191 Timeout-Überwachung der Funktion RX\_SETUP. Ist der Fall des RX-Timeouts
192 eingetreten, kann durch Setzen dieses Flags ein RX\_CHANGED erzwungen
193 werden, wenn der (zyklische) Empfang wieder einsetzt. Dieses gilt
194 besonders auch dann, wenn sich die Nutzdaten nicht geändert haben.
198 \subsection{TX\_SETUP}
201 Mit TX\_SETUP wird für eine bestimmte CAN-ID ein (zyklischer)
202 Sendeauftrag eingerichtet oder geändert.\\
204 Typischerweise wird dabei eine Variable angelegt,
205 bei der die Komponenten \verb+can_id+, \verb+flags+
206 (\verb+SETTIMER+,\verb+STARTTIMER+), \verb+count+=0,
207 \verb+ival2+=100ms, \verb+nframes+=1 gesetzt werden und die Nutzdaten in der
208 Struktur \verb+can_frame+ entsprechend eingetragen werden. Diese Variable wird
209 dann im Stück(!) mit einem \textsf{write()}-Systemcall auf dem Socket
210 an den \BCM\ übertragen. Beispiel:
214 struct bcm_msg_head msg_head;
215 struct can_frame frame[4]; /* just an example */
218 msg.msg_head.opcode = TX_SETUP;
219 msg.msg_head.can_id = 0x42;
220 msg.msg_head.flags = SETTIMER|STARTTIMER|TX_CP_CAN_ID;
221 msg.msg_head.nframes = 1;
222 msg.msg_head.count = 0;
223 msg.msg_head.ival1.tv_sec = 0;
224 msg.msg_head.ival1.tv_usec = 0;
225 msg.msg_head.ival2.tv_sec = 0;
226 msg.msg_head.ival2.tv_usec = 100000;
227 msg.frame[0].can_id = 0x42; /* obsolete when using TX_CP_CAN_ID */
228 msg.frame[0].can_dlc = 3;
229 msg.frame[0].data[0] = 0x123;
230 msg.frame[0].data[1] = 0x312;
231 msg.frame[0].data[2] = 0x231;
233 write(s, &msg, sizeof(msg));
236 Die Nachrichtenlänge für den Befehl TX\_SETUP ist also
237 \mbox{\tt \{[bcm\_msg\_head] [can\_frame]+\} } d.h. ein Nachrichtenkopf und
238 mindestens ein CAN-Frame.
240 \subsubsection{Besonderheiten des Timers}
242 Der Timer kann durch Setzen des Intervalls auf 0 ms (\verb+ival1+ und
244 gestoppt werden. Dabei wird die o.g. Variable wieder
245 mit dem gesetzten Flag SETTIMER an den \BCM\ übertragen.
246 Um eine zyklische Aussendung mit den übergebenen Timerwerten zu
247 starten, müssen also die Flags \verb+SETTIMER+ und \verb+STARTTIMER+ im Element
248 \verb+flags+ gesetzt sein.\\
250 Als Ergänzung zum obigen Beispiel kann auch mit zwei Intervallen für
251 die zyklische Aussendung der CAN-Botschaft gearbeitet werden. Dabei
252 wird die CAN-Botschaft zunächst \verb+count+ mal im Intervall
253 \verb+ival1+ gesendet
254 und danach bis zur expliziten Löschung durch TX\_DELETE oder durch
255 Stoppen des Timers im Intervall \verb+ival2+. Das Intervall
256 \verb+ival2+ darf auch
257 Null sein, in welchem Fall die Aussendung nach den ersten \verb+count+
258 Aussendungen stoppt. Falls \verb+count+ Null ist, spielt der Wert von
260 keine Rolle und muss nicht angegeben zu werden.\\
262 Ist das Flag \verb+STARTTIMER+ gesetzt, wird unmittelbar die erste
263 CAN-Botschaft ausgesendet.\\
265 Ist es für den Anwender wichtig zu erfahren, wann der \BCM\ vom
266 Intervall \verb+ival1+ auf \verb+ival2+ umschaltet (und somit u.U. die
268 einstellt), kann dieses dem \BCM\ durch das Flag \verb+TX_COUNTEVT+ angezeigt
269 werden. Ist der Wert von \verb+count+ auf Null heruntergezählt und das Flag
270 \verb+TX_COUNTEVT+ gesetzt worden, erzeugt der \BCM\ eine Nachricht mit dem
271 Opcode TX\_EXPIRED an den Prozess. Diese Nachricht
272 besteht nur aus einem Nachrichtenkopf (\verb+nframes+ = 0).\\
274 \subsubsection{Veränderung von Daten zur Laufzeit}
276 Zur Laufzeit können auch die Daten in der CAN-Botschaft geändert
277 werden. Dazu werden die Daten in der Variable
278 geändert und mit dem Opcode TX\_SETUP an den \BCM\ übertragen. Dabei
279 kann es folgende Sonderfälle geben:
281 \item Der Zyklus soll neu gestartet werden: Flag \verb+STARTTIMER+ setzen
282 \item Der Zyklus soll beibehalten werden aber die geänderten/beigefügten Daten
283 sollen sofort einmal gesendet werden: Flag \verb+TX_ANNOUNCE+ setzen
284 \item Der Zyklus soll beibehalten werden und die geänderten Daten erst mit dem
285 nächsten Mal gesendet werden: default Verhalten
288 Hinweis: Beim Neustarten des Zyklus werden die zuletzt gesetzten
289 Timerwerte (\verb+ival1+, \verb+ival2+) zugrunde gelegt, die vom \BCM\ nicht
290 modifiziert werden. Sollte aber mit zwei Timern gearbeitet werden,
291 wird der Wert \verb+count+ zur Laufzeit vom \BCM\ dekrementiert.
293 \subsubsection{Aussenden verschiedener Nutzdaten (Multiplex-Nachrichen)}
296 Mit dem \BCM\ können auch Multiplex-Nachrichten versendet
297 werden. Dieses wird benötigt, wenn z.B. im ersten Byte der Nutzdaten
298 ein Wert definiert, welche Informationen in den folgenden 7
299 Bytes zu finden sind. Ein anderer Anwendungsfall ist das Umschalten /
300 Toggeln von Dateninhalten. Dazu wird im Prozess eine Variable erzeugt,
301 bei der hinter dem Nachrichtenkopf mehr als ein Nutzdaten-Frame
302 vorhanden ist. Folglich werden an den \BCM\ für eine
303 CAN-ID nicht ein sondern mehrere \verb+can_frame+'s übermittelt. Die
304 verschiedenen Nutzdaten werden nacheinander im Zyklus der Aussendung
305 ausgegeben. D.h. bei zwei \verb+can_frame+'s werden diese abwechselnd im
306 gewünschten Intervall gesendet. Bei einer Änderung der Daten zur
307 Laufzeit, wird mit der Aussendung des ersten \verb+can_frame+
308 neu begonnen, wenn sich die Anzahl der zu sendenden
309 \verb+can_frame+'s beim Update verändert (also nframes$_{neu}$ $\neq$
310 nframes$_{alt}$). Bei einer gleichbleibenden Anzahl zu sendender
311 \verb+can_frame+'s kann dieses Rücksetzen des ansonsten normal
312 weiterlaufenden Index-Zählers durch Setzen des Flags
313 \verb+TX_RESET_MULTI_IDX+ erzwungen werden.
315 \subsection{TX\_DELETE}
318 Diese Nachricht löscht den Eintrag zur Aussendung der CAN-Nachricht mit
319 dem in \verb+can_id+ angegebenen CAN-Identifier.
320 Die Nachrichtenlänge für den Befehl TX\_DELETE ist
321 \mbox{\tt \{[bcm\_msg\_head]\} } d.h. ein Nachrichtenkopf.
323 \subsection{TX\_READ}
326 Mit dieser Nachricht kann der aktuelle Zustand, also die zu sendende
327 CAN-Nachricht, Zähler, Timer-Werte, etc. zu dem in \verb+can_id+
328 angegebenen CAN-Identifier
329 ausgelesen werden. Der \BCM\ antwortet mit einer Nachricht mit dem
330 \verb+opcode+ TX\_STATUS, die das entsprechende Element enthält. Diese
331 Antwort kann je nach Länge der Daten beim zugehörigen TX\_SETUP
332 unterschiedlich lang sein.
333 Die Nachrichtenlänge für den Befehl TX\_READ ist
334 \mbox{\tt \{[bcm\_msg\_head]\} } d.h. ein Nachrichtenkopf.
336 \subsection{TX\_SEND}
339 Zum einmaligen Senden einer CAN-Nachricht, ohne eine besondere
340 Funktionalität des \BCM\ zu nutzen, kann der \verb+opcode+ TX\_SEND genutzt
341 werden. Dabei wird eine Variable erzeugt, in der die
342 Komponenten \verb+can_id+, \verb+can_dlc+,
343 \verb+data[]+ mit den entsprechenden Werten gefüllt werden. Der \BCM\
344 sendet diese CAN-Botschaft unmittelbar auf dem durch den Socket
345 definierten CAN-Bus. Die Nachrichtenlänge für den Befehl TX\_SEND ist
346 \mbox{\tt \{[bcm\_msg\_head] [can\_frame]\} } d.h. ein Nachrichtenkopf und
347 genau ein CAN-Frame.\\
349 Anmerkung: Selbstverständlich können einzelne CAN-Botschaften auch mit
350 dem RAW-Socket versendet werden. Allerdings muss man dazu einen
351 RAW-Socket öffnen, was für eine einzelne CAN-Botschaft bei einem
352 bereits geöffneten \BC-Socket ein unverhältnismäßig großer
353 Programmieraufwand wäre.
356 \subsection{RX\_SETUP}
359 Mit RX\_SETUP wird für eine bestimmte CAN-ID ein Empfangsauftrag
360 eingerichtet oder geändert. Der \BCM\ kann bei der Filterung von
361 CAN-Nachrichten dieser CAN-ID nach verschiedenen Kriterien arbeiten
362 und bei Änderungen und/oder Timeouts eine entsprechende Nachricht an
363 den Prozess senden.\\
365 Analog zum \verb+opcode+ TX\_SETUP (siehe Seite \pageref{txsetup})
366 wird auch hier typischerweise eine Variable angelegt die der
367 Nachrichtenstruktur des \BCM\ entspricht.
368 Die Nachrichtenlänge für den Befehl RX\_SETUP ist
369 \mbox{\tt \{[bcm\_msg\_head] [can\_frame]+\} } d.h. ein Nachrichtenkopf und
370 mindestens ein CAN-Frame.\\
372 Im Unterschied zu TX\_SETUP haben die Komponenten der Struktur im
373 Rahmen der Empfangsfunktionalität zum Teil andere Bedeutungen, wenn
374 sie vom Prozess an den \BCM\ geschickt werden:
378 \item[count] keine Funktion
379 \item[ival1] Timeout für CAN-Nachrichtenempfang
380 \item[ival2] Drosselung von RX\_CHANGED Nachrichten
381 \item[can\_data] enthält eine Maske zum Filtern von Nutzdaten
385 \subsubsection{Timeoutüberwachung}
387 Wird vom \BCM\ eine CAN-Nachricht für einen längeren Zeitraum als
388 \verb+ival1+ nicht vom CAN-Bus empfangen, wird eine Nachricht mit dem
389 \verb+opcode+ RX\_TIMEOUT an den Prozess gesendet. Diese Nachricht
390 besteht nur aus einem Nachrichtenkopf (\verb+nframes+ = Null). Eine
391 Timeoutüberwachung wird in diesem Fall nicht neu gestartet.\\
393 Typischerweise wird die Timeroutüberwachung mit dem Empfang einer
394 CAN-Botschaft gestartet. Mit Setzen des Flags \verb+STARTTIMER+ kann
395 aber auch sofort beim RX\_SETUP mit dem Timeout begonnen werden. Das
396 Setzen des Flags \verb+RX_NO_AUTOTIMER+ unterbindet das automatische
397 Starten der Timeoutüberwachung beim Empfang einer CAN-Nachricht.\\
399 Hintergrund: Das automatische Starten der Timeoutüberwachung beim
400 Empfang einer Nachricht macht jeden auftretenden zyklischen Ausfall
401 einer CAN-Nachricht deutlich, ohne dass der Anwender aktiv werden muss.\\
403 Um ein Wiedereinsetzen des Zyklus' bei gleich bleibenden Nutzdaten
404 sicher zu erkennen kann das Flag \verb+RX_ANNOUNCE_RESUME+ gesetzt werden.
406 \subsubsection{Drosselung von RX\_CHANGED Nachrichten}
408 Auch bei einer aktivierten Filterung von Nutzdaten kann die
409 Benutzerapplikation bei der Bearbeitung von RX\_CHANGED Nachrichten
410 überfordert sein, wenn sich die Daten schnell ändern (z.B. Drehzahl).\\
412 Dazu kann der Timer \verb+ival2+ gesetzt werden, der den minimalen
413 Zeitraum beschreibt, in der aufeinanderfolgende RX\_CHANGED Nachrichten
414 für die jeweilige \verb+can_id+ vom \BCM\ gesendet werden dürfen.\\
416 Hinweis: Werden innerhalb der gesperrten Zeit weitere geänderte
417 CAN-Nachrichten empfangen, wird die letzt gültige nach Ablauf der
418 Sperrzeit mit einem RX\_CHANGED übertragen. Dabei können zwischenzeitliche
419 (z.B. alternierende) Zustandsübergänge verloren gehen.\\
421 Hinweis zu MUX-Nachrichten: Nach Ablauf der Sperrzeit werden alle
422 aufgetretenen RX\_CHANGED Nachrichten hintereinander an den Prozess
423 gesendet. D.h. für jeden MUX-Eintrag wird eine evtl. eingetretene
426 \subsubsection{Nachrichtenfilterung (Nutzdaten - simple)}
428 Analog der Übertragung der Nutzdaten bei TX\_SETUP (siehe Seite
429 \pageref{txsetup}) wird bei RX\_SETUP
430 eine Maske zur Filterung der eintreffenden Nutzdaten an den \BCM\
431 übergeben. Dabei wird vom \BCM\ zur Nachrichtenfilterung zunächst nur
432 der Nutzdatenteil (\verb+data[]+) der Struktur \verb+can_frame+
435 Ein gesetztes Bit in der Maske bedeutet dabei, das dieses
436 entsprechende Bit in der CAN-Nachricht auf eine Veränderung hin
439 Wenn in einer empfangenen CAN-Nachrichten eine Änderungen gegenüber der
440 letzten empfangenen Nachricht in einem der durch die Maske
441 spezifizierten Bits eintritt, wird die Nachricht RX\_CHANGED
442 mit dem empfangenen CAN-Frame an den Prozess gesendet.\\
443 Beim ersten Empfang einer Nachricht, wird das empfangene CAN-Frame
444 grundsätzlich an den Prozess gesendet - erst danach kann schließlich
445 auf eine {\it Änderung} geprüft werden. Tipp: Das Setzen der
446 Filtermaske auf Null bewirkt somit das einmalige Empfangen einer sonst
447 z.B. zyklischen Nachricht.
449 \subsubsection{Nachrichtenfilterung (Nutzdaten - Multiplex)}
451 Werden auf einer CAN-ID verschiedene, sich zyklisch wiederholende
452 Inhalte übertragen, spricht man von einer Multiplex-Nachricht. Dazu
453 wird beispielsweise im ersten Byte der Nutzdaten des CAN-Frames ein
454 MUX-Identifier eingetragen, der dann die folgenden Bytes in ihrer
455 Bedeutung definiert. Bsp.: Das erste Byte (Byte 0) hat den Wert \verb+0x02+
456 $\Rightarrow$ in den Bytes 1-7 ist die Zahl der zurückgelegten
457 Kilometer eingetragen. Das erste Byte (Byte 0) hat den Wert \verb+0x04+
458 $\Rightarrow$ in den Bytes 1-7 ist die Zahl der geleisteten
459 Betriebsstunden eingetragen. Usw.\\
461 Solche Multiplex-Nachrichten können mit dem \BCM\ gesendet werden, wenn
462 für das Aussenden über eine CAN-ID mehr als ein Nutzdatenframe
463 \verb+can_frame+ an den \BCM\ gesendet werden (siehe Seite
464 \pageref{txsendmux}).\\
466 Zur Filterung von Multiplex-Nachrichten werden mindestens zwei
467 (\verb+nframes+ $\geq$ 2) \verb+can_frame+'s an den \BCM\ gesendet,
468 wobei im ersten \verb+can_frame+ die MUX-Maske enthalten ist und in den
469 folgenden \verb+can_frame+('s) die Nutzdaten-Maske(n), wie oben
470 beschrieben. In die Nutzdaten-Masken sind an den Stellen, die die
471 MUX-Maske definiert hat, die MUX-Identifier eingetragen, anhand derer die
472 Nutzdaten unterschieden werden.\\
474 Für das obige Beispiel würde also gelten:\\
476 Das erste Byte im ersten \verb+can_frame+ (der MUX-Maske) wäre
477 \verb+0xFF+ - die folgenden 7 Bytes wären \verb+0x00+ - damit ist die
478 MUX-Maske definiert. Die beiden folgenden \verb+can_frame+'s enthalten
479 wenigstens in den jeweils ersten Bytes die \verb+0x02+
480 bzw. \verb+0x04+ wodurch die MUX-Identifier der
481 Multiplex-Nachrichten definiert sind. Zusätzlich können
482 (sinnvollerweise) in den Nutzdatenmasken noch weitere Bits gesetzt
483 sein, mit denen z.B. eine Änderung der Betriebsstundenzahl überwacht
488 \psfig{file=bcm_mux_filter.eps}
489 \caption{Beispiel für die Anwendung des Multiplexfilters}
490 \label{figure:bcm_mux_filter}
495 Eine Änderung einer Multiplex-Nachricht mit einem bestimmten
496 MUX-Identifier führt zu einer Nachricht RX\_CHANGED
497 mit genau dem einen empfangenen CAN-Frame an den Prozess. D.h. der
498 Prozess muss anhand des MUX-Identifiers die vom \BCM\ empfangene
499 Nachricht bewerten.\\
501 Im gezeigten Beispiel (Abbildung \ref{figure:bcm_mux_filter}) ist die
502 MUX-Maske im Byte 0 auf \verb+0x5F+
503 gesetzt. Beim Empfang von RX-Frame 1 wird keine Nachricht an den
504 Anwender geschickt (MUX-Identifier ist nicht bekannt). Bei RX-Frame 2
505 gibt es eine Nachricht (MUX-Identifier bekannt und relevante Daten
506 haben sich - beim ersten Empfangsvorgang - geändert). Beim Empfang von
507 RX-Frame 3 (Änderungen in den gelb markierten Bits) wird keine
508 Nachricht an den Anwender geschickt, weil sich
509 keine relevanten Daten für den eingetragenen MUX-Identifier geändert haben.
511 \subsubsection{Nachrichtenfilterung (Länge der Nutzdaten - DLC)}
513 Auf Anforderung kann der \BCM\ auch zusätzlich eine Veränderung der in den
514 CAN-Nachrichten angegebenen Nutzdatenlänge überwachen. Dazu wird der
515 empfangene Data Length Code (DLC) mit dem zu diesem CAN-Frame
516 passenden, bereits empfangenen DLC verglichen. Ein Unterschied führt
517 wie bei der Filterung der Nutzdaten zu einer Nachricht RX\_CHANGED an
518 den Prozess. Zum Aktivieren dieser Funktionalität muss in der
519 Komponente \verb+flags+ der Wert \verb+RX_CHECK_DLC+ gesetzt sein.
521 \subsubsection{Filterung nach CAN-ID}
523 Im Gegensatz zu den oben beschriebenen Nachrichtenfiltern besteht auch
524 die Möglichkeit nur nach der angegebenen CAN-ID zu filtern. Dazu wird
525 in der Komponente \verb+flags+ der Wert \verb+RX_FILTER_ID+
526 gesetzt. Die Komponente \verb+nframes+ kann dabei Null sein und
527 so werden folglich auch keine Nutzdaten (\verb+can_frame+'s) an den
528 \BCM\ geschickt. Angehängte Nutzdaten (d.h. \verb+nframes+ $>$ 0 und
529 entsprechende \verb+can_frame+'s) werden ignoriert. Werden
530 beim RX\_SETUP keine \verb+can_frames+ übertrags, ist also
531 \verb+nframes+ = 0, wird im \BCM\ automatisch das Flag
532 \verb+RX_FILTER_ID+ gesetzt.\\
534 Hinweis: Die Filterung nach CAN-IDs sollte nur bei nicht zyklischen
535 CAN-Nachrichten genutzt werden.
537 \subsubsection{Automatisches Beantworten von RTR-Frames}
540 Grundsätzlich können Remote-Transmission-Requests (RTR) mit dem \BCM\
541 ODER in einer Applikation im Userspace beantwortet werden. Im
542 Userspace würde eine Anwendung über den \BCM-Socket oder einen
543 RAW-Socket eine CAN-Nachricht empfangen, auf das gesetzte RTR-Bit
544 prüfen und entsprechend eine Antwort senden. Das RX\_SETUP könnte in
545 diesem Fall beispielsweise so aussehen:
548 /* normal receiption of RTR-frames in Userspace */
549 txmsg.msg_head.opcode = RX_SETUP;
550 txmsg.msg_head.can_id = 0x123 | CAN_RTR_FLAG;
551 txmsg.msg_head.flags = RX_FILTER_ID;
552 txmsg.msg_head.ival1.tv_sec = 0;
553 txmsg.msg_head.ival1.tv_usec = 0;
554 txmsg.msg_head.ival2.tv_sec = 0;
555 txmsg.msg_head.ival2.tv_usec = 0;
556 txmsg.msg_head.nframes = 0;
558 if (write(s, &txmsg, sizeof(txmsg)) < 0)
562 Diese Aufgabe kann auch der \BCM\ übernehmen, indem man beim RX\_SETUP
563 statt eines Filters die auszusendende Nachricht angibt und das Flag
564 \verb+RX_RTR_FRAME+ setzt:
567 /* specify CAN-Frame to send as reply to a RTR-request */
568 txmsg.msg_head.opcode = RX_SETUP;
569 txmsg.msg_head.can_id = 0x123 | CAN_RTR_FLAG;
570 txmsg.msg_head.flags = RX_RTR_FRAME; /* | TX_CP_CAN_ID */;
571 txmsg.msg_head.ival1.tv_sec = 0; /* no timers in RTR-mode */
572 txmsg.msg_head.ival1.tv_usec = 0;
573 txmsg.msg_head.ival2.tv_sec = 0;
574 txmsg.msg_head.ival2.tv_usec = 0;
575 txmsg.msg_head.nframes = 1; /* exact 1 */
577 /* the frame to send as reply ... */
578 txmsg.frame.can_id = 0x123; /* 'should' be the same */
579 txmsg.frame.can_dlc = 4;
580 txmsg.frame.data[0] = 0x12;
581 txmsg.frame.data[1] = 0x34;
582 txmsg.frame.data[2] = 0x56;
583 txmsg.frame.data[3] = 0x78;
585 if (write(s, &txmsg, sizeof(txmsg)) < 0)
589 Beim Empfang einer CAN-Nachricht mit der CAN-ID 0x123 und gesetztem
590 RTR-Bit wird das \verb+can_frame txmsg.frame+ ausgesendet. Bei
591 gesetztem Flag \verb+TX_CP_CAN_ID+ wird die Zeile mit
592 \verb+txmsg.frame.can_id+ obsolet. Der Wert \verb+txmsg.frame.can_id+
593 ist nicht beschränkt,
594 d.h. der \BCM\ könnte auf ein RTR-Frame mit der CAN-ID 0x123 auch mit
595 einer CAN-Nachricht mit einer anderen CAN-ID (z.B. 0x42)
596 antworten. Achtung Denksportaufgabe: Bei gleicher CAN-ID und einem
597 gesetzten RTR-Flag im \verb+can_frame txmsg.frame+ erfolgt ein
598 Vollast-Test. Aus diesem Grunde wird bei Gleichheit von
599 \verb+txmsg.msg_head.can_id+ und \verb+txmsg.frame.can_id+ (z.B. bei
600 Anwendung der Option \verb+TX_CP_CAN_ID+) das RTR-Flag in
601 \verb+txmsg.frame.can_id+ beim RX\_SETUP automatisch gelöscht.
603 Die bei einem RTR-Frame auszusendende Nachricht kann durch ein erneutes
604 RX\_SETUP mit der identischen CAN-ID (mit gesetztem Flag
605 \verb+RX_RTR_FRAME+) jederzeit aktualisiert werden. Die
606 Nachrichtenlänge für den Befehl RX\_SETUP mit gesetztem Flag
607 \verb+RX_RTR_FRAME+ ist \mbox{\tt \{[bcm\_msg\_head] [can\_frame]\} }
608 d.h. ein Nachrichtenkopf und genau ein CAN-Frame.\\
610 \subsection{RX\_DELETE}
613 Mit RX\_DELETE wird für eine bestimmte CAN-ID ein Empfangsauftrag
614 gelöscht. Die angegebene CAN-ID wird vom \BCM\ nicht mehr vom CAN-Bus
616 Die Nachrichtenlänge für den Befehl RX\_DELETE ist
617 \mbox{\tt \{[bcm\_msg\_head]\} } d.h. ein Nachrichtenkopf.
619 \subsection{RX\_READ}
622 Mit RX\_READ kann der aktuelle Zustand des Filters für
623 CAN-Frames mit der angegebenen CAN-ID ausgelesen werden. Der
624 Broadcast-Manager antwortet mit der Nachricht RX\_STATUS
625 an den Prozess. Diese
626 Antwort kann je nach Länge der Daten beim zugehörigen RX\_SETUP
627 unterschiedlich lang sein.
628 Die Nachrichtenlänge für den Befehl RX\_READ ist
629 \mbox{\tt \{[bcm\_msg\_head]\} } d.h. ein Nachrichtenkopf.
631 \subsection{Weitere Anmerkungen zum Broadcast-Manager}
636 \item Die Nachrichten TX\_EXPIRED, RX\_TIMEOUT vom \BCM\ an den Prozess
637 enthalten keine Nutzdaten (\verb+nframes+ = 0)
639 \item Die Nachrichten TX\_STATUS, RX\_STATUS vom \BCM\ an den Prozess
640 enthalten genau so viele Nutzdaten, wie vom Prozess bei der
641 Einrichtung des Sende-/Empfangsauftrags mit TX\_SETUP bzw. RX\_SETUP
642 an den \BCM\ geschickt wurden.
644 \item Die Nachricht RX\_CHANGED vom \BCM\ an den Prozess
645 enthält genau das vom CAN empfangene, geänderte Nutzdaten-Frame
648 \item Beim Ändern von zu sendenden Multiplex-Nachrichten (TX\_SETUP)
649 müssen immer alle Nutzdaten-Frames übertragen werden. Es wird generell
650 mit der Aussendung der ersten MUX-Nachricht begonnen.
652 \item Die Komponente \verb+can_id+ in der Struktur \verb+bcm_msg_head+
653 kann {\it sendeseitig} auch als 'Handle' betrachtet werden, weil bei der
654 Aussendung von CAN-Nachrichten die beim TX\_SETUP mit übertragenen
655 \verb+can_frame+'s gesendet werden. Das Setzen jeder einzelnen
656 \verb+can_id+ in den \verb+can_frame+'s kann durch das Flag
657 \verb+TX_CP_CAN_ID+ vereinfacht werden.
659 \item Beim Auslesen der Sende-/Empfangsaufträge mit TX\_READ
660 bzw. RX\_READ können folgende Werte in den Antworten TX\_STATUS bzw.
661 RX\_STATUS von der ursprünglich gesendeten Nachricht abweichen:
664 \item[count] Entspricht dem aktuellen Wert
665 \item[SETTIMER] Wurde ausgeführt und damit konsumiert
666 \item[STARTTIMER] Wurde ausgeführt und damit konsumiert
667 \item[TX\_ANNOUNCE] Wurde ausgeführt und damit konsumiert
671 \item Das Schließen des \BC-Sockets mit \man{close}{2} bzw. das
672 Terminieren des Anwenderprozesses löscht alle Konfigurationseinträge
673 der zugehörigen \BC-Instanz. Zyklische Aussendungen dieser \BC-Instanz
674 werden folglich sofort beendet.
679 \subsection{Testprogramme}
682 \item[tst-bcm-single] führt eine einzelne TX\_SEND-Operation aus.
683 \item[tst-bcm-cycle] Zyklisches Aussenden einer CAN-Botschaft mit
684 TX\_SETUP und beenden der zyklischen Aussendung mit
685 TX\_SETUP (ohne TX\_DELETE).
686 \item[tst-bcm-tx\_read] Funktionsprüfung der Debug-Möglichkeit mit TX\_READ.
687 \item[tst-bcm-rtr] Beispiel für die Anwendung des Flags \verb+RX_RTR_FRAME+.
688 \item[tst-bcm-filter] diverse Filtertests inklusive Multiplex-Filter.
689 \item[tst-bcm-throttle] Funktionsprüfung der Throttle-Funktionalität (Update-Bremse).
690 \item[can-sniffer] ist ein Programm zur Beobachtung dynamischer
691 Dateninhalte in zyklischen CAN-Nachrichten. Änderungen können in
692 hexadezimaler, binärer oder in ASCII-Darstellung farblich
693 hervorgehoben werden. Filter können zur Laufzeit verändert und
694 gespeichert bzw. geladen werden.Wird \verb+can-sniffer+ ohne Parameter
695 aufgerufen, erscheint ein Hilfetext.