Can Controller "SJA1000" Remote Betrieb???

hab jetzt grad kein Code da, aber ich umschreibe es mal: Damit RTR
funktioniert musst du das Design des CAN Busses so machen, wie ich es
dir in der letzen Message zum SJA1000 geschrieben habe.
So und nu Butter bei die Fische:
Soll Sensor mit der ID 0b00000000001 (bei CAN gibt man jedem Sensor und
jedem anderen Bauteil ne eigene ID, ein uC mit einem SJA1000 dran
verwaltet also ne ganze Reihe von IDs, z.B. für jeden A/D Port eine
eigene ID) seinen Wert auf den Bus werfen, dann musst Du folgende
Message von deinem Controller der die Info anfordert senden:

Ziel_ID + RTR_Bit + Message_Length

An CAN Adresse 10 und 11 des SJA1000 im Basic CAN Mode müssen also
folgende Dinge geschrieben werden:
10: ID.10 ... ID.3
Also für die ID 0b00000000001 wären das 0b00000000

11: ID.2 ... ID.0 + RTR + DLC.3 ... DLC.0

Restliche 3 Bit der ID: 0b000XXXXX + RTR 0b0001XXXX + DLC 0bXXXX0000
Also würdest du an Adresse 11: 0b00010000 schreiben.

Wenn Du das jetzt sendest, sollte der Sensor oder was auch immer die ID
0b00000000001 hat daraufhin seine Informationen auf den Bus senen.

sorry die "restlichen 3 Bit der Id" sind natürlich 0b001XXXXX also
würdest du an Adresse 11 0b00110000 schreiben

Danke für die Info!

Irgendwie ist es mir immer noch nicht 100% klar.
Wenn ich das jetzt so verstehe:
Auf dem CAN Bus sind jetzt z.B. 10 Nachrichten wo jeweil das RTR Bit
auf eins steht.
Jetzt will ich gezielt eine Botschaft empfangen, dann muss ich
doch beim empfangen das RTR Bit auch auf ein setzten oder???

verstehe nicht, was Du meinst. Beim Empfangen musst Du gar nix setzen,
weil Du empfängst ja eben was. In der empfangenen Message ist natürlich
das RTR Bit auch gesetzt (hast Du ja auch beim Senden gesetzt), sonst
könntest Du ja nicht unterscheiden, ob es sich nur um eine "normale"
Message ohne Datenbytes handelt oder halt um eine RTR Message (die ja
per Definition keine Datenbytes haben).
Wie viele Nachrichten das nun sind, ist doch egal. Oder wie meinst Du
das? Ich kann leider deinen Satz auf 2 Arten verstehen:
1. Es ist 10x die selbe Message auf dem Bus, d.h. ID ist jedesmal
gleich. Dann empfängst du halt 10x das selbe auf deinem "Ziel". Das
musst Du auf jedenfall in deiner Software abfangen, oder halt stupide
10x antworten ;-)
2. 10 unterschiedliche Messages für z.B. 10 unterschiedliche Sensoren,
d.h auch 10 verschiedene IDs mit jeweils dem RTR Bit gesetzt. Wenn Du
gezielt z.B. nur Nachrichten mit bestimmten IDs empfangen willst,
kannst Du die mit dem Acceptance Mask Register "filtern". Es kommen
nur die durch, auf die das Bitmuster (mit Acceptance Code zusammen) im
Acceptance Mask Register passt. Ich allerdinge filtere ausschliesslich
in Software, d.h. ich lasse meinen CAN Controller alles empfangen und
werfe dann im Programm das weg, was mich nicht interessiert.

Ist es jetzt klarer?

Ach so jetzt kappiere ich es erst richtig.
Das heisst beim Senden ist das RTR Bit auf EINS.
Und wenn ich empfangen will, dann muss ich nur das RTR Bit auf EINS
setzen.
Das bedeutet beim Empfangen der Nachricht muss ich nur das RTR Bit
senden. Dann kann ich auch die Nachricht empfangen.

Mich stört, daß Du redest das Du beim Empfangen was setzen willst. Wie
soll das gehen? Beim Empfangen kannst Du nix setzen, der Controller
präsentiert dir das, was er von der Busleitung empfangen hat.
Du musst nix Spezielles einstellen auf dem Controller der RTR Messages
empfangen soll. Diese Nachrichten werden genauso empfangen wie normale.
Nur halt das Du dann in deiner Software bei der Headerauswertung
entdeckst, daß das RTR Bit im Header der empfangenen Message gesetzt
ist.

Ok. Ich muss nur im Empfangspuffer nachschauen ob das RTR Bit gesetzt
ist oder nicht.
Und angenommen es ist gesetzt, wie geht es da dann weiter.

Ja dann kommst Du dem Remote Transmission Request nach. Du sendest dann
eine ganz normale Message unter der angeforderten ID mit den
entsprechenden Datenbytes.

Bsp:
Du hast nen Temp-Sensor mit der ID "ABC" (geht natürlich nicht, denk
dir nen Binärwert). Irgendein Controller in deinem Netzwerk benötigt
jetzt den Temperaturwert dieses Sensors für irgendeine Aufgabe. Also
sendet er eine Msg mit der ID "ABC" und dem RTR Bit gesetzt.
Der Controller an dem der Sensor ABC angeschlossen ist empfängt die Msg
und erkennt das da das RTR Bit gesetzt ist und sendet daraufhin eine
normale Msg mit der ID ABC und den angeforderten Daten zurück - in
diesem Fall wohl der Sensorwert.

Leo, BITTE bitte lies dir mal ne Beschreibung zu CAN durch.
www.can-cia.de hat da einige recht gut gemachte Info-PDFs auf ihrem
Server. Mir kommt es vor, als wüsstest du nicht wozu die RTR-Frames
gedacht sind, willst sie aber mit aller Gewalt einsetzen...
Was willst du mit den Remote-Frames bezwecken? (<-- Wenn du diese Frage
beantworten kannst, dann dürften alle deine weiteren Fragen zu CAN +
Remoteframes geklärt sein!)

----, (QuadDash).

Super danke QuadDash. Leider bin ich nicht so fit in Englisch.

Ok, denn nehme ich meine rhetorische Frage von oben:
> Was willst du mit den Remote-Frames bezwecken?
zurück und stelle Sie diesmal konkret. Also:

 Was willst du mit den Remote-Frames erreichen?

(Ergänzung zu LtDatas Beitrag:)
RemoteFrames werden als "Lockmittel" benutzt, um den CAN-Knoten der
zu dieser CAN-ID die Daten liefert/sendet, dazu zu bringen die Daten
jetzt auf den Bus zu senden. Überschneiden sich das Remote-frame (zu
einer bestimmten CanId) mit dieser CanId (während der
Arbitrierungsphase), so verliert das Remote-Frame den Buszugriff und
die eigentlichen Daten (also CanMsg ohne RTR-Bit) landen auf dem Bus.
Genau das war ja auch die Absicht des Remoteframes.

Je nach CAN-Controller kann der Knoten, dessen Empfangsfilter auf die
CanId des eben gesendeten Remoteframes eingestellt ist, ohne Zutun der
Software die Daten aus den vorbereiteten Sendepuffer verschicken (ob
das der SJA1000 auch kann? - kA).

----, (QuadDash).

@QuadDash:
Automatisch verschicken kann der sja1000 meines Wissens nicht.