Ich arbeite an einem Projekt, das eine gute 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 zusammenzuwerfen. Was sind jedoch für größere Projekte 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 aber eine Vorstellung von der Nische.
Mir fallen nur zwei gängige Standardprotokolle für diese Nische ein:
Sehr oft, wenn die eingebetteten Programmierer in der Situation wie das OP sind, entwerfen sie ihre eigenen seriellen Kommunikationsprotokolle von Grund auf neu.
Einige eingebettete Systemprotokolle, von denen einige sehr einfach sind, sind unter Embedded Systems: Common Protocols aufgeführt , darunter:
Vielleicht wäre eines dieser Protokolle für Ihre Anwendung so wie es ist oder mit nur geringfügigen Anpassungen angemessen.
Ich würde selbst abstimmen und es so einfach wie möglich halten.
Ich habe mich mit vielen seriellen Protokollen für verschiedene Steuerungsanwendungen befasst, und einige Dinge, die ich Ihnen empfehlen kann, sind:
Als sehr einfaches Beispiel könnten Sie Ihre Daten in ASCII-Zeichen konvertieren und sie wie folgt in Start-/Stoppzeichen einfügen:
Um den Bytewert 0x7A zu senden, wären die gesendeten Daten (7A), wobei () die gewählten Start-/Stoppzeichen sind und 7 und A zwei ASCII-Zeichen sind. OK, es fügt eine Menge Overhead hinzu, aber es bedeutet, dass Sie mit einfacher 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 an einen XBee übergeben wird, entweder intakt ankommt oder überhaupt nicht. Gestalten Sie Ihr Protokoll um die Übertragung von Chunks von 1–255 Bytes herum und überlassen Sie es den XBee-Modulen, sich darum zu kümmern, wie die Daten in jedem Chunk zu übermitteln sind. Machen Sie sich keine Sorgen um die Aufrechterhaltung der Integrität einzelner Pakete oder der Unterteilungen zwischen ihnen. Die Digi-Module werden dafür gute Arbeit leisten. Das Größte, worüber Sie sich Sorgen machen müssen, ist die Tatsache, dass selbst wenn der Knoten, der ein Paket überträgt, glaubt, dass es nicht zugestellt wurde, und einen Ersatz sendet, der Empfänger es am Ende trotzdem erhält – möglicherweise sogar nachdem er den Ersatz erhalten hat. Die Dinge können am einfachsten sein, wenn Sie Ihr Protokoll so gestalten, dass eine Seite der "Master" ist; Wenn der Master nach einem Datenstück fragt, sollte der Slave es einmal senden und sich nicht darum kümmern, ob der Master es bekommt. Wenn der Master die gewünschten Daten nicht erhält, kann er sie erneut anfordern.
Der Slave sollte Daten irgendeine Art von Sequenznummern zuweisen, und der Master sollte Anfragen, die den Slave-Status ändern, Sequenznummern zuweisen. Wenn die Anfrage des Masters die Form hat "sende das erste Element, dessen Sequenznummer größer als XXX ist", und jedes Datenelement des Slaves seine eigene Sequenznummer und die des vorherigen Elements enthält (falls sie nicht fortlaufend nummeriert sind). ), können spät ankommende Pakete den Slave dazu veranlassen, Daten redundant an den Master zu senden, aber der Master wird keine Schwierigkeiten haben, die daraus resultierenden spät ankommenden Antworten zu ignorieren. Wenn der Slave eine Zustandsä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. Controllerseitig werden Arduino und PICduino unterstützt, aber das sollte nicht zu schwer sein, auf einen bloßen Mikrocontroller zu portieren.
Ich hatte eine ähnliche Frage und fand nie etwas, das einfach und klein genug für kleine AVRs usw. war. Also habe ich etwas gedreht, das von CAN inspiriert ist. Es heißt MIN (Microcontroller Interconnect Network):
https://github.com/min-protocol/min
Hier habe ich darüber gebloggt:
https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/
Es gibt dort Haken für Blockdaten, aber es zielt hauptsächlich auf Signale für Sensoren/Aktoren ab. Ich habe ein JSON-Format zum Beschreiben von Signalen und deren Verpackung in MIN-Frames definiert und hoffe, einen Wireshark-Dissector zu bekommen, der es verwendet.
Benutzer17592
Computerisch
Benutzer17592
Computerisch
Chris Stratton