Hi zusammen, ich möchte ein CAN Netzwerk Diagnosesytem entwerfen, dass mir folgende Funktion bietet: Angesteckt an eine CAN Leitung sollen benutzerdefinierte Nachrichten gesendet werden können. Dabei wird mittels Sende-LED und Empfangs-LED der Traffic überprüft. Für den Fall, dass einmal eine auszusendende Nachricht auf dem Bus kein ACK bekommt, wird diese ja vom CAN-Controller wiederholt gesendet (wie oft überhaupt?). Diesen Wiederholungs-Sendevorgang soll unbedingt durch die Sende-LED angezeigt werden. Das kann man dann durch dauerhaftes Leuchten gut erkennen. Ich benutze die Chips von Microchip: mcp2515 (CC) und mcp2551 (Trcv) Wie muss ich meine LED nun schalten, dass es so wie beschrieben abläuft? Ich denke die einzige Möglichkeit ist es, die zwischen die beiden ICs zu hängen. Also an die Leitungen TXCAN und RXCAN. Ich habe schon überlegt, die LED an den Interrupt Pin eines Sendepuffers zu hängen, jedoch würde da nur eine erfolgreich gesendete Nachricht ein Aufleuchten verursachen. Bin ich da schon mal auf dem richtigen Holzweg? Oli
Zu deinen ICs kann ich nix sagen, aber zu CAN mit SJA1000. Den kann man programmieren das er entweder ständig Wiederholt bis ein ACK kommt, oder im One-Shot Modus. Das heist es wird nur einmal gesendet und dann das Ergebniss ermittelt (ACK oder NACK). Die LED solltest du vom uC ansteuern lassen und zwar mit zusätzlichem Delay. Auf meiner Homepage (mictronics.de) gibts ein offenes CAN Bus Interface, da kannst du mal in den Code schaun wie ich das gelöst habe.
> Für den Fall, dass einmal eine auszusendende Nachricht auf dem Bus kein > ACK bekommt, wird diese ja vom CAN-Controller wiederholt gesendet (wie > oft überhaupt?). Im Normalfall (also One-Shot-Modus nicht aktiviert...) 255 mal, danach geht der Knoten in den "Bus Off" - Zustand. > Wie muss ich meine LED nun schalten, dass es so wie beschrieben abläuft? > Ich denke die einzige Möglichkeit ist es, die zwischen die beiden ICs zu > hängen. Also an die Leitungen TXCAN und RXCAN. Ohne jetzt die Datenblätter zu kennen: Diese beiden beiden Signalleitungen dürften kaum in der Lage sein, LEDs zu treiben. Und selbst wenn: Bei 100kBaud dauert ein 8-Byte-Frame ~1ms. Sichtbar wäre höchstens eine gefühlte Buslast, aber nicht ob, und wie oft ein Tx-Versuch wiederholt wird... > Ich habe schon überlegt, die LED an den Interrupt Pin eines Sendepuffers > zu hängen, jedoch würde da nur eine erfolgreich gesendete Nachricht ein > Aufleuchten verursachen. Wie oben: auch dieses Signal kann nicht direkt eine LED treiben, und wenn doch (bzw. über Treiber realisiert): keine Aussage über wiederholte Sendeversuche... Die LED sollte vom uC angesteuert werden. Soweit ich gesehen habe, gibt es für eine verlorene Arbitrierung das "TXBnCTRL.MLOA"-Bit, für sonstige Fehler die "TXBnCTRL.TXERR" und "CANINTF.MERRF" - Bits, die vom uC ausgewertet werden können.
>> Für den Fall, dass einmal eine auszusendende Nachricht auf dem Bus kein >> ACK bekommt, wird diese ja vom CAN-Controller wiederholt gesendet (wie >> oft überhaupt?). >Im Normalfall (also One-Shot-Modus nicht aktiviert...) 255 mal, danach >geht der Knoten in den "Bus Off" - Zustand. Bist du sicher? Das würde bedeuten, dass eine niedrig priore Nachricht, welche 255 mal überschrieben würde, den ECU lahmlegt. Und dieses Szenario ist m.M. sehr häufig.
> Bist du sicher? Das würde bedeuten, dass eine niedrig priore Nachricht, > welche 255 mal überschrieben würde, den ECU lahmlegt. Nein, ich bin nicht sicher. So ist das, wenn man aus seinem Halbwissen zitiert... Ich habe noch einmal in die Bosch-CAN-Spec. geschaut. Es gibt u.a. einen Transmit Error Counter (TEC). Wenn der TEC < 128 ist, ist der Knoten "Error Active", ist 128 <= TEC < 255, ist der Knoten "Error Passive" (und darf kein "ACTIVE ERROR FLAG" mehr setzten, aber noch Botschaften senden...). Ist der TEC >=255, ist der Knoten im Zustand "Bus Off" und darf nicht mehr den Bus beeinflussen. Mein Irrtum war, daß ich angenommen hatte, daß eine verlorene Arbitrierung zur Erhöhung des TEC führt. Das kann ich aber so nicht in der CAN-Spec. finden. Wenn ich mich also nicht wieder irre, versucht der CAN-Controller so oft die niedrigpriore Botschaft zu senden, bis er die Arbitrierung gewinnt, oder andere Fehler auftreten. Weiterer Irrtum meinerseits: der TEC wird je nach Fehler um 8 erhöht, was schneller als von mir angegeben zu "Bus Off" führen kann... Dieses "Low-Level"-Verhalten wird aber von den CAN-Protokoll-Controllern, die ich kenne (v.a. Freescale MSCAN) weitgehend autark (ohne SW-Eingriff) geregelt. D.h., dort bekommt die SW eine verlorene Arbitrierung in den Konfiguratuionen, mit denen ich arbeite, nicht mit. > Und dieses Szenario ist m.M. sehr häufig. Das hängt ganz von der Busauslastung ab und deutet auf einen überlasteten CAN-Bus hin.
Ach ja, es ging ja ursprünglich um "kein ACK gesehen" und nicht um "Arbitrierung verloren". Für ein fehlendes ACK-Bit gilt: wenn der Controller bereits "Error Passive" ist, wird der TEC nicht weiter erhöht. Diesen Fall kann der CAN-Controller aber gewöhnlich an die SW signalisieren. Wenn aber kein ACK-Bit gesetzt wird, heißt das normalerweise, daß es keine anderen Knoten gibt oder die anderen Knoten noch nicht kommunikationsbereit sind. In einem "stabilen Zustand", den es meist im Netzwerk gibt, kommt es normalerweise nicht vor, daß das ACK-Bit nicht gesetzt wird. Gruß Martin
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.