Hallo zusammen, das CAN (in meinem Fall 2.0B)-Protokoll ist ja per se recht fehlertolerant, insbesondere gegen "Babbling Idiots", also Knoten, die außer Kontrolle geraten und Mist senden. Mir bekannt sind z. B. folgende Mechanismen: - Transceiver schalten automatisch die Treiber ab, wenn sie länger dominante Pegel schalten als es bei der niedrigsten sinnvollen Bitrate zwischen den Stuff Bits auftreten könnte - Controller müssen TEC und REC implementieren, um auf massiv auftretende korrupte Frames zu reagieren - Einige Controller überwachen auch hardwareseitig die Kurzschlüsse der CAN-Leitungen gegen andere Potentiale und melden das an den µC Jetzt die Frage: Wird bei CAN-Controllern wie MCP2515 oder dem im AT90CAN integrierten hardwareseitig verhindert, dass man den Bus mit gültigen ID 0-Frames blockiert? Ich hätte tatsächlich einen Anwendungsfall, einen Bus zu Testzwecken zu jammen, damit andere Knoten in die Frame Timeouts laufen, was ich mir theoretisch mit ID 0 Länge 0-Nachrichten gut vorstellen könnte. Geht das z. B. mit einem AT90CAN?
Thomas S. schrieb: > gültigen ID 0-Frames blockiert? Wie soll das bei GÜLTIGEN ID 0 Frames funktionieren? Da kommt einer, wird verarbeitet und dann kommt der nächste, wieder ID 0, usw. Klar, da kann man in SW diverse Maßnahmen ergreifen, z.B. Timeouts. Aber der Controller kann sich ja nur auf den Empfang von gültigen Nachrichten konzentrieren. Wenn der Frame als solches ungültig ist, wäre das eine Sache des Controllers - alles andere ist Sache der Software.
Harald A. schrieb: > Wie soll das bei GÜLTIGEN ID 0 Frames funktionieren? Ja, das hab ich mich auch gefragt. Aber wenn man einen Versuch wegwerfen muss, dann ja nicht wegen offensichtlicher Dinge, sondern wegen Fußnote 17 auf Seite 377 im Datenblatt. Also wollte ich sicherheitshalber nachfragen, ob ich mit einer hardwareseitigen Flooding Protection rechnen muss. Danke für die Antwort!
Gast
#4863281
Kurze Antwort: es gibt da keinen Schutz, da es sich um legitimen Traffic handelt.