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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.