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
