3.5 CAN-Identifier

Es gibt im Prinzipiellen zwei Möglichkeiten, den CAN-Identifier zu nutzen: Eine Identifikation der Nachricht oder die Identifikation des Empfängers. CAN sieht eigentlich eine Identifikation der Nachtricht vor, diese Identifikation wird durch Spezial-Telegramme (RTR-Bit^3.1) unterstützt. Anhand des Identifiers der Nachricht entscheiden die CAN-Knoten im Netz selber, ob die empfangene Nachricht für sie relevant ist, oder nicht. Dafür muß natürlich der Prozessor aktiv sein. Wenn man sich aber vor Augen führt, daß die meisten verschickten Nachrichten nur für einen einzigen Roboter sind (Kommunikation zwischen exakt zwei Robotern), führt diese Daueraktivität der anderen Prozessoren zu einem unnötig hohen Energieverbrauch, und genau den gilt es bei einem autonomen System so gering wie möglich zu halten. Daher wurde bei dieser Arbeit ein Teil des Identifiers den Robotern zugeordnet, genau der Teil, der durch die Acceptance Mask (siehe Abschnitt 2.2) ausgefiltert wird. Damit sind die CAN-Protokolle nicht mehr nachrichten- sondern empfängerorientiert, da jedes CAN-Telegramm nur noch exakt einen Empfänger hat^3.2.

Es wird jetzt also jede Nachricht mit der ID^3.3 des Empfängers versehen. Dies verbietet dann leider Broadcasts, d.h. Nachrichten an alle Roboter - zumindest direkte - und zwar aus folgendem Grund: Wenn es möglich sein soll, nur einem Roboter gezielt ein CAN-Telegramm zu schicken, so muß ein Teil des Identifiers die Adresse des Roboters enthalten und das IR-Modul nur Nachrichten mit dieser ID selektieren. Das bedeutet aber auch, daß alle anderen Telegramme nicht weiter betrachtet werden, weil sie eben nicht die richtige ID eingetragen haben. Wenn ein Roboter also eine Nachricht an alle senden möchte, muß dies softwaremäßig geschehen, d.h. die Nachricht muß an jeden verfügbaren Roboter einzeln geschickt werden.

Der CAN-Identifier ist, wie beschrieben, in unserem Fall 11 Bit lang. Für 32 Adressen^3.4 werden davon 5 Bit benötigt. Um zu unterscheiden, ob eine Nachricht für den K-Bus oder die serielle Schnittstelle vorgesehen ist, wird ein weiteres Bit benötigt. In die verbleibenden 5 Bit paßt exakt die Absender-ID hinein; damit ist auch diese in jedem CAN-Telegramm enthalten, ohne zusätzlichen Speicherplatz zu benötigen. Weiterhin sind durch diese Wahl wirklich alle Identifier eindeutig.

Es ist wünschenswert, daß der Master-Knoten eine höhere Priorität hat, als die Roboter-Knoten, da er die Kommunikation über die serielle Schnittstelle ermöglicht und diese zeitkritisch ist^3.5. Um dies zu erreichen müßte der Master-Knoten die minimale ID=0 (00000) besitzen^3.6 und die Absender-ID ganz am Anfang gesendet werden. Leider sind Filter- und Vergleichsmaske nur 8 Bit lang, so daß die 5 Bit lange Absenderadresse nicht komplett vor den Empfänger paßt (dieser muß innerhalb der ersten 8 Bit liegen, um gefiltert werden zu können). Immerhin - drei der fünf Bit passen davor, die übrigen zwei kommen dann dahinter. Die niedrigste Adresse, die somit dem Master garantiert noch Priorität einräumen würde, wäre dann 00100, oder dezimal 4. Also gibt es nur 3 Adressen außer der Master-Adresse 00000, bei denen die Priorität nicht vom Absender, sondern vom Empfänger abhängt - dieses stellt bei 32 möglichen Adressen folglich kein Problem dar.

    

Mit Ziel ist hier gemeint, ob die Nachricht für den K-Bus oder die serielle Schnittstelle vorgesehen ist.