Ist der MCP2551 ein UART-zu-CAN-Konverter?

Ich möchte mit meinem Computer einen CAN-Bus-Sniffer für 250 kbit / s erstellen. Nach einigen Recherchen habe ich herausgefunden, dass MCP2551 eine Art Spannungspegelregler für die physikalische Schicht von CAN ist. Vor diesem Hintergrund frage ich mich, ob dieses Setup funktionieren könnte. Ich möchte nur die ausgetauschten Nachrichten für automatisierte Testzwecke aufzeichnen und nicht Teil der Kommunikation sein:

PC <-> USB-UART (vielleicht CP2102, weil ich bereits einen habe) <-> MCP2551 <-> CAN-Bus

Wenn nicht, welche Art von Signalen muss MCP2551 eingeben, damit ich Teil des Busses bin?

usb microchip can

— rnunes
quelle

Antworten:

Sie können das tun, aber was Sie auf Ihrem CAN-Bus bekommen, wird UART unter Verwendung von CAN-Spannungspegeln sein. Sie müssen das MCP2551 mit CAN-Protokollnachrichten versorgen, wenn Sie mit CAN-Geräten auf Ihrem Bus kommunizieren möchten. Dasselbe gilt für das Abhören: CAN-Nachrichten unterscheiden sich so stark vom UART-Format, dass der UART nicht weiß, was er damit machen soll. Sie werden die ganze Zeit mindestens Frame-Fehler haben, und Sie werden nicht an den Inhalt der Nachricht gelangen.
Dieses Bild zeigt den Aufbau einer CAN-Nachricht:

Bildbeschreibung hier eingeben

Es gibt viele Mikrocontroller mit einer CAN-Schnittstelle ohne Transceiver. Für diese wurde der MCP2551 entwickelt. In der Vergangenheit haben wir den NXP LPC2294 verwendet, der über 4 CAN-Schnittstellen verfügt. Jeder von ihnen benötigt einen MCP2551 zum Anschluss an einen CAN-Bus. Neuere Controller von NXP umfassen die LPC1800- Familie, von der alle Mitglieder CAN unterstützen.

— stevenvh
quelle

Ich habe die UART Start / Stop Bits und wahrscheinlich einige CAN "Start / Top Bits" Situationen total vergessen. Ich werde wahrscheinlich versuchen , eine Lösung unter Verwendung eines CAN - Stack auf dem PC als gpio mit FTDI zu finden, dem MCP2551 am Ende wird übertragen

— rnunes

@rnunes - Es sind nicht nur die Start- / Stoppbits. Ohne diese ist eine UART-Übertragung nur ein 8-Bit-Byte. Eine CAN-Nachricht ist mit Adressierung, Priorität und Fehlerprüfung wesentlich komplexer. Sie können die beiden nicht vergleichen.

— stevenvh

Aber mit dem FTDI arbeite ich Stück für Stück (im Grunde ist es ein sehr schnelles USB <-> GPIO), nicht byteweise wie mit UART. Ich suche bereits nach diesen CAN-MCUs, aber ich würde es vorziehen, für den Moment Geld auszugeben (es ist ein Hobbyprojekt für Studenten), und ich habe bereits die FTDI. Wenn ich mit meinen Nachforschungen feststelle, dass der FTDI dies nicht kann, werde ich versuchen, eine CAN-MCU zu verwenden.

— 19.

Der Stack ist für die Abwicklung aller Vorgänge (z. B. Bitstuffing) verantwortlich und überträgt diese nach und nach an MCP2551. Das einzige Problem, das ich derzeit habe, ist die FTDI-Latenz, da ich sie schnell und regelmäßig haben muss, aber ich werde sie später messen.

— 19.

@rnunes - Was jedoch aus dem CP2102 (SiLabs, nicht FTDI) kommt, sind Bytes , nicht Bits. Sie können es nicht nach einem Stück stoppen. Sie benötigen sowohl den CP2102, um Ihren Mikrocontroller mit USB zu verbinden, als auch einen Mikrocontroller, der CAN + MCP2551 unterstützt. Oder ein Mikrocontroller, der auch als USB-Gerät fungieren kann. Dann brauchen Sie den CP2102 nicht.

— stevenvh

Ich habe eine USB / CAN-Schnittstelle mit FT2232H im MPSSE-Modus (UART vergessen), MCP2515 und MCP2551 erstellt. MCP2515 ist das Schlüsselstück, das Sie hier vermissen. Studieren Sie gut, was es tut. Es ist der eigentliche CAN-Controller, der Framing, ACKs, Generierung und Verifizierung von Prüfsummen, Nachrichtenfilterung und andere weniger offensichtliche Aufgaben übernimmt, die ein CAN-Knoten nach dem Standard ausführen muss. Wenn Sie einen Sniffer wünschen, verfügt der MCP2515 über einen Listen Only-Modus, der garantiert, dass keine Übertragungen auf dem Bus erfolgen. Der MCP2551 ist einfach ein dummer physikalischer Schichtadapter, ähnlich einem MAX232 für RS-232 oder ADM485 für RS-485.

Diese Architektur ist bei weitem nicht perfekt, da die FTDI-MPSSE-Technologie im Wesentlichen keine Unterstützung für Interrupts bietet (ich glaube, sie verwendet nur Massen-USB-Übertragungen im Hintergrund). Daher muss ich den Controller häufig nach neuen Nachrichten abfragen. Dies belastet den USB-Host-Controller sehr, garantiert jedoch nicht, dass keine Nachrichten verloren gehen (der MCP2515 kann bis zu 2 empfangene Nachrichten intern speichern, wenn Sie den "Überlaufmodus" aktivieren, nur eine, wenn Sie dies nicht tun). Eine weitaus bessere Lösung wäre ein geeigneter Mikrocontroller mit integriertem CAN und USB-Peripheriegeräten wie STM32F105 (103 kann nicht gleichzeitig USB und CAN verwenden). In diesem Projekt erfahren Sie, wie genau diese Idee umgesetzt wird. LPC18xx wie von stevenh vorgeschlagen wird auch funktionieren, aber LPC17xx sind wahrscheinlich billiger und leichter zu finden.

— Dorn
quelle

In diesem Fall ist das Pooling kein Problem, aber die ideale Lösung wäre die Verwendung einer MCU mit CAN-Controller, die als CAN-Nachrichtenpuffer fungiert. Ab jetzt werde ich versuchen, das erste Setup zu verwenden, das Sie geschrieben haben. Thanks

— rnunes

+1 Die Verwendung des FTDI-Chips, um direkt mit einem CAN-Controller ohne uC zu kommunizieren, ist in Ordnung. Anscheinend kam FTDI mit FT221X heraus, einer dedizierten USB-zu-SPI-Brücke. (Es gibt auch ein anderes Modell für USB zu I2C.)

— Nick Alexeev

Da Sie einen vorhandenen CAN-Bus abhören möchten, wie ich die Frage verstehe, können Sie einen UART überhaupt nicht verwenden. CAN- und UART-Signalgebung sind völlig unterschiedlich.

Sie könnten theoretisch die CAN-Empfangsleitung betrachten, die vom MCP2551 ausgeht, und den CAN-Verkehr dekodieren. Das wird nicht einfach, ist aber theoretisch möglich. Ohne spezielle CAN-Hardware müssen Sie einige Male schneller als die CAN-Bitrate abtasten und diesen Bitstrom später in der Software dekodieren. Sie müssen wahrscheinlich mit ca. 1 Mbit / s aufnehmen, um 250 kbit / s CAN zu decodieren.

Die Verwendung eines Mikrocontrollers ist viel einfacher. Der PIC 18F2580 und ähnliche Prozessoren verfügen über ein eingebautes CAN-Peripheriegerät. Die Hardware dekodiert alle Bitpegel und empfängt ganze CAN-Frames. Der Prozessor kann dann empfangene CAN-Frames über seinen UART an Ihren PC senden.

— Olin Lathrop
quelle