Gute RS232-basierte Protokolle für die eingebettete Computerkommunikation

Ich arbeite an einem Projekt, das ein gutes Stück Datenkommunikation zwischen einem entfernten Arduino und einem Computer beinhaltet. Die drahtlose Verbindung erfolgt über ein Paar XBees, sodass wir eine RS232-Verbindung zwischen dem Arduino und dem Computer haben. Für kleine Datenmengen ist es einfach genug, ein einfaches Kommunikationsprotokoll zusammenzustellen. Was sind jedoch für größere Projekte einige gute einfache Kommunikationsprotokolle?

Ich habe mir MODBUS angesehen, was eine praktikable Option zu sein scheint, aber ich wollte sehen, ob es andere bessere Optionen gibt.

Das OP fordert ein serielles Protokoll für eine Situation an, in der " nicht viele [Daten] und Geschwindigkeit kein großes Problem sind ". MODBUS wird im OP erwähnt. MODBUS über RS-485 ist kein schnelles Protokoll. Dies ist zwar keine Spezifikation, gibt jedoch eine Vorstellung von der Nische.

Ich kann mir nur zwei gängige Standardprotokolle für diese Nische vorstellen:

• NEMA 0183 . Nur-Text-ASCII-Protokoll. Für Menschen lesbar. Nur Punkt zu Punkt. Unterstützt keinen Multi-Drop-Bus.
• MODBUS, der bereits im OP erwähnt wurde

Sehr oft, wenn sich die eingebetteten Programmierer in einer Situation wie dem OP befinden, entwerfen sie ihre eigenen seriellen Kommunikationsprotokolle von Grund auf neu.

Einige eingebettete Systemprotokolle, von denen einige äußerst einfach sind, sind unter Embedded Systems: Common Protocols aufgeführt , darunter:

• Winziges eingebettetes Netzwerk (TEN)
• Mikrocontroller-Interpreter für vernetzte eingebettete Systeme (MINEN)
• Noch ein skalierbares Protokoll (YASP)
• Local Interconnect Network (LIN)
• Serial Servo Controller (SSC)
• Robot Operating System serial (rosserial)
• Netzstring
• verschiedene Feldbusse
• Modbus
• Controller Area Network (CAN)
• Firmata (Danke, Jippie!)

Möglicherweise ist eines dieser Protokolle für Ihre Anwendung unverändert oder mit nur geringfügigen Änderungen geeignet.

Ich würde selbst abstimmen und es so einfach wie möglich halten.

Ich habe für verschiedene Steuerungsanwendungen mit vielen seriellen Protokollen behandelt, und ein paar Dinge , die ich kann empfehlen Sie enthalten sind:

• Start & Stopp-Zeichen, die an keiner anderen Stelle verwendet werden
• Eine Art Prüfsummen- / Fehlerprüfung
• Einige Methoden zur Flusskontrolle / Signalisierung, insbesondere wenn Sie bidirektionale Kommunikation benötigen.

Als sehr einfaches Beispiel können Sie Ihre Daten in ASCII-Zeichen konvertieren und in Start / Stopp-Zeichen wie folgt einfügen:

Um den Bytewert 0x7A zu senden, wären die gesendeten Daten (7A), wobei () die gewählten Start / Stopp-Zeichen und 7 und A zwei ASCII-Zeichen sind. OK, es fügt viel Overhead hinzu, aber es bedeutet, dass Sie mit grundlegender Terminalsoftware debuggen können.

Wenn Ihre Daten XBees durchlaufen, sollten Sie die Module mit Escape-Zeichen in den API-Modus versetzen, Ihre Daten in logische Pakete aufteilen und die Tatsache nutzen, dass im API-Modus ein Paket, das einem XBee übergeben wird, entweder intakt ankommt oder keineswegs. Entwerfen Sie Ihr Protokoll für die Übertragung von Blöcken von 1 bis 555 Byte und lassen Sie die XBee-Module sich Gedanken darüber machen, wie die Daten in jedem Block bereitgestellt werden sollen. Machen Sie sich keine Sorgen um die Integrität einzelner Pakete oder die Unterteilungen zwischen ihnen. Die Digi-Module werden sich gut darum kümmern. Das größte Problem, über das Sie sich Sorgen machen müssen, ist die Tatsache, dass der Empfänger, selbst wenn der Knoten, der ein Paket sendet, glaubt, dass es nicht zugestellt wurde, einen Ersatz sendet, diesen möglicherweise trotzdem erhält - möglicherweise sogar, nachdem er den Ersatz erhalten hat. Am einfachsten ist es, wenn Sie Ihr Protokoll so gestalten, dass eine Seite der "Master" ist. Wenn der Master nach Daten fragt, sollte der Slave diese einmal senden und sich keine Gedanken darüber machen, ob der Master sie erhält. Wenn der Master die gewünschten Daten nicht erhält, kann er sie erneut anfordern.

Der Slave sollte Daten eine Art Sequenznummer zuweisen, und der Master sollte Anforderungen, die den Slave-Status ändern, Sequenznummer zuweisen. Wenn die Anforderung des Masters die Form "Senden Sie das erste Element, dessen Sequenznummer größer als XXX ist" hat und jedes Datenelement vom Slave seine eigene Sequenznummer und die des vorherigen Elements enthält (wenn sie nicht fortlaufend nummeriert sind) ) können spät ankommende Pakete dazu führen, dass der Slave redundant Daten an den Master sendet, aber der Master wird keine Schwierigkeiten haben, die daraus resultierenden spät ankommenden Antworten zu ignorieren. Wenn der Slave eine Statusänderungsanforderung empfängt, deren Sequenznummer unter der einer früheren Anforderung liegt, sollte er diese Anforderung ignorieren, da sie bereits vor dem Empfang ersetzt wurde.

Wie wäre es mit Firmata ? Es unterstützt verschiedene Betriebssysteme und Programmiersprachen. Controller-Seite Arduino und PICduino werden unterstützt, aber das sollte nicht zu schwierig sein, um es auf einen nackten Mikrocontroller zu portieren.

Ich hatte eine ähnliche Frage und fand nie etwas Einfaches und Kleines, das für kleine AVRs usw. geeignet war. Also rollte ich etwas, das von CAN inspiriert war. Es heißt MIN (Microcontroller Interconnect Network):

https://github.com/min-protocol/min

Ich habe hier darüber gebloggt:

https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

Es gibt dort Hooks für Blockdaten, die jedoch hauptsächlich auf Signale für Sensoren / Aktoren abzielen. Ich habe ein JSON-Format zur Beschreibung von Signalen und deren Packung in MIN-Frames definiert und hoffe, einen Wireshark-Dissektor zu erhalten, der es verwendet.