Ich suche einen seriellen Bus, der adressierbare Knoten haben könnte, mit vielleicht max. 30 Knoten. Ich brauche keinen Multi-Master und die Geschwindigkeit ist kein Problem. Der Abstand zwischen den Knoten könnte etwa 20 Meter betragen. Je einfacher die Implementierung mit Microchip PIC-Mikrocontrollern ist, desto besser. I2c scheint ansonsten nett zu sein, aber es ist nicht dafür ausgelegt, bei solchen Entfernungen zu funktionieren.
Ich habe mir RS485, CAN, LIN usw. angesehen ... Zumindest für CAN und LIN gibt es in einigen PICs der höheren Serie integrierte Peripheriegeräte.
Welche Vor- und Nachteile haben diese und wie unterscheiden sie sich?
CAN ist definitiv der richtige Weg. Es gibt viele PICs, die ein CAN-Peripheriegerät eingebaut haben. Die elektrische Schnittstelle bis hin zur Paketschicht, einschließlich Prüfsummenerzeugung und -prüfung, ist alles in die Hardware eingebaut. Die Hardware handhabt auch die Kollisionserkennung und Übertragungswiederholung. Bei 20 Metern sollten Sie in der Lage sein, den CAN-Bus mit 1 Mbit/s zu betreiben, aber wenn die Geschwindigkeit keine Priorität hat, können Sie ihn ganz sicher mit 500 kbit/s betreiben.
RS-485 ist sehr altmodisch und lässt Sie in der Firmware viel mehr selbst machen. Die RS-485-Spezifikation gibt Ihnen nur die Signalpegel an und überlässt Ihnen den Rest. Sie können die UART-Hardware verwenden, um zumindest ganze Bytes zu senden und zu empfangen, aber Sie benötigen immer noch externe Hardware, um jeden Knoten explizit zwischen Senden und Empfangen umzuschalten, und dann Firmware, die weiß, wann umgeschaltet werden muss. CAN mag einschüchternd erscheinen, wenn Sie zum ersten Mal im Datenblatt über das Peripheriegerät lesen, aber nachdem Sie alle Protokollschichten für ein robustes geschrieben habenMulti-Node-Kommunikationsschnittstelle haben Sie viel mehr Aufwand betrieben als bei der Verwendung von CAN. Mit CAN senden und empfangen Sie ganze Pakete, die entweder eine 11- oder 29-Bit-ID und bis zu 8 Datenbytes enthalten. Die Hardware kümmert sich um das Senden und Empfangen dieser auf Paketebene, und Sie müssen sich keine Gedanken darüber machen, wer wann sendet, Master oder Slave usw.
Hören Sie nicht auf Leute, die in den 1990er Jahren stecken geblieben sind und immer noch RS-485 verwenden. Es gibt einen besseren Weg, und es gibt ihn schon eine Weile. Sie sollten bedenken, dass viele wichtige Protokolle, die im Pleistozän RS-485 waren, jetzt neuere Versionen haben, die CAN verwenden. Dazu gehören Automobil- und Schiffskommunikationsbusse.
RS-485 ist ziemlich gut. Es erfordert separate Treiberchips, aber die Verwendung solcher Chips hilft, den PIC vor jeglicher elektrischer Unannehmlichkeit im Bus zu schützen.
Wenn es einen Master geben wird, würde ich vorschlagen, dass Slave-Geräte so codiert werden, dass sie im Wesentlichen nie sprechen, außer als unmittelbare Reaktion auf eine Übertragung vom Master. Wenn der Master eine Operation anfordert, die eine Weile dauern könnte, sollte sie in zwei Befehle aufgeteilt werden: „Beginne mit XX“ und „Sag, ob du fertig bist“. Das Entwerfen von Protokollen auf diese Weise minimiert die Komplexität von Timing-Interaktionen zwischen dem Master und den Slaves. Der Master muss über eine Timeout-Logik für das Szenario verfügen, in dem er versucht, mit einem Slave zu sprechen, aber keine Antwort erhält, aber Slaves benötigen keine Timeout-Logik (außer vielleicht für eine Master-Watchdog-Funktion). Wenn der Master erfolgreich etwas an den Slave sendet, aber die Antwort des Slaves von einer zufälligen elektrischen Störung verschlungen wird, hört der Master die Antwort des Slaves nicht, wird seine Anfrage wiederholen; Der Slave, der die Neuübertragung hört, sendet seine Antwort erneut. Aus der Perspektive des Slaves kann die Bestätigung durch das Fehlen einer Neuübertragungsanforderung des Masters gefolgert werden.
Jon L
varesa