Ich denke, die Implementierung des CAN-Protokolls nur in Firmware wird schwierig sein und eine Weile dauern, bis es richtig ist. Es ist keine gute Idee.

Ihre Preise sind jedoch hoch. Ich habe gerade nachgesehen, und ein dsPIC 33FJ64GP802 im QFN-Gehäuse wird für 3,68 USD bei Microchipdirect für 1000 Stück verkauft. Der Preis wird für reale Produktionsmengen niedriger sein.

Das Hardware-CAN-Peripheriegerät 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 entschlossen zu sein scheinen, die Firmware-Route auszuprobieren, sind hier einige der offensichtlichen Probleme, die Ihnen in den Sinn kommen. Es wird höchstwahrscheinlich andere Probleme geben, die mir noch nicht aufgetreten sind.

Sie wollen CAN mit 20 kbit/s machen. Das ist eine sehr langsame Rate für CAN, die für mindestens 10 Sekunden von Metern bis zu 1 Mbit / s erreichen. Um Ihnen einen Datenpunkt zu geben, ist der NMEA 2000-Schiffssignalisierungsstandard auf CAN mit 200 kbit/s geschichtet, und das soll von einem Ende eines großen Schiffes zum anderen gehen.

Sie denken vielleicht, dass Sie nur einen Interrupt pro Bit brauchen und in diesem Interrupt alles tun können, was Sie brauchen. Das wird nicht funktionieren, weil in jeder CAN-Bitzeit mehrere Dinge passieren. Auf der Unterbitebene müssen insbesondere zwei Dinge 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 antreibt. Beide Leitungen werden um insgesamt 60 Ω zusammengezogen. Ein normaler CAN-Bus, wie er von gängigen Chips wie dem MCP2551 implementiert wird, sollte an beiden Enden 120-Ω-Terminatoren haben, also insgesamt 60 Ω, die die beiden Differenzleitungen passiv zusammenziehen. Der dominante Zustand ist, wenn beide Linien aktiv auseinander gezogen werden, irgendwo um 900 mV vom rezessiven Zustand entfernt, wenn ich mich recht erinnere. Im Grunde ist dies wie ein Open-Collector-Bus, außer dass er mit einem Differenzialpaar implementiert ist. Der Bus ist rezessiv, 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 auf den Bus "schreibt" (ihn loslässt), prüft er, ob ein anderer Knoten eine 0 schreibt. Wenn Sie den Bus im dominanten Zustand (0) finden, wenn Sie glauben, dass Sie senden, und Wenn das aktuelle Bit, das Sie senden, eine 1 ist, bedeutet dies, dass jemand anderes auch sendet. Kollisionen spielen nur eine Rolle, wenn die beiden Sender sich nicht einig sind, und die Regel lautet, dass derjenige, der den rezessiven Zustand sendet, sich zurückzieht und seine Nachricht abbricht. Der Knoten, der den dominanten Zustand sendet, weiß nicht einmal, dass dies passiert ist. So funktioniert die Arbitrierung auf einem CAN-Bus.

Die CAN-Bus-Arbitrierungsregeln bedeuten, dass Sie den Bus auf halbem Weg durch jedes Bit, das Sie als 1 senden, beobachten müssen, um sicherzustellen, dass jemand anderes keine 0 sendet. Diese Überprüfung wird normalerweise nach etwa 2/3 des Bits durchgeführt , und ist die grundlegende Begrenzung der CAN-Buslänge. Je langsamer die Bitrate, 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 daher sein. Diese Prüfung muss jedes Bit durchgeführt werden, wo Sie denken, dass Sie den Bus besitzen und ein 1-Bit senden.

