CAN identifier als Trigger

martinW Gast #703503
Lesenswert?
• ▲
▼ 
Hallo!

Ich bin gerade am tüfteln, ob ein CAN-Bus meine Anforderungen erfüllt 
und komme nicht weiter...deshalb würde ich mich über ein paar hilfreiche 
Kommentare sehr freuen!
Zu meinem Problem: Ich möchte auf einem CAN-Bus nicht nur Daten 
übertragen, sondern auch ein CAN-Telegramm als Trigger verwenden, auf 
welches dann möglichst_schnell ein Event im uC folgt. Kann ich dazu 
auch den Identifier alleine verwenden? So, dass wenn ein CAN-Telegramm 
mit der ID x kommt ich sofort weiß, dass mein Trigger-Ereignis gestartet 
werden kann ohne, dass ich erst die restlichen Bits des Telegramms 
einlesen muss?

Sollte das nicht gehen, stimmt dann folgende Überlegung für ein 
komplettes Telegramm?
Ein CAN-Telegramm mit einem Datenbyte hat 54Bit (ohne Stuffing). Bei 
einer Übertragungsrate von 1Mbps wären das dann 54us Übertragunszeit 
(natürlich ohne Verzögerunszeiten durch Transceiver, 
Wellenausbreitungszeiten etc.) Oder mache ich hier einen grundlegenden 
Überlegungsfehler?

Danke&Gruß
Martin
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Willivonbienemaya .. #703513
Lesenswert?
• ▲
▼ 
So ganz ist mir nicht klar was du machen willst.

Aber ich denke mal es wird daran scheitern, dass du beim CAN Bus keine 
garantierten Latenzzeiten bekommst.

Angenommen deine Nachricht benötigt tatsächlich 54µs Übertragungszeit, 
wie willst du sicherstellen, dass sie sofort gesendet wird.
Wenn erst mal 100 andere höher priorisierte Telegramme über den Bus 
gehen, kann das deine Nachricht schon erheblich verzögern.

Vielleicht schreibst du einfach noch etwas genauer was du machen 
möchtest.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
martinW Gast #703582
Lesenswert?
• ▲
▼ 
Danke erstmals für Deine Antwort!

Der Traffic wird minimal sein. Am Bus hängen ein uC und 2 Geräte, die 
jeweils möglichst schnell und mit konstanter Zeit-Differenz auf ein 
Telegramm des C167 reagieren sollen (Trigger). Des Weiteren gibt es auch 
eine bidirektionale, prinzipiell zeitunkritische und nicht sehr häufige 
(mehrere hundert ms zw. Telegrammen) Kommunikation (Stati, Ergebnisse 
etc.). Um die Reaktionszeit kürzer zu machen, dachte ich mir, dass ich 
für die Trigger-Erkennung vielleicht nur den Identifier im jeweiligen 
Gerät auswerten brauche. Also insgesamt 4 IDs (Trigger Gerät 1, Trigger 
Gerät 2, Daten Gerät 1, Daten Gerät 2) Ob das so einfach geht, wie ich 
mir das vorstelle weiß ich jedoch leider nicht, da ich aus der trockenen 
Theorie leider nichts diesbzg. herauslesen konnte.

Ansonsten muss ich wohl als Trigger ein normales Datentelegramm mit der 
Information "Trigger" an das Gerät senden, was geschwindigkeitsmäßig 
theoretisch noch im grünen Bereich ist. Theoretisch! Hast Du eine Idee 
wie lange die Verarbeitungszeit ("uC sendet Telegramm" bis "Event wird 
beim Gerät erkannt") unter obigen Voraussetzungen ungefähr sein wird? 
Also 54us + Physik oder muss ich noch andere, nicht genannte Faktoren 
berücksichtigen?

Danke & viele Grüße
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Alex Gast #703585
Lesenswert?
• ▲
▼ 
Konfiguriere die Mailboxen 1-4 einfach auf die 4 benötigten IDs (= in 
der Maske alle Bits auf 1 setzen und in den IDs die benötigten Werte 
eintragen). Wenn die Daten nicht relevant sind, dann verwende Frames mit 
einem data length code von 0, damit entfällt dieser Overhead.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Willivonbienemaya .. #703721
Lesenswert?
• ▲
▼ 
Ja, so ist das machbar.
die niedrigsten IDs nehmen, und keine Daten mitschicken.

Ich nehm mal an der C167 hat einen CAN Controller onboard?

Dann dekodiert er die CAN Nachricht direkt während dem Empfang und löst 
mit minimaler Verzögerung einen Interrupt aus.
weiter kann dir die Theorie nicht helfen. Wenn dus genauer wissen 
willst, musst du sowas testweise aufbauen und mit einem Scope messen wie 
groß die Latenz ist.

Was ist das denn für eine Anwendung, bei der du einen Trigger brauchst?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
eProfi Gast #703778
Lesenswert?
• ▲
▼ 
Es könnte vielleicht noch schneller gehen, wenn Du zum Triggern gezielt 
einen Bus-Error (z.B. 20 Bit langen Dominant-Pegel) erzeugst, der dann 
einen Error-Irq auslöst.

Ähnlich wie bei der Seriellen einen Parity-Error oder Break-Signal 
(Framing-Error).


@Alex (Gast) "Eher 0, 1, 2 und 3 ;-)"
?? könntest Du das mal bitte näher erläutern?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren