Situation:
fremdes CAN-Netz, 2 (!) Adressen zugeteilt bekommen.
Die eine wird für die eigentliche Funktion benötigt, über die andere
will ich Parametrierdaten schicken und ggf. ändern.
Beisp:
ID=0x720 Prozessdaten (20ms)
ID=0x721 eingestellte Parameter, kommt nur einmal/s
Und nun die eigentliche Frage: Was passiert, wenn ich von einem
PC-Dongle einen frame mit ID=0x721 schicke? Die Daten würden dann im
EEPROM gespeichert.
Spricht irgendwas dagegen?
Es wäre nicht unbedingt nötig, dass die Daten auch im laufenden Betrieb
angezeigt/geändert werden können (habe noch andere Schnittstellen), wäre
aber schöner und bequemer.
Den einzigen Problemfall, den ich mir im Moment vorstellen kann, dass
beide exakt im gleichen Moment mit gleicher ID versuchen zu senden, das
kann man praktisch aber ausschliessen, da vom Gerät wie gesagt nur 1/s
gesendet wird, vom PC aus überhaupt nur einmal.
MCP2515 + ATMega32.
Alle Kontras willkommen!
Hi,
verstehe ich das richtig, dass Du 2 Datenquellen hast, die Nachrichten
mit der selben ID verschicken wollen? Das wäre ungut!
Versuche mal eine dritte dritte ID zu bekommen, etwa so:
0x720 Prozessdaten
0x721 eingestellte Parameter (Report)
0x722 einzustellende Parameter (Setup vom PC)
Wenn das nicht geht, brauchst Du irgendeine Form von Protokoll (und
wenn's nur ist jeweils eine Parameter-Nachricht vom Gerät abzuwarten und
gleich danach versuchen die Nachricht vom PC abzusetzen - mit Timeout,
damit man den Versuch bei vollem Bus ggf. abbricht, bevor man mit der
nächsten Nachricht vom Gerät kollidiert).
Irgendwie sehe ich das Problem nicht ganz:
Du hast 2 CAN-IDs. Auf der einen werden dir Prozessdaten geschickt und
die andere wird dafür verwendet, Parameter deines Gerätes zu ändern.
Es ist egal, woher ein CAN-Frame mit deinen IDs kommt.
Wenn dein Controller auf die beiden IDs reagiert (sie herausfiltert und
für sich als gültig befindet), dann ist die Quelle für ihn
uninteressant.
Die wird im CAN-Frame ja auch gar nicht mitübertragen.
Wenn dein Controller jetzt selber etwas an diese ID schickt, müsste er
es meiner Meinung auch selbst empfangen (Datenblatt...).
Wo siehst du denn das Problem?
IDs im CAN-Bus sollten nur für eine Funktion verwendet werden. Diese
kann aber auch von mehreren Controllern empfangen und ausgewertet werden
(CAN-Sniffer sind meist sehr passiv...).
@Stefan: nein, ich bekomme keine weiteren IDs. Und dass es dann jenseits
aller Sorgen wäre, ist mir auch klar. Aber nicht immer bekommt man
alles, was man sich wünschst...
@Rahul:
mein Gerät SENDET auf ID 0x720 seine Sensordaten und auf 0x721
Parametrierdaten (Offset, Steilheit, Entprellzeit etc), darauf könnte
ich zur Not auch verzichten, schöner wärs aber, wenn ich die im
Einricht/Servicefall alle sehen könnte.
Selbst geschickte Frames werden zwar vom Transceiver empfangen und auch
vom CAN-Controller ausgewertet, ob korrekt auf dem Bus, aber nicht als
empfangene Botschaft an den MC weitergeleitet, oder (?). Habe mich
jedenfalls noch nie aktiv darum gekümmert, gesendete Botschaften aus dem
Empfangsbuffer zu lesen.
Die Information auf 0x721 wird von niemand anders ausgewertet. Und
selbst wenn - es sind ja auch korrekte Daten. Ab dem Zeitpunkt, wo sie
von extern eingespielt werden, sind es ja auch automatisch aktuelle
Betriebswerte vom node. Ich sehe einfach keine anderen Probleme ausser
einem extrem unwahrscheinlichen gleichzeitigen Zugriff.
Ich glaube, ich probier es einfach mal aus.
Es müsste eigendlich funktionieren, da der CAN ja Low als dominanten
Pegel kennt. Das zwei Sender nicht die gleiche ID benutzen drüfen ist
deshalb festgelegt, damit einer im Fall des gleichzeitigen Sendens
bereits beim Senden der ID mitbekommt, dass ein zweiter ebenfalls
sendet. Im Datenteil sollte das nicht passieren, da dann möglicherweise
keiner von beiden mehr abbricht. Im schlimmsten Fall stimmt dann aber
die Checksumme nicht und die Nachricht wird verworfen, denke ich mal.
Was ein Problem sein könnte ist, dass einige CAN-Controller auf ihre
eigene ID warten, (Remote-Request) um zu senden. Wie sich der Controller
aber verhält, wenn er eine Nachricht seiner ID detektiert bei der das
R.-R.-Bit nicht gesetzt ist, weiß ich nicht.
Wenn der zuletzt genannte Fall kein Problem darstellt und das
gleichzeitige Senden unwahrscheinlich ist, ist es zumindest einen
Versuch wert.
Henrik
Konflikt jenseits der ID müsste wohl zu einem Error-Frame führen. Bei
hinreichend Retries mit exakt gleichem Timing kann das dann bis zu
"error passive" so weitergehen. Theoretisch.
allenfalls könnte es ja in dem Moment was passieren, wenn ich mit dem PC
am Bus bin und Daten verschicke. Und dann sehe ich ja auch im
receive-Fenster, ob der unwahrscheinliche Fall eines Aufhängers
eintritt (ich glaube, eher habe ich einen Sechser im Lotto durch
Versehen der Lottogesellschaft, da ich gar nicht spiele).
Also, wie gesagt, prinzipiell funktionierts, der CAN-Controller merkt
gar nichts davon, dass ich auf einer Sende-ID auch empfange.