Ein weiteres Problem ist die Anpassung der Bitrate. Alle Teilnehmer an einem Bus müssen sich auf die Bitrate einigen, enger als bei RS-232. Um zu verhindern, dass sich kleine Taktunterschiede zu erheblichen Fehlern summieren, muss jeder Knoten in der Lage sein, etwas länger oder kürzer als sein Nennwert zu tun. In der Hardware wird dies implementiert, indem eine Uhr etwa 9x bis 20x schneller als die Bitrate läuft. Die Zyklen dieser schnellen Uhr heißen Zeitquanten. Es gibt Möglichkeiten, um zu erkennen, dass der Anfang neuer Bits in Bezug auf die Stelle wandert, an der sie Ihrer Meinung nach sein sollten. Hardware-Implementierungen fügen dann ein Zeitquantum in einem Bit hinzu oder überspringen es, um es erneut zu synchronisieren. Es gibt andere Möglichkeiten, wie Sie dies implementieren könnten, solange Sie sich an kleine Phasenunterschiede zwischen Ihren erwarteten Bitzeiten und den tatsächlich gemessenen Bitzeiten anpassen können.

In jedem Fall erfordern diese Mechanismen, dass verschiedene Dinge zu verschiedenen Zeiten innerhalb eines Bits erledigt 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 sicherlich mit so etwas wie einem dsPIC 33F möglich, wird aber einen erheblichen Teil des Prozessors verbrauchen. Bei der maximalen Befehlsrate von 40 MHz erhalten Sie 222 Befehlszyklen pro Interrupt. Es sollte nicht so lange dauern, alle Überprüfungen durchzuführen, aber wahrscheinlich 50-100 Zyklen, was bedeutet, dass 25-50 % des Prozessors für CAN verwendet werden und alles andere, was läuft, unterbinden muss. Das verhindert viele Anwendungen, die diese Prozessoren oft ausführen, wie Puls-für-Puls-Steuerung eines Schaltnetzteils oder Motortreibers. Die Latenz von 50-100 Zyklen bei jedem zweiten Interrupt wäre ein kompletter Showstopper für viele der Dinge, die ich mit solchen Chips gemacht habe.

Sie werden das Geld also ausgeben, um CAN irgendwie zu machen. Wenn nicht in dem für diesen Zweck vorgesehenen dedizierten Hardware-Peripheriegerät, dann in einem größeren Prozessor, der den erheblichen Firmware-Overhead handhabt und sich dann mit der unvorhersehbaren und möglicherweise großen Interrupt-Latenz für alles andere befasst.

Dann gibt es das Up-Front-Engineering. 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 scheint mir ein Schnäppchen zu sein. Wenn Sie kein Produkt mit sehr hohen Stückzahlen haben, werden Sie auf keinen Fall die erhebliche Zeit und die Kosten zurückerhalten, die erforderlich sind, um CAN nur in Firmware zu implementieren. Wenn Ihr Volumen so hoch ist, sind die genannten Preise sowieso nicht realistisch, und die Differenz zum Hinzufügen der CAN-Hardware wird geringer sein.

Ich sehe das wirklich nicht sinnvoll.

Wir verwenden den PIC18F25K80 . Obwohl es keinen DSP hat, kostet es ~ $ 2 in der Menge. Es ist fast ein direkter Ersatz für den von Ihnen erwähnten PIC18F2480. Wir verwenden den CCS -Compiler und seinen Software-Stack für CAN, der wahrscheinlich von Microchip portiert wurde. Es funktioniert gut für alles, was ich brauchte und ausprobiert habe.

Wenn ich das richtig lese, klingt es so, als wollten Sie die CAN-Funktionalität nur mit einem UART und einer cleveren Firmware bit-bashen. Vertrauen Sie mir, das wird nie funktionieren - ich schlage vor, einen guten Text über die Feinheiten von CAN oder CANopen zu lesen. Sie haben alle Kosteneinsparungen, die Sie suchen, ausgelöscht, indem Sie diesen Weg eingeschlagen haben.

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

Ich denke auch über das Bit-Banging des CAN-Protokolls 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 erhalten haben. Vielen Dank!

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

Aber in UART/V24/RS232 wird Vollduplex meistens verwendet, ohne darüber im Detail nachzudenken, also müssen Sie vielleicht etwas Gehirn in den Superloop oder die Zustandsmaschine Ihrer Anwendung stecken ...

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

Zumindest wenn man nur das Rücklesen betrachtet... Das Senden würde einen gewissen Aufwand bedeuten, die Bitstrukturen so aufzubereiten, dass nicht 100% Buslast erreichbar wären, aber bei CAN sind mehr als 65% überhaupt selten...