Ich verwende eine 16-Bit-MCU, PIC24HJ64GP504 , um eine CAN-basierte Anwendung zu schreiben. Im Grunde handelt es sich um eine Kommunikation zwischen meinem Board und einem anderen Knoten, der kontinuierlich Daten über CAN mit 1 Mbit / s an mein Board sendet. Ich konfiguriere das ECAN-Modul in meinem PIC24 so, dass es mit 1 Mbit/s arbeitet. Ich habe den Code so geschrieben, dass das ECAN-Modul für die ersten 10 ms alle Nachrichten akzeptiert, die von der anderen Seite kommen, und danach habe ich das ECAN-Modul neu konfiguriert, um nur die Nachrichten mit der Nachrichten-ID 0x13 zu akzeptieren.
Jetzt kommt das Problem. Der andere Knoten und mein Board werden im selben Moment eingeschaltet. Der andere Knoten beginnt etwa 40 ms nach dem Einschalten mit der Übertragung von Nachrichten. Aber ich kann keine Nachricht davon auf meinem Board erhalten. Wenn ich jetzt zuerst mein Board einschalte, ihm etwas Zeit gebe, das ECAN-Modul mit neuen Filtern neu zu konfigurieren und sich zu beruhigen und dann den anderen Knoten einzuschalten, dann funktioniert alles perfekt.
Jetzt der seltsamste Teil.. Wenn ich einen CAN-Bus-Analysator zwischen meinem Board und dem anderen Knoten angeschlossen habe und selbst wenn ich beide Knoten gleichzeitig einschalte, funktioniert alles gut ... keine Notwendigkeit, mein Board zuerst einzuschalten. Ich habe dies mit drei verschiedenen Bus-Analysatoren von verschiedenen Herstellern versucht und die gleichen Ergebnisse erhalten.
Mir scheint, dass es während der Neukonfiguration des ECAN-Moduls einige Zeit dauert, bis es sich beruhigt hat. Und mit der Einführung des Busanalyzers im Bus wird diese Zeit irgendwie verkürzt, damit alles perfekt funktioniert. Aber ich bin mir nicht sicher, was genau das Problem sein könnte.
Ich habe mit diesem Problem in den letzten sieben Tagen gekämpft.
PS: Ich habe heute mit einem Scope nachgesehen und festgestellt, dass wenn der andere Knoten nach 170 ms nach dem Einschalten mit dem Senden beginnt, das Ganze einwandfrei funktioniert. Davor erhält mein Gerät keine Nachrichten von ihm, es sei denn, der Busanalysator ist angeschlossen. Das Schlimmste ist, dass ich die Übertragung des anderen Knotens nicht verzögern kann, die Firmware dieses Knotens ist proprietär.
Außerdem habe ich heute in einem Forum gelesen, dass CAN den 120-Ω-Widerstand am Knoten benötigt, damit es funktioniert (obwohl mein Knoten keinen hat und es gut funktioniert, vorausgesetzt, dass nach der Neukonfiguration etwas Zeit zum Einschwingen gegeben wird). Ich vermute, dass die Einführung des Busanalysators die elektrischen Parameter einiger Netzwerke irgendwie verändert, so dass die Zeit, die mein Knoten braucht, um sich nach der Neukonfiguration einzupendeln, verkürzt wird. Aber ich bin mir nicht sicher.. :(
Sie haben irgendwo in einem Forum "gelesen", dass der CAN-Bus Widerstände benötigt? Ernsthaft!!?
Dies ist ein wesentlicher Bestandteil Ihres Designs. Wenn Sie CAN verwenden, müssen Sie es verstehen, dh die entsprechende Dokumentation lesen.
Spearson hat Recht, aber aus dem falschen Grund. Ein differenzieller CAN-Bus, wie Sie ihn wahrscheinlich haben (Sie haben nicht gesagt, welchen Schnittstellenchip Sie verwenden, aber wahrscheinlich haben Sie einen standardmäßigen differenziellen CAN-Bus, der von so etwas wie einem MCP2551 an jedem Knoten angesteuert wird) , erfordert einen Widerstand zwischen den Leitungen. Denn der rezessive Zustand wird durch das passive Zusammenziehen der beiden Linien signalisiert, der dominante Zustand durch das aktive Auseinanderziehen. Die Widerstände zwischen den Leitungen sind in diesem Sinne das Äquivalent eines Pullup-Widerstands auf einer Open-Collector-Leitung. Ohne etwas, das die Leitungen zusammenzieht, wenn nichts den Bus antreibt, funktioniert der Bus nicht.
Die Widerstände fungieren auch als Terminatoren, wie Spearson betonte. Für die beiden Busleitungen verwenden Sie in der Regel Twisted Pair. Dieser hat eine Impedanz von etwa 120 Ω. Diese Art von differenziellem CAN-Bus ist so definiert, dass er 60 Ω zwischen den Leitungen als Pull-Together hat, damit er mit jeweils 120 Ω implementiert werden kann, um den Bus zu terminieren und Reflexionen zu vermeiden.
Im normalen CAN-Betrieb wiederholt ein Knoten seine Übertragung, bis er bestätigt wird oder die Fehlerzahl überschritten wurde. Wenn Sie den CAN-Analysator mit dem Netzwerk verbunden haben, gibt er das ACK-Bit aus, wenn er den Frame von Ihrem ersten Knoten erkennt, wodurch die Übertragung erfolgreich wird. Wenn Sie den CAN-BUS-Analysator von Microchip verwenden, können Sie ihn auf den „Listen-Only“-Modus konfigurieren, was bedeutet, dass er keine ACK-Bits ausgibt und daher das Netzwerk nicht beeinflusst. Sie sollten also in der Lage sein, den wiederholten CAN-Frame in der Anzeige des Analysators zu sehen, bis der zweite Knoten ein ACK ausgibt oder der erste Knoten die Übertragung aufgrund einer Fehlerzählung beendet.
Das ACK-Bit wird von einem empfangenden Knoten gesetzt (wenn der Rahmen vollständig und korrekt ist), unabhängig von einer Adressfilterung.
Höchstwahrscheinlich erreicht Ihr erster Knoten einen Fehlerzustand, weil der Rahmen nicht bestätigt wird. Sie sollten dies in der Software mithilfe des CiINTF-Registers erkennen. Sie können den PIC auch so konfigurieren, dass er Interrupts für Fehlerbedingungen ausgibt, indem Sie das CiINTE-Register verwenden.
Wenn Ihr Oszilloskop keine CAN-Frames dekodiert, versuchen Sie es mit dem Analysator von Saleae Logic . Es dekodiert den CAN-Frame und zeigt das ACK/Error-Bit an. Es war viel zuverlässiger als der CAN-Analysator von Microchip.
Es gibt einen ACK-Slot (zwei Bits) in einem CAN-Rahmen. Wenn ein Knoten A die Daten überträgt und es fünf andere Knoten auf dem Bus gibt, wird nach der Übertragung jeder Knoten, der den Rahmen empfängt, das dominante Bit in den ACK-Schlitz stellen. Dies zeigt an, dass die Nachricht erfolgreich übertragen wurde. Andernfalls werten CAN-Controller dies als Fehler auf dem Bus.
Wenn Sie einen CAN-Analysator hinzufügen, sendet dieser ACK an den Sender. Der Sender hält den Bus für in Ordnung und sendet weiter. In Ermangelung eines CAN-Analyzers erhält der Sender bei der Neukonfiguration Ihres CAN-Controllers kein ACK und glaubt, dass ein Fehler auf dem Bus vorliegt, und stoppt die Übertragung.
Ich hoffe, du hast es verstanden.
Stellen Sie sicher, dass ACK richtig ankommt. Versuchen Sie auch, Ihren CAN-Empfänger während der Neukonfiguration nicht vollständig auszuschalten.
Ein weiterer Trick (ich bin mir nicht sicher, ob er immer funktioniert) besteht darin, nach der Neukonfiguration einen Null-DLC- und Null-ID-Frame zu senden. Dadurch wird dem Senderknoten mitgeteilt, dass der Bus aktiv ist, und er beginnt mit der Übertragung.
Hinweis: ein 120 Ω Widerstand ist ein MUSS!!! . Ein Abschlusswiderstand ist DAS Wichtige an JEDEM Bus.
Kortuk
Vicatcu
Schedler
Stefan Collings