Implementierung einer CAN-Protokollschicht in Software

12

Hintergrund

Ich entwickle ein Projekt, das die bescheidenen Mikrocontrollerspezifikationen von erfordert:

  • 8 12-Bit-10-kHz-ADCs
  • 1 KB RAM
  • 48-QFN oder kleinerer Platzbedarf
  • 20 kbit / s Daisy-Chain-fähiges, rauschresistentes und fehlerkorrigierendes Kommunikationsprotokoll

Die Anforderungen an die Signalverarbeitung sind relativ gering und die meisten können an den Master-Prozessor im System exportiert werden. Die ersten drei Spezifikationen sind einfach zu erfüllen und können für weniger als 2 USD in Stückzahlen durchgeführt werden. Die Kommunikation findet jedoch in einer sehr lauten Umgebung statt, sodass lärmempfindliche Netzwerke wie LIN und I2C ausfallen. Ein weiteres Argument gegen LIN ist, dass ich das Ganze mit 5 V oder 3,3 V betreiben möchte und LIN-Transceiver 12 V benötigen und daher einen zusätzlichen Regler oder Kabel pro Sensorplatine benötigen würden. Für diese Aufgabe habe ich mich zunächst für CAN entschieden. CAN-Controller verursachen jedoch erhebliche Kosten, und ich bin gespannt, ob dies mit Software möglich ist.

CAN-Physical-Layer

Die CAN-Spezifikation definiert die Datenverbindung und die physikalischen Schichten des OSI-Netzwerkreferenzmodells. Es gibt viele kostengünstige 8-Pin-ICs, wie den NXP TJA1040 / 50 , den Maxim MAX3058 / 59 , den Microchip MCP2551 und den TI SN65HVD1050 , um die physikalische Schicht zu implementieren. Das Implementieren der physikalischen Schicht mit D / A-Wandlern oder Operationsverstärkern wäre schwierig, wenn nicht unmöglich, so dass diese ICs den Wert von 1 USD oder die damit verbundenen Kosten durchaus wert sind.

CAN-Datenverbindung / Protokollschicht

Für die Datenverbindungsschicht fügen einige Mikrocontroller CAN-Protokollmodule zu den grundlegenden UART-, I2C- und SPI-Kommunikationsschichten hinzu. Diese sind jedoch deutlich teurer als die Basischips.

Untersuchung der Kosten von CAN-Protokollmodulen

Um diese Behauptung zu untermauern, hier einige populäre Mikros in CAN- und Nicht-CAN-Versionen:

  • ATmega16 - ATMEGA16M1 (mit CAN): 3,87 USD, ATMEGA168A (ohne CAN): 3,23 USD
  • dsPIC - DSPIC33FJ64MC802 (mit CAN): 6,14 USD, DSPIC33FJ64GP202 (ohne CAN): 5,48 USD
  • PIC18 - PIC18F2480 (mit CAN): 6,80 USD, PIC18F24J10 (ohne CAN): 2,10 USD
  • Cortex-M3 - STM32F103C4T6A (mit CAN): 6,50 USD, STM32F100C4T6B (ohne CAN): 2,73 USD

Um fair zu sein, habe ich nur Mikrocontroller mit äquivalenten Speichergrößen verglichen. Viele der Nicht-CAN-Versionen sind jedoch mit kleineren Speichergrößen für weniger verfügbar. Externe CAN-Controller, wie der Microchip MCP2515 , kosten fast 2 US-Dollar. Wenn Sie die Option haben, ist es offensichtlich kostengünstiger , den CAN-Controller in den Mikrocontroller zu integrieren.

Interessanterweise ist das ATmega-Teil das mit Abstand billigste mit CAN ausgestattete Teil in Digikeys Inventar.

Funktion der CAN-Protokollschicht

Das in den dsPIC-Mikrocontrollern enthaltene CAN-Modul führt folgende Aktionen aus:

Das CAN-Bus-Modul besteht aus einer Protokoll-Engine und einer Nachrichtenpufferung / -steuerung. Die CAN-Protokoll-Engine übernimmt alle Funktionen zum Empfangen und Senden von Nachrichten auf dem CAN-Bus. Nachrichten werden übertragen, indem zuerst die entsprechenden Datenregister geladen werden. Status und Fehler können durch Lesen der entsprechenden Register überprüft werden. Jede auf dem CAN-Bus erkannte Nachricht wird auf Fehler überprüft und dann mit Filtern abgeglichen, um festzustellen, ob sie empfangen und in einem der Empfangsregister gespeichert werden soll.

