Kann CAN-Bus Treiber nur dem CAN-Bus zuhören? / I2C -> SPI Konvertierung notwendig?

International Deutsch
1

Hallo,
ich möchte mit einem IMU (Bosch BNO055) Bewegungen an einem Sensor (ist fest am Auto montiert) erfassen, die der Sensor während der Fahrt aufgrund des Windwiderstands macht. Die Sensorsignale werden mit I2C an einen Arduino Nano 33 BLE gesendet und dann mit dem integrierten Bluetooth-Modul an einen weiteren Arduino Nano 33 BLE gesendet. Am Ausgang des zweiten Arduino Nano 33 BLE werden die Signale von I2C zu SPI konvertiert. Um die Signale mit der Messtechnik verbinden zu können, müssen die Signale als CAN-Bus Signale vorliegen, daher verwende ich noch einen CAN-Bus Treiber.

Ablauf:
IMU (Schnittstelle I2C) (Bosch BNO055) -> Arduino Nano 33 BLE --> Datenübertragung mit Bluetooth --> Arduino Nano 33 BLE --> Bus Converter von I2C zu SPI (SC18IS602 I2C to SPI Bridge Module) --> CAN-Bus Treiber (Serial CAN-Bus Module with MCP2551 und und MCP2515)

Nun meine Fragen:

  • Kann der CAN-Bus Treiber ein Bus Signal daraus machen oder muss ein CAN-Bus vorhanden sein, weil der CAN Treiber nur einen CAN-Bus zuhören kann?
  • Ist der Bus Converter überhaupt notwendig oder kann der Mikrocontroller des Empfänger-Arduinos die Signale intern von I2C zu SPI wandeln oder muss ich gar nichts machen und die Signale liegen an MISO und MOSI an?

Die Teile habe ich noch nicht bei mir. Ich betreibe aktuell noch Recherche.

Viele Grüße

2

Jeder Bus hat seine eigenen Pins zugeordnet, über die Daten gelesen und geschrieben werden können. Den Daten ist es egal, über welchen Bus sie geschickt werden. Unterschiedlich sind nur die für die Übertragung nötigen Bibliotheken und Methoden.

3

Ich sehe nicht, dass Deine Sensorsignale auf dem Empfänger-Nano noch irgendwas mit I2C zu tun haben sollten, denn der Sensor ist am Sender-Nano angeklemmt. Da ich aber den Nano 33 BLE nicht kenne weiß ich natürlich nicht, wie genau die Daten am zweiten Nano ankommen (gibt es da Serial Profile?).
Das heißt: M.E. brauchst Du keinen I2C nach SPI. Du selbst legst mit Deinem Programmcode und vermutlich mit Hilfe einer MCP2515-Library auf dem Empfänger-Nano die Daten auf den SPI, um den CAN zu füttern.

Wenn ich mich recht entsinne, kann der MCP2515 auch loopback, dann brauchst Du keinen zweiten Busteilnehmer. Hier hat die Suchmaschine meines geringsten Mißtrauens ein Beispiel ausgespuckt.

4

Vorweg: Einen Arduino Nano 33 BLE hatte ich noch nie in der Hand.

Der Bus Converter von I2C zu SPI erschließt sich mir nicht, da der Nano 33 BLE doch SPI hat:

grafik
grafik794×479 121 KB

Ich würde das CAN-Bus Module direkt anschließen.

Ein Bus hat zwei oder mehr Teilnehmer, sonst ist es kein Bus. Die "Messtechnik" hat wohl einen CAN-Bus, sonst würdest Du den nicht nutzen wollen. Das CAN-Bus Module kann senden und empfangen.

Oder verstehe ich Deine Frage nicht?

Der Teensy 3.2 hat eine CAN-Bus-Schnittstelle eingebaut und benötigt daher nur externe Treiber ( TJA1050 CAN Bus Tranceiver Modul) für die Differenzsignale.

Beim Nano 33 BLE sehe ich keine CAN-Bus-Schnittstelle, weshalb das CAN-Bus Module mit MCP2551 und MCP2515 notwendig ist. Der CAN-Bus-Prozessor wird hinsichtlich Filtern usw. konfiguriert, übernimmt sonst die komplette Kommunikation. Der Arduino sendet und erhält Daten über SPI und eventuell per Interrupt.

Eventuell hilft Dir dieser Text: UNO - Mega - Teensy mittels CAN-Bus verbinden

5

Was mir an dem Bildchen aufgefallen ist:
D19/A5 ist auch I2C-SCL, nicht nochmal SDA.

