die datenschleuder. - Chaosradio - CCC
die datenschleuder. - Chaosradio - CCC
die datenschleuder. - Chaosradio - CCC
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
TANK AN G-G-G-GROSSHIRN, TANK AN GROSSHIRN<br />
Historisch gewachsen gibt es zwei unterschiedliche<br />
Implementierungen des CAN 2.0 Standards: FullCAN<br />
und BasicCAN. Sie unterscheiden sich vor allem <strong>die</strong><br />
Empfangsfilter betreffend. BasicCAN verwendet eine<br />
Maske und einen Code. Die Maske gibt an, welche<br />
Bits des Identifiers signifikant für <strong>die</strong> Filterung sind. Der<br />
Code gibt an, welchen Wert <strong>die</strong> einzelnen Bits haben<br />
müssen. Nur wenn alle signifikanten Bits den Wert der<br />
Codebits haben wird <strong>die</strong> Nachricht akzeptiert. Da man<br />
mit jedem Bit, das man als nicht-signifkant definiert,<br />
zwei neue Identifier durch den Filter lässt, kann man in<br />
vielen Fällen nicht engmaschig genug filtern und muss<br />
softwaremäßig nacharbeiten. Das beansprucht aber<br />
zusätzliche Prozessorzeit. FullCAN kennt keine Masken.<br />
Vielmehr gibt es mehrere Empfangspuffer, für <strong>die</strong><br />
jeweils ein Code angegeben werden kann. Ein soft-<br />
waremäßiges Nachfiltern entfällt damit. Allerdings ist<br />
<strong>die</strong> maximale Anzahl der Nachrichten, <strong>die</strong> man empfangen<br />
kann, durch <strong>die</strong> Anzahl der Empfangspuffer<br />
beschränkt. Mittlerweile gibt es CAN Chips, <strong>die</strong> beide<br />
Arten und auch neuere Techniken der Filterung beherrschen,<br />
so dass <strong>die</strong> irreführenden Begriffe FullCAN und<br />
BasicCAN veraltet sind.<br />
Ein Design Ziel von CAN war es, dass möglichst viele<br />
Fehler bereits von der Hardware erkannt und behandelt<br />
werden. Damit spart man Rechenleistung in den<br />
CPUs und aufwändige Protokolle in höheren Layern.<br />
Zwei der fünf möglichen Fehler können vom Sender<br />
entdeckt werden. Das erste ist ein Bitfehler. Dieser<br />
liegt vor, wenn außerhalb der Arbitrierungsphase<br />
und des ACK Slots das gelesene Bit nicht mit dem<br />
geschriebenen übereinstimmt. Das zweite ist ein Acknowledge<br />
Fehler. Dieser liegt vor, wenn der Sender<br />
im ACK Slot keine 0 liest. Die restlichen drei möglichen<br />
Fehler können von den Empfängern erkannt werden.<br />
Zuerst kann ein Knoten eine Verletzung der Bit<br />
Stuffing Regel erkennen. Geschieht das außerhalb des<br />
EOF Feldes, so ist das offensichtlich ein Empfangsfehler.<br />
Außerdem kann ein Teilnehmer feststellen, dass<br />
<strong>die</strong> berechnete Prüfsumme nicht mit der Empfangenen<br />
übereinstimmt. Zuletzt kann eine allgemeine Ver-<br />
26 26<br />
#83 / 2004<br />
letzung des Nachrichten Formats erkannt werden. Das<br />
geschieht z.B. wenn <strong>die</strong> 6 rezessiven Bits des EOF ausbleiben<br />
oder auch, wenn ein Teilnehmer standard Frames<br />
erwartet, aber extended Frames empfängt. In<br />
jedem der fünf Fehlerfälle kommt es zur selben Fehlerbehandlung.<br />
Derjenige, der einen Fehler erkannt hat,<br />
sendet ein Error Frame auf den Bus, um alle anderen<br />
von dem Fehler in Kenntnis zu sezten. Das Error Frame<br />
besteht aus 6 dominanten Bits und überschreibt somit<br />
alles andere auf dem Bus. Auch hier wird absichtlich<br />
<strong>die</strong> Bit Stuffing Regel verletzt, um das Signal eindeutig<br />
erkennbar zu machen. Wenn ein Knoten selber keinen<br />
Fehler erkennt, aber ein Error Frame empfängt, so reagiert<br />
er auf <strong>die</strong> vermeintliche Verletzung der Bit Stuffing<br />
Regel mit dem Senden eines Error Frames. Das<br />
bedeutet zwar, dass ein Error Frame auf bis zu 12 Bits<br />
anwachsen kann, hat aber den Vorteil, dass jeder Busteilnehmer<br />
ein Error Frame sendet und damit im Fehlerzustand<br />
ist. Da jeder Teilnehmer im Fehlerfall <strong>die</strong><br />
empfangene Nachricht verwirft, wird somit garantiert,<br />
dass eine CAN Nachricht entweder von allen oder von<br />
keinem angenommen wird. Das ist sehr wichtig für <strong>die</strong><br />
Synchronisation der Busteilnehmer. Nach dem Error<br />
Frame wird <strong>die</strong> Nachricht einfach erneut gesendet.<br />
Hat ein Knoten einen permanenten Fehler, wie z.B.<br />
einen defekten Eingang, so würde er den kompletten<br />
Bus ständig mit Error Frames beschreiben und<br />
somit lahm legen. Um das zu verhindern, hat man eine<br />
Selbstdiagnose der Busteilnehmer spezifiziert. Jeder<br />
CAN Baustein besitzt zwei Error Counter, einen für<br />
den Empfang (REC) und einen für das Senden (TEC).<br />
Kommt es zu Fehlern, so werden <strong>die</strong>se Zähler incrementiert.<br />
Wenn <strong>die</strong> Fehler wieder ausbleiben, so werden<br />
<strong>die</strong> Zähler mit der Zeit wieder decrementiert.<br />
Überschreitet einer der beiden Zähler eine Schwelle, so<br />
verhält sich der Teilnehmer Error Passive. Das bedeutet,<br />
dass er zwar ganz normal am Busgeschehen teilnimmt,<br />
aber im Fehlerfall nur noch passive Error Frames<br />
sendet. Diese bestehen aus 6 rezessiven Bits und<br />
stören damit den restlichen Bus nicht. Überschreitet<br />
der TEC eine zweite Schwelle, so geht der Baustein Bus<br />
<strong>die</strong> <strong>datenschleuder</strong>