Dies scheint in Software ziemlich machbar zu sein.

Die Frage

Kann eine Softwareprotokollschicht verwendet werden, um die CAN-Spezifikation nur mit einem kostengünstigen Mikrocontroller mit UART-Ausstattung und einem CAN-Transceiver zu implementieren? Wenn ja, gibt es Open-Source-Implementierungen?

Können alternativ CAN-Transceiver mit UARTs verwendet werden, um ein benutzerdefiniertes Protokoll zu implementieren? Ich bin mit einer Single-Master-Topologie einverstanden. Ich verstehe, dass es schwierig sein kann, ein Schiedsverfahren in einem benutzerdefinierten Protokoll durchzuführen.

Kevin Vermeer
quelle
CAN ist ebenfalls 12V, da es für den Automobilbereich entwickelt wurde.
Kenny
@Kenny - Die an den obigen Transceivern verwendeten Spannungspegel betragen 5V.
Kevin Vermeer
Wenn Sie die STM32F-Serie in Betracht ziehen, kann ich diesen NXP-Teil auch vorschlagen? Es ist ein Cortex-M0-Kern. search.digikey.com/scripts/DkSearch/…
Jon L
@ Jon - Diese wurden nicht unbedingt in Betracht gezogen, und ein M0 wäre ideal für diesen Anwendungsfall. - Berücksichtigen Sie jedoch, dass Teile des Nuvoton M052LAN ebenfalls Cortex-M0 sind und ungefähr die Hälfte der Menge kosten (1,21 USD gegenüber 2,35 USD) hat nicht das CAN-Modul. Diese Art von Preisunterschied ist meine Motivation.
Kevin Vermeer
Vielleicht möchten Sie auch die Betriebsbewertung berücksichtigen. Die meisten Teile mit CAN-Unterstützung werden für Nicht-CAN-Varianten industriell oder automobil oder kommerziell sein.
Mark

Antworten:

11

Ich denke, dass die Implementierung des CAN-Protokolls nur in Firmware schwierig sein wird und eine Weile dauern wird, bis das Problem behoben ist. Das ist keine gute Idee.

Ihre Preise sind jedoch hoch. Ich habe gerade nachgesehen und ein dsPIC 33FJ64GP802 im QFN-Paket wird für 3,68 USD bei microchipdirect für 1000 Stück verkauft. Bei realen Produktionsmengen ist der Preis niedriger.

Die Hardware-CAN-Peripherie erledigt einige echte Dinge für Sie, und die Preiserhöhung dafür ist bei weitem nicht das, was Sie behaupten.

Hinzugefügt:

Da Sie anscheinend entschlossen sind, die Firmware-Route auszuprobieren, sind hier einige der offensichtlichen Probleme aufgeführt, die Ihnen in den Sinn kommen. Es wird höchstwahrscheinlich noch andere Probleme geben, die mir noch nicht aufgefallen sind.

Sie möchten CAN mit 20 kbit / s ausführen. Das ist eine sehr langsame Geschwindigkeit für CAN, die für mindestens 10s Meter auf 1Mbit / s ansteigt. Um Ihnen einen Datenpunkt zu geben, ist der NMEA 2000-Bordsignalisierungsstandard auf CAN mit 200 kbit / s festgelegt, und das soll von einem Ende eines großen Schiffes zum anderen gehen.

Sie denken vielleicht, dass Sie nur einen Interrupt pro Bit benötigen und Sie können in diesem Interrupt alles tun, was Sie brauchen. Das funktioniert nicht, weil in jeder CAN-Bit-Zeit mehrere Dinge vor sich gehen. Insbesondere zwei Dinge müssen auf der Subbit-Ebene getan werden. Der erste erkennt eine Kollision und der zweite passt die Bitrate im laufenden Betrieb an.

Auf einem CAN-Bus gibt es zwei Signalisierungszustände: rezessiv und dominant. Rezessiv ist, was passiert, wenn nichts den Bus fährt. Beide Leitungen werden um insgesamt 60 Ω zusammengezogen. Ein normaler CAN-Bus, wie er von herkömmlichen Chips wie dem MCP2551 implementiert wird, sollte an beiden Enden 120 Ω-Abschlusswiderstände aufweisen, dh insgesamt 60 Ω, die die beiden Differenzleitungen passiv zusammenziehen. Der dominante Zustand ist, wenn beide Leitungen aktiv auseinandergezogen werden, ungefähr 900 mV vom rezessiven Zustand entfernt, wenn ich mich recht erinnere. Im Grunde ist dies wie ein Open-Collector-Bus, nur dass er mit einem differentiellen Paar implementiert ist. Der Bus befindet sich im rezessiven Zustand, wenn CANH-CANL <900 mV und dominant, wenn CANH-CANL> 900 mV. Der dominante Zustand signalisiert 0 und der rezessive 1.

