Wir brauchten ein rauschunempfindliches, kostengünstiges Multidrop-, Multi-Master-Protokoll (Echtzeit und verteilt), und es scheint, dass nur der CAN-Bus diese Anforderungen erfüllt.
Da es keine CAN-Controller (Datenverbindungsschicht-Hardware) für sehr kostengünstige MCUs (wie STM32F0) und keine einfach zu verwendende API gibt, die wir für den Einstieg finden konnten, können wir den CAN-Bus nicht als Standard-Kommunikationsstack unserer Projekte betrachten .
Ich denke also, ich kann eine wirklich winzige Schicht implementieren, die es ermöglicht, jedes Protokoll (wie Modbus) über UART über die physikalische Schicht von CAN zu implementieren und gleichzeitig die Datenkollisionserkennung zu nutzen, indem 1 Startbyte als Köder verwendet wird.
Außerdem nehme ich an, dass jede I2C- oder 1-Wire-Hardware mit einem einfachen Dioden-Widerstands-Hack, ähnlich dem 1-Wire <-> uart-Dioden-Widerstands-Hack, direkt einen CAN-Sender für ihr Busprotokoll verwenden kann.
Ich vermute, dass mir etwas fehlt, da dieser Ansatz mit relativ geringem Aufwand viele Vorteile bringt, obwohl ich für diesen Zweck keine Implementierung finden konnte.
Gibt es versteckte Konsequenzen für diese Umfrage?
1-Wire (mit UART-Hack) funktioniert nicht über den CAN-Transceiver MCP2551, da der Transceiver am Endpunkt (der 1-Wire-Seite) beginnt, sich selbst mit Null (dominant) zu füttern, wodurch verhindert wird, dass ein Gerät "1" auf den Bus schreibt bis die Funktion "permanente TXD-Erkennung" des Transceivers die Kontrolle übernimmt. Aus Sicht des "einfachen 1-Wire-Range-Extenders" ist es also unbrauchbar. Das bedeutet, dass die RXD/ TXDPins eines CAN-Bus-Transceivers nicht mit einem einfachen 1-Wire / Uart-Konverter-Hack in eine Open-Drain-Leitung umgewandelt werden können, sodass es auch nicht mit einem I2C-Bus funktioniert.
Die Verwendung von 1 Byte als Köder ist nicht leistungsfähig, da wir nur 1 Bit als Null verwenden müssen, was bedeutet, dass wir 100 Bit nur für die Adressierung verwenden müssen, wenn wir vorhaben, 100 Geräte an denselben Bus anzuschließen, da wir zwar erkennen könnten, dass jemand anderes ist gleichzeitig sprechen, aber wir können die Priorität nicht erkennen (z. B. wenn node#0b101und node#0b011gleichzeitig spricht, werden wir lesen, 0b001was genau die gleiche Antwort ist, wenn node#0b011und node#0b001spricht. Wir node#011werden also nie wissen, ob es die Priorität hat oder nicht.) Also Dies ist unmöglich, wenn wir nicht eine Bit-Banging-Technik anwenden und den RXPort Stück für Stück lesen. Was keinen Sinn macht, weil es den CAN-Bus wie erwähnt neu erfindet.
Insgesamt würde ich CAN den ganzen Weg verwenden. Sie benötigen auf die eine oder andere Weise einen Leitungstreiber / Empfänger. CAN-Transceiver sind so gut wie alle anderen, aber dann ist es einfacher, den Rest von CAN zu verwenden. Der wesentliche Unterschied zu CAN besteht darin, dass die unteren Ebenen des Protokolls gut durchdacht und in vielen Mikrocontrollern direkt integriert kostengünstig verfügbar sind. RS-485 wirft Ihnen eine elektrische Spezifikation zu, dann sind Sie auf sich allein gestellt.
Es ist viel schwieriger, alle Details eines Multidrop-Busses richtig und robust zu machen, als die meisten Leute glauben. Benutzen können. Es wurde alles für Sie ausgearbeitet und erledigt. Sie senden ganze Pakete auf Firmware-Ebene. Die Hardware kümmert sich um Kollisionserkennung, Wiederholung und CRC-Prüfsummenerzeugung und -validierung. Das sind alles Dinge, die Sie wollen, und mit CAN bekommen Sie sie praktisch kostenlos.
Es gibt diskrete Controller (MCP2515), die SPI und einige andere GPIOs benötigen.
Es ist nicht wahr, dass CAN auf kleinen Cortex m0-Teilen nicht verfügbar ist. Schauen Sie sich LPC11C22 an; Es hat einen eingebauten CAN-Transceiver. Oder der STM32F042. NXP kostet 3 $, STM32 etwa 2 $, erfordert aber einen externen Transceiver, der die Kosten erhöht.
Wenn die zusätzlichen Kosten für ein Teil mit CAN-Controller nicht in Ihr Projekt passen, nehme ich an, dass Sie eine sehr hohe Designgebühr verlangen müssen, um Ihr eigenes Software-CAN-System zu erfinden und in der Lage zu sein, die Gewinnschwelle zu erreichen. Das Erstellen von Testfällen und der Nachweis, dass Ihr eigenes Datenbussystem zuverlässig, rauschunempfindlich, bitfehlerfrei, Kollisionserkennung, Busarbiter usw. ist, ist nicht einfach.
Genau das habe ich einmal gemacht. Ich weiß nicht, ob es immer noch kompiliert (ich benutze jetzt Wireless), aber es funktioniert sehr gut, wenn Sie alles richtig machen.
Microchip hatte früher einen CAN-Chip, der häufig ausfiel, wenn zu viel Gleichtaktspannung oder ähnliches vorhanden war. Netzteile könnten den Fehlermodus mit ihrem undichten AC-Mist IIRC auslösen. Dann kamen sie mit einer neuen Version heraus. Ich habe die Teilenummer vergessen, aber recherchieren Sie.
I2C braucht jedoch einen komplizierteren Hack. Der Transceiver kann normalerweise nicht in beide Richtungen arbeiten, ohne dass ein intelligenterer Chip ihm mitteilt, welche Richtung verwendet wird (diese existieren jedoch tatsächlich). MCU UART hat dieses Problem nicht, da der Mikrocontroller die separaten TX- und RX-Pins des Transceivers kennt, I2C verwendet bidirektionale Drähte.
David Tweed
feier