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
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.
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
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.
Und verwende als Trigger die ID 0, denn die gewinnt die Arbitrierung immer. Ansonsten kommt nur noch die Interrupt-Latenzzeit hinzu.
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?
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?
Ich danke Euch allen für Eure Hilfe und für die Geduld beim Herauskitzeln was ich eigentlich will (auch das war ein wichtiger Prozess bei mir;) !!! alles Gute weiterhin Martin
sorry, vergaß ich total: Die Anwendung ist ein Geschwindigkeitsmessgerät mit externen Kameras, welche eben zum richtigen Zeitpunkt ausgelöst werden sollen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.