Immer wenn ein Knoten eine 1 in den Bus "schreibt" (loslässt), prüft er, ob ein anderer Knoten eine 0 schreibt Das aktuelle Bit, das Sie senden, ist eine 1, was bedeutet, dass auch jemand anderes sendet. Kollisionen spielen nur dann eine Rolle, wenn sich die beiden Sender nicht einig sind, und die Regel lautet, dass derjenige, der den rezessiven Zustand sendet, seine Nachricht zurücknimmt und abbricht. Der Knoten, der den dominanten Zustand sendet, weiß nicht einmal, dass dies geschehen ist. So funktioniert Arbitration auf einem CAN-Bus.

Die CAN-Bus-Arbitrierungsregeln bedeuten, dass Sie den Bus während jedes gesendeten Bits als 1 beobachten müssen, um sicherzustellen, dass kein anderer Benutzer eine 0 sendet. Diese Überprüfung wird normalerweise etwa zu 2/3 auf dem Weg in das Bit durchgeführt und ist die grundlegende Einschränkung der CAN-Bus-Länge. Je langsamer die Bitrate ist, desto mehr Zeit bleibt für die Ausbreitung im ungünstigsten Fall von einem Ende des Busses zum anderen und desto länger kann der Bus sein. Diese Prüfung muss in jedem Fall durchgeführt werden, in dem Sie glauben, den Bus zu besitzen und ein 1-Bit-Signal zu senden.

Ein weiteres Problem ist die Anpassung der Bitrate. Alle Teilnehmer an einem Bus müssen sich enger als bei RS-232 auf die Bitrate einigen. Um zu verhindern, dass sich kleine Taktdifferenzen in signifikanten Fehlern ansammeln, muss jeder Knoten in der Lage sein, etwas länger oder kürzer als seine Nennleistung zu sein. In der Hardware wird dies implementiert, indem eine Uhr etwa 9x bis 20x schneller als die Bitrate ausgeführt wird. Die Zyklen dieser schnellen Uhr heißen Zeitquanten. Es gibt Möglichkeiten, um zu erkennen, dass der Beginn neuer Bits in Bezug darauf, wo Sie denken, dass sie sein sollten, wandert. Hardware-Implementierungen addieren oder überspringen dann ein Mal Quanten in einem Bit, um sie erneut zu synchronisieren. Es gibt andere Möglichkeiten, wie Sie dies implementieren können, solange Sie sich auf kleine Phasendifferenzen zwischen Ihren erwarteten und tatsächlich gemessenen Bitzeiten einstellen können.

In jedem Fall erfordern diese Mechanismen, dass verschiedene Dinge zu verschiedenen Zeiten innerhalb eines Bits ausgeführt werden. Diese Art von Timing wird in der Firmware sehr schwierig oder erfordert, dass der Bus sehr langsam läuft. Angenommen, Sie implementieren ein Zeitquantensystem in Firmware mit 20 kbit / s. Bei mindestens 9 Zeitquanten pro Bit würde dies einen 180 kHz-Interrupt erfordern. Das ist mit so etwas wie einem dsPIC 33F sicherlich möglich, verschlingt aber einen erheblichen Teil des Prozessors. Bei der maximalen Befehlsrate von 40 MHz erhalten Sie 222 Befehlszyklen pro Interrupt. Es sollte nicht so lange dauern, bis alle Überprüfungen durchgeführt sind, aber wahrscheinlich 50-100 Zyklen, was bedeutet, dass 25-50% des Prozessors für CAN verwendet werden und dass alles andere, was läuft, verhindert werden muss. Das verhindert, dass viele Anwendungen, die diese Prozessoren häufig ausführen, wie pulsweise Steuerung eines Schaltnetzteils oder eines Motortreibers. Die Latenz von 50-100 Zyklen bei jedem zweiten Interrupt wäre ein kompletter Show Stopper für viele Dinge, die ich mit solchen Chips gemacht habe.

Du wirst also das Geld dafür ausgeben, CAN irgendwie zu machen. Wenn es sich nicht um das für diesen Zweck vorgesehene dedizierte Hardware-Peripheriegerät handelt, müssen Sie dafür sorgen, dass ein größerer Prozessor den erheblichen Firmware-Overhead bewältigt, und dann die unvorhersehbare und möglicherweise große Interrupt-Latenz für alles andere bewältigen.