6

:wink:
Der TO hat zwei.
Sensor - I2C - BLE -/ Bluetooth /- BLE - SPI->CAN
Die Umsetzung erfolgt aus dem BT nach CAN

Ja.
CAN ist ein Multi-Master-Bus.

Ja.
Die Datenübetragung erfolgt 2-Draht mit symetrischem Pegel. Es gibt wie bei RS485 kein Bezugspotential.

7

Da sollte man noch mal nachhaken: Der TO spricht von einem CAN-Bus-Treiber ... Der erzeugt aber nur die Pegel und nicht das Protokoll, wie es ein CAN-Bus Modul würde ... ?!?

Sorry, schon gesehen, es ist ein Serial CAN-Bus Module with MCP2551 und MCP2515 ...

8

Ich zitiere:

Der rot markierte Teil stört mich.

Ja, da ist ein selbständig agierender Prozessor drauf. "Dummer" Treiber ist TJA1050 CAN Bus Tranceiver Modul.

9

Ich hab's mal aufgemalt wie ich das verstehe.
Kein I2C to SPI Buskonverter nötig.
Sehr spitzfindig: Wenn überhaupt, bilden die beiden Nanos mit der Funkstrecke einen solchen Umsetzer.

image
image1528×298 11.3 KB

2 Likes
10

Genau so sieht das Bild in meinem Kopf auch aus :slightly_smiling_face:

11

Wieder einmal ein unbestreitbares Beispiel für den wahren Spruch: Ein Bild sagt mehr als tausend Worte :wink:

12

Dann bin ich erstens nicht allein (Danke!) und zweitens die zweite Frage aus dem Eingangspost wohl beantwortet.

Bei der ersten würde ich dazu tendieren, während der Entwicklung einen zweiten CAN-Teilnehmer mindestens zum Horchen, vielleicht auch zum gezielten Simulieren erwünschter und nicht erwünschter Bus-Nachrichten einzusetzen. Das wäre z.B. nochmal die Empfänger-Nano-Konstruktion rechts angebaut.

13

Auch da bist Du nicht alleine!

So habe ich das auch im in #4 verlinkten Thema gemacht, um die Filterwirkung auszuprobieren.

14

Vielen Dank für die zahlreichen und hilfreichen Antworten!

Ich habe meine Skizze angehängt, um zu zeigen, wie ich es umsetzen würde.
Ich hatte die Vorstellung, dass I2C und SPI ihr eigenes Protokoll haben und man deswegen von Anfang bis zum Ende denselben Bus verwenden muss. Ich verstehe die Antworten so, dass man bis zum Arduino mit einem Bus arbeiten muss und man danach ohne Weiteres einen "neuen" Bus verwenden kann, weil I2C und SPI ohne Protokoll arbeiten.

Hinsichtlich CAN-Bus:
Der Loopback-Modus wird wohl nicht funktionieren, weil das ein stiller Modus ist. Das heißt, dass in diesem Zustand keine Nachrichten übertragen werden. Das werde ich evtl. mal testen.

mit_konv
mit_konv1261×692 205 KB

15

Hier noch ohne Konvertierung

ohne_konv
ohne_konv1261×693 174 KB

16

Vielleicht habe ich das übersehen, aber um welche Messtechnik geht es da?

I2C, SPI und CAN haben schon auf "unteren" Ebenen schon ihre eigenen Protokolle, die aber entweder in Software oder einem spezifischen Controller abgebildet sind.

Im Gegensatz zu I2C und SPI ist der CAN ein message-basierender Bus, wobei jede erlaubte Nachricht einem fest vorgegebenen Identifier zugeordnet sein muss.
Jedem Sender werden bestimmte IDs zugeordnet, die er versenden darf.

Die ID der Messages wird auf dem Bus dazu genutzt, Kollisionen zu vermeiden: Wer zu senden beginnt, prüft, ob die von ihm gesendeten ID-Bits auch auf dem Bus landen. Dominate Bits "überschreiben" rezessive Bits. Ein Sender, der erkennt, dass eines seiner Bits nicht durchkommt, nimmt sofort die "Füsse vom Bus", so dass der Sender mit der höherprioren Message-ID vom "Doppelversuch" gar nichts merkt (ebenso wie die lauschenden Empfänger).

Damit diese Bus-Arbitrierung funktioniert, gilt das "Highlander-Prinzip": Es darf nur einen geben ... (der auf einem CAN Bus eine bestimmte Nachrichten-ID versenden darf.).

Zudem kann man bei CAN Bus im Standard ohne höhere Protokollschichten maximal 8 Byte mit einer Nachricht versenden, muss also längere Pakete stückeln und wieder zusammensetzen.

Wichtig wäre daher, dass die IDs und die interne Struktur der Messages bekannt sind, die die "Messtechnik" erwartet ... zzgl. mindestens zur Baudrate und ggf. weiterer Parameter sowie der Frage, ob die Messtechnik u.U. auf höhere Protokollschichten aufbaut (Canopen, Unified Diagnostic Services, ...).

Gibt es für diese Seite eine ausreichende Dokumentation?

17

Na ja, das ist nicht ganz richtig. Es gibt schon Vorschriften, wie Busteilnehmer adressiert werden, wie Nutzdaten verpackt werden und wie die Signale elektrisch jeweils zueinander in Beziehung stehen (Clock, Data, ChipSelect usw.). Die Elektrik regeln die HW-Module auf dem Chip, den SW-Teil kann man u.a. den Dokumentationen der jeweiligen Libraries (beim Standard-Arduino Wire für I2C und halt SPI) entnehmen.

Vermutlich stimmen mir einige zu, wenn ich sage, dass die Variante aus Post #15 ohne Konvertierung mit direkter Nutzung der SPI-Schnittstelle des Nano 33 BLE zu bevorzugen ist.

Was genau hast Du an Messtechnik von Vector zur Verfügung?
Wenn es ein CANoe ist, ist das schon Dein zweiter Busteilnehmer und damit kannst Du alles aufzeichnen, was Du so auf den MCP packst.

18

Zwischen Empfänger und CAN-Bus-Treiber fehlen SCK D13 und CS D10, mit MISO und MOSI sind es also vier Leitungen.

Ich würde mit der Verbindung des Empfängers über CAN-Bus mit der "Messtechnik" anfangen, denn ob das wunschgemäß zum Funktionieren gebracht werden kann, hängt von einer guten Dokumentation der "Messtechnik" ab. Wenn Du mit CAN-Bus noch nie was gemacht haben solltest, wartet da auch die steilste Lernkurve auf Dich. Deine Herangehensweise erscheint mir recht akademisch, weshalb ich Dir zu etwas Praxis raten möchte.

Verbinde beispielsweise die zwei Nanos per CAN-Bus und spiele mit der Kommunikation, der normalen und erweiterten Adressierung und den Filtern. Wenn Du dafür ein Gefühl entwickelt hast, kannst Du die Nanos mit der Meßtechnik verbinden und sehen, was dann passiert.

Das Auslesen von fünf Meßwerten aus dem Bosch-Sensor und deren Weiterleitung per Bluetooth möchte ich als nicht so problematisch einschätzen. Das Wort "einfach" habe ich aber nicht verwendet.

Selbstverständlich gebe ich nur meine persönliche Einschätzung wieder, was auch sonst :slightly_smiling_face:

19

Oh danke, so genau habe ich gar nicht draufgeschaut, hatte mich auf den Konverter konzentriert.

Warten wir mal, was der TO sagt. Vector-Technik ist professionell in der Automobil-Industrie und teuer - ein CANoe kostet soweit mir bekannt einen höheren vierstelligen Betrag.

20

@ec2021
Als Messtechnik verwende ich von Vektor die VN-Box 7600 und das Tool CANape.

Mir ist nicht ganz klar was du unter Dokumentation verstehst? Ich habe mit dem Vector-Support telefoniert und die meinten, dass es mit dem CAN-Treiber funktioniert und ich nur eine eigene Datenbasis schreiben muss. Falls der Begriff Datenbasis unbekannt ist, dass ist die Vernetzungsdatei, wo alle Signale und deren Einzelheiten beschrieben wird. Darin ist die Signalgröße, Einheit vom Signal, in welcher Botschaft etc. beschrieben. Bin mir aber nicht sicher, ob der Support tatsächlich mein Problem verstanden hat.

@wno158
Da ich keine Konvertierung machen muss, werde ich das auch weg lassen und es wahrscheinlich so wie in Post #15 machen.
Als Messtechnik verwende ich von Vektor die VN-Box 7600 und das Tool CANape.

Warten wir mal, was der TO sagt. Vector-Technik ist professionell in der Automobil-Industrie und teuer - ein CANoe kostet soweit mir bekannt einen höheren vierstelligen Betrag.

Mal schauen wann ich eine Abschätzung geben kann :slight_smile: