Eigenständiges CAN-Busmodul oder eingebettetes STM32-CAN?

Ich habe Tage damit verbracht, zu studieren und zu versuchen, mit stm32f1 von Grund auf eine einfache Kommunikation mit dem CAN-Bus zu erreichen, aber ich habe immer noch nicht die gewünschten Ergebnisse erzielt und es ist schwierig zu verstehen und zu programmieren.

Andererseits gibt es CAN-Bus-Module, die wie folgt mit einem Mikrocontroller per SPI kommunizieren: https://www.ebay.com/itm/283953770322?hash=item421cf6af52:g:JHAAAOSwIeVfQ7HI

und es gibt viele Bibliotheken, um diese Module zu handhaben, aber die offizielle Mikrochip-Seite empfiehlt nicht, den MCP2515 weiter zu verwenden.

Mein Zweifel ist: Welcher Unterschied besteht darin, den CAN-Bus von Grund auf neu (STM32) zu verwenden, als ein separates Modul zu verwenden? Die Verwendung eines eigenständigen Moduls beeinträchtigt die Sicherheit des CAN-Busses? Soll ein eigenständiges Modul in der Industrie eingesetzt werden?

Wahrscheinlich dasselbe wie ein interner vs. externer ADC. Interrupts und Register sind für das Interne schneller. Keine SPI-Nachricht, etwas zu tun. Du machst es einfach.
Mit "von Grund auf" meinen Sie einen Software-CAN-Controller im Gegensatz zu einem Hardware-CAN-Peripheriegerät (sei es in die MCU integriert oder extern über SPI)?

Antworten (3)

Welcher Unterschied besteht zwischen der Verwendung eines CAN-Busses von Grund auf (STM32) und der Verwendung eines separaten Moduls?

Externe CAN-Controller gehören weitgehend der Vergangenheit an. In den 1990er Jahren war dies die einzige Möglichkeit, CAN zu verwenden, bevor Mikrocontroller anfingen, On-Chip-CAN-Controller zu unterstützen.

Seitdem besteht der einzige Grund für die Verwendung eines externen CAN-Controllers darin, dass Sie spezielle Projektanforderungen haben, die zu einer sehr spezialisierten MCU führen - einer, die nicht mit einer CAN-Version geliefert wird.

Die Verwendung eines eigenständigen Moduls beeinträchtigt die Sicherheit des CAN-Busses?

Nicht Sicherheit wie beim Schutz vor böswilliger Nutzung. Aber es macht das gesamte Design etwas empfindlicher gegenüber EMI, da SPI nicht annähernd so robust ist wie CAN. Der externe Controller führt auch zu viel Latenz, BoM-Kosten und insgesamt zusätzlicher sinnloser Komplexität.

Die offizielle Mikrochip-Seite empfiehlt jedoch nicht, den MCP2515 weiter zu verwenden

Das liegt hauptsächlich daran, dass Microchip eine neue Generation all seiner Transceiver und Controller mit Unterstützung für CAN FD entwickelt hat. Die neuen modernen Teile sind abwärtskompatibel und haben auch eine bessere Immunität und ESD-Schutz usw.

Wenn Ihre MCU über ein On-Chip-CAN-Peripheriegerät verfügt, ist die Verwendung dieses gegenüber einem externen Modul vorzuziehen. Berücksichtigen Sie neben der von Ralph erwähnten Latenz auch die Kosten, Verfügbarkeit und Zuverlässigkeit der Verwendung eines Moduls.

Denken Sie so darüber nach. Auf dem Markt sind viele IO-Expander-Chips erhältlich. Würden Sie einen verwenden, wenn Sie viele freie Pins auf der MCU hätten? Wahrscheinlich nicht. Wenn andererseits alle Ihre Pins aufgebraucht sind, ist ein I2C-Port-Expander möglicherweise eine praktikablere Option, als die MCU in einem größeren Paket zu bekommen.

Im Allgemeinen haben Geräte auf einem CAN-Bus Anforderungen, dass die Nachrichten mit einer sehr geringen Zeitlatenz von einem Gerät zum anderen geliefert werden. Zum Beispiel das Übermitteln der Position einer rotierenden Motorwelle von einer Motorantriebsvorrichtung an eine Steuerung über den Bus. Die Daten sind nicht nützlich, wenn sie nicht innerhalb einer kurzen Verzögerung geliefert werden. Wenn sich zwischen Ihrem Prozessor und dem CAN-Bus ein Gerät befindet, mit dem Sie über SPI kommunizieren müssen, verzögert diese Device-in-the-Middle-Kommunikation jede Nachricht und erhöht die Latenz ihrer Ankunft bei anderen Geräten auf dem CAN-Bus.

Ein CAN-Controller, der in einen Mikrocontroller integriert ist, der direkt auf dem CAN-Bus kommuniziert, ist die beste Möglichkeit, mit anderen Geräten mit geringer Latenz zu interagieren. Die meisten Mikrocontroller-CAN-Peripheriegeräte können die Low-Level-Kommunikation handhaben und den Mikro nur bei Bedarf unterbrechen, wodurch die Notwendigkeit einer Abfrage oder Nachrichtenfilterung vermieden wird.

Wenn die Anwendung keine Kommunikationsanforderungen mit geringer Latenz hat, kann das über SPI verbundene externe Peripheriegerät diese Anforderungen vermutlich erfüllen.

Der Hauptgrund, das externe Modul nicht zu verwenden, wäre also die Kommunikation auf dem CAN-Bus mit geringer Latenz.