Dann gibt es die Vorausentwicklung. Das CAN-Peripheriegerät funktioniert einfach. Aus Ihrem Kommentar geht hervor, dass die zusätzlichen Kosten für dieses Peripheriegerät 0,56 US-Dollar betragen. Das kommt mir wie ein Schnäppchen vor. Solange Sie kein Produkt mit sehr hohen Stückzahlen haben, werden Sie auf keinen Fall die beträchtliche Zeit und die Kosten zurückbekommen, die für die Implementierung von CAN nur in Firmware erforderlich sind. Wenn Ihr Volumen so hoch ist, sind die genannten Preise ohnehin nicht realistisch, und der Unterschied beim Hinzufügen der CAN-Hardware ist geringer.

Ich sehe das wirklich nicht als sinnvoll an.

Olin Lathrop
quelle
Ich schätze Ihre Meinung, aber ich bin gespannt, warum niemand versucht hat, die Schwierigkeiten zu umgehen - jedes Projekt wird diese Probleme haben! Ich werde Sie wissen lassen, wie es ausgeht, wenn ich es versuche.
Kevin Vermeer
Bei Mengen von 1000 finde ich einen Preis von 3,12 USD für den dsPIC33FJ64GP202 von microchipdirect - eine Gesamtwertdifferenz von 560 USD! Zumindest lohnt es sich, es zu versuchen. Ich habe die Preise pro Stück angegeben, weil es einfacher war, Nummern für einzelne Teile zu erhalten, ohne sich um das Abwickeln, die Standardverpackungsmenge usw. kümmern zu müssen.
Kevin Vermeer
2
@ Kevin, niedrige Mengenpreise sind nicht immer proportional zu hohen Mengenpreisen. Ich weiß nicht, wie viele dieser Dinge Sie planen zu machen, aber 560 $ werden nicht anfangen, für das Engineering zu bezahlen, um CAN in Firmware zu machen. Ich werde noch einige der Schwierigkeiten erläutern, auf die Sie stoßen werden.
Olin Lathrop
WTF !? Ich habe meiner Antwort nur ein paar Dinge hinzugefügt, und der größte Teil des Absatzwechsels ist verschwunden. Es gab definitiv leere Zeilen im Bearbeitungsfenster, das ich eingab.
Olin Lathrop
1
Die Antwort lautet: Ja, das kannst du, aber ich stimme Olin hier voll zu. Ich arbeite eigentlich ganztägig in diesem Bereich. Ich benutze den Chip dsPIC33FJ256. Die Zeit, die aufgewendet wird, um die Dinge zum Schreiben zu bringen, verringert den Kostenvorteil, wenn Hardware dies für Sie erledigt und Sie das Rad neu erfinden. Ganz zu schweigen davon, dass alles, was Sie sonst noch an Hardware tun, sorgfältig geplant werden muss. Ich frage mich auch, ob Sie andere übergeordnete Protokolle wie ISO14229 oder OSEK / Autosar NetworkManagement benötigen.
Eric M
2

Wir verwenden den PIC18F25K80 . Es hat zwar keinen DSP, aber eine Menge von ~ 2 US-Dollar. Es ist fast ein direkter Ersatz für den PIC18F2480, den Sie erwähnen. Wir verwenden den CCS- Compiler und dessen Software-Stack für CAN, der wahrscheinlich von Microchip portiert wurde. Es funktioniert gut für alles, was ich gebraucht und ausprobiert habe.

kenny
quelle
Suche nicht nach ECAN. Blöder Mikrochip-Name, aber ich muss das nächste Mal genauer nachlesen! Wie ich bereits sagte, sind meine Anforderungen an die Signalverarbeitung gering, sodass ich glaube, dass ich keinen tatsächlichen DSP benötige.
Kevin Vermeer
2

Wenn ich das richtig lese, hört es sich so an, als ob Sie die CAN-Funktionalität nur mit einem UART und einer cleveren Firmware bitweise testen möchten. Vertrauen Sie mir, das wird niemals funktionieren. Ich empfehle Ihnen, einen guten Text über die Feinheiten von CAN oder CANopen zu lesen. Sie haben alle Kosteneinsparungen, die Sie suchen, auf diesem Weg beseitigt.

Ich würde entweder einen Mikrocontroller mit einem CAN-Modul verwenden und die zusätzlichen $ 2 weitergeben, oder Sie haben über ein anderes Protokoll nachgedacht, das mit einem UART kompatibel ist, wie z Modbus über RS-485 ?

BullBoyShoes
quelle
Du liest es richtig. Ich habe das Vector-Schulungsheft über CAN gründlich gelesen. Es sieht so aus, als ob für jede Nachricht eine Vorverarbeitung für CRC erforderlich ist, aber der Rest des Pakets sollte derselbe sein, und ich muss nur die Empfangsleitung auf einen Konflikt überprüfen. Es scheint wirklich nicht so schwer zu sein, wie die Leute es sich vorstellen, aber ich werde auf jeden Fall Ihren Rat berücksichtigen.
Kevin Vermeer
Ich mag den Modbus über RS485-Idee, obwohl. Es scheint, dass die meisten dieser Transceiver auch eine 5-V-Versorgung haben. Ich hatte den Eindruck, dass es eine +/- Eingangsspannung wie RS232 benötigt. Muss das untersuchen.
Kevin Vermeer
Bit Banging wird mit Sicherheit funktionieren! Es ist nicht trivial, wie Olin oben erwähnt, kann aber getan werden. Ich persönlich habe es sowohl mit einem PIC18F-Mikro als auch mit einem dsPIC33-Mikro geschafft. Ich kann die PIC18F-Quelle hochladen, wenn Sie sie wirklich sehen möchten. Ich kann die dsPIC-Quelle jedoch nicht preisgeben, da sie Teil eines kommerziellen Projekts ist, an dem ich arbeite. In beiden Fällen verwenden wir MCP2551 und ich habe auch LIN-Code. LIN ist auf der Protokollebene etwas einfacher, aber die Implementierung von LIN-Zeitplänen ist etwas schwieriger ...
Eric M
1
@EricM - Wie hoch war die Bitrate und konnten Sie die vollständige CAN-Spezifikation in Software implementieren? Ich würde gerne den PIC18F-Code dafür sehen.
Rocketmagnet
Ja, die vollständige CAN-Spezifikation wurde so implementiert, dass das ECAN-Modul auf dem dsPIC, das viele Aspekte berücksichtigt, nicht dupliziert wird. Bei der PIC18-Implementierung habe ich den Bus auf die volle Spezifikation und später gebockt, und dieser Code funktioniert auf einem dsPIC, der GPIO-Leitungen verwendet. Ich werde in ein paar Tagen mit Link zum Code aktualisieren.
Eric M
0

Ich denke auch über Bit-Banging-CAN-Protokoll auf einem PIC-µC nach, also bitte, EricM, wenn Sie das wirklich getan haben, antworten Sie bitte und sagen Sie zumindest, welche Bitrate bei welcher Kernfrequenz von PIC18F oder DSPic Sie haben. Danke!

Im Allgemeinen: RS 485 wäre die Lösung für das primäre gestellte Problem, aber es wäre auch möglich, CAN- (oder sogar FlexRay) -Transceiver mit Nicht-Vollduplex-UART-Kommunikation (Punkt 2 Punkt) als alle diese Protokolle zu verwenden benutze NRZ-Kodierung.

In UART / V24 / RS232 wird Vollduplex jedoch meistens verwendet, ohne sich eingehend mit dem Thema auseinanderzusetzen. Vielleicht müssen Sie also den Superloop oder die Statemachine Ihrer Anwendung genauer untersuchen ...

Aber zurück zum CAN-Bitbanging: Ich arbeite seit vielen Jahren mit CAN und habe noch nie eine Bitbanging-Implementierung gesehen, aber soweit ich das beurteilen kann, sollte das für Bit-Timings bis zu 100 kBit mit modernen µCs wie DSPic oder ARM usw. funktionieren. (mit Kernen bei 80 MHz oder höher ...)

Zumindest, wenn nur das Zurücklesen berücksichtigt wird ... Das Senden würde einen gewissen Aufwand bedeuten, wenn die Bitstrukturen so vorbereitet werden, dass nicht 100% der Buslast erreichbar sind, aber in CAN sind mehr als 65% überhaupt selten ...

roby111
quelle
2
Willkommen bei der Elektrotechnik StackExchange. Der erste Teil Ihrer Antwort ist überhaupt keine Antwort. Sie stellen eine neue Frage, wenn Sie dies wünschen. Das OP hat speziell nach der Software-Implementierung des CAN-Protokolls gefragt, und Ihre Antwort scheint zu wandern, ohne diese Frage zu beantworten. Bitte bleiben Sie beim Thema der Frage.
Joe Hass