Rolle des SSR-Bit beim CAN-BUS

Technik Elektronik & Elektrotechnik
#1

Hallo,

ich habe bei meiner Recherche schon 100mal den von einander abgeschriebenen Satz gelesen:

Beim Extended Frame wird das RTR Bit [des 11-Bit Standard Frames] durch das SSR Bit ersetzt, darauf folgt das IDE Bit und der Rest des 29-Bit ID, an den dann das RTR Bit angehängt wird.

Mir geht es um die Bedeutung (also die Funktion) des SSR/RTR-Bits bei extended Frames). [Die Bedeutung des RTR-Bit bei Standerd Frames ist mir völlig klar und keine Frage!]

Bedeutet dieser ominöse Satz, dass das SSR-Bit an der Stelle zu finden ist, an der bei CAN2.0A Frames das RTR-Bit zu finden ist (das nehme ich an) - oder, dass das SSR die Rolle vom RTR übernimmt (was ich mir kaum vorstellen kann)?

[Sorry für die blöde Frage, aber für mich hat nun mal ein Satz i.d.R. eine eindeutige Bedeutung, dieser aber nicht.]

Dies war die Präambel, das ist meine Frage:

Warum benötigt man bei CAN2.0B ein zusätzliches Bit?

Unter der Voraussetzung, dass das SSR ein neues Bit ist (also nicht das für den Arbitrierungsprozess noch vorne geschobene RTR sondern eines mit einer neuen zusätzlichen Funktion), kann ich mir zwei Funktionen vorstellen:

  • Leitungstechnisch - damit das IDE Bit von den vorangehenden ersten 11 ID Bits getrennt werden kann.

  • Kompatibilitätsgründe, damit alte und dumme CAN Controller nicht gleich losfeuern, wenn sie das 12te Bit als RTR interpretieren.

Ich habe aber keine Ahnung, wie Nahe ich da liege und ob ich überhaupt richtig liege.

Zusatzfrage:
Es sieht so aus, als könne man das SSR Bit setzen oder auch nicht!?!
Warum um Himmels Willen? Ich nehme einmal an, dass man bei einem Generischen CAN Treiber die Global Mask an der Stelle wo das SSR ist auf don’t care setzen sollte. Dann können die Knoten es unter sich ausmachen, ob sie SSR-Gegner, -Freunde oder -Ignoranten sein wollen.

Gruß und Danke für eine etwaige Unterstützung.

#2

Na ja, wenn keine Antwort kommt, muss iche es mir selbst beantworten:

Vielleicht wurde das SSR Bit nur deswegen eingeführt, um den besagten ominösen Satz aufstellen und verbreiten zu können.

#3

Rolle des SRR-Bit beim CAN-BUS
Wenn man die Sache richtig bei Google eintippt („SRR“ statt „SSR“, s. geänderten Titel), findet man auch weniger ominöse Sätze, die die Bedeutung des SRR-Bits erklären. Für den, den es interessiert:

Das SSR-Bit gibt es nicht im CAN Frame, das ist ein Schreibfehler (meinerseits und auch andererseits).

Das SRR-Bit ermöglicht es, die Priorität unter Standard-Frames und Extended-Frames, die sich in den ersten 11 ID-Bits nicht unterscheiden, zu regeln; also STD über EXT bzw. EXT über STD.

#4

ich bin ein frischling und interessiere mich auch für die Antwort. Bin mal gespannt, ob die Leiche hier wieder reaktiviert wird.

Das RTR Bit wird nicht ersetzt, es wird verschoben, im Extented Format hinter den Indentifier.

Da das SRR & der IDE im Fall der Extented Frame rezessiv sind, könnte das die Ankündigung der 29 bit Identifier unterstützen.

Aber warum dann der RTR nach dem Indifier kommt, macht dann auch wenig Sinn, da der Inhalt der Botschaft ja schon im Identifier übermittelt wurde und somit schon geklärt sein sollte, hab ich eine Daten übermittelt oder wünsche ich Daten zu empfangen.

#5

Hi!

Der Inhalt der Botschaft setzt sich aus einer ID und den eigentlichen Daten zusammen. Statt für einen Request ne eigene ID zu nutzten, nimmt man die gleiche ID, unter der man die Daten auch zu empfangen wünscht, und markiert das per RTR eben als Anfrage. Dann wird auch sofort erkannt, dass keine weiteren Daten in dem Frame kommen.

Und wie in der anderen Antwort schon geschrieben, daß IDE-Bit definiert, ob es ein Extended- oder Standard-Frame ist. Das SRR ist erstmal nur ein Füllbit, kann aber zur Priorisierung genutzt werden. Du weißt, jeder Sender muss gleichzeitig lauschen, und wenn statt einem gesendeten rezessiven Bit ein dominantes erkannt wird, muss der Sender sofort die Klappe halten, denn offensichtlich sendet da noch wer, und der hat Priorität.