uart-Kommunikationsprotokoll

Ich arbeite an einem Projekt, bei dem ich Befehle unterschiedlicher Länge von meinem PC an einen Mikrocontroller übermitteln muss. (mit usb to uart bridge) Ich mache bereits ein kleines Protokoll (Startbyte, einige Daten, Prüfsumme ...), aber ich muss es an meine neuen Bedürfnisse anpassen.

Ich frage mich, ob es dafür bereits einen Standard oder einen gemeinsamen Weg gibt.

Antworten (4)

Befehle mit variabler Länge

Viele Leute bevorzugen Befehle mit fester Länge. Wenn Sie Befehle mit variabler Länge benötigen, müssen Sie Folgendes bedenken:

  • Ist es möglich, dass versehentliches Rauschen (oder böswillige Witzbolde) etwas erzeugt, das meinen Empfangspuffer zum Überlaufen bringt?
  • Wenn ein wenig Rauschen das hohe Bit des "Längen"-Felds eines kurzen Pakets umdreht (was es wie ein langes Paket erscheinen lässt), erholt sich mein System dann ordnungsgemäß?
    • schlecht: Der Mikrocontroller stoppt alles und wartet auf den Rest von dem, was er für ein "langes" Paket hält. Einige Tage später, nach vielen hektischen Versuchen, ihm Nachrichten zu senden, die sagen: „Einsatz der Airbags“, „Senken Sie die Steuerstangen“, „Öffnen Sie die Kabinenschachttüren, HAL“ usw., erhält es schließlich alle Bytes, die es erwartet hat, sehen Sie das Die Prüfsumme schlägt fehl, wirft dieses "lange Paket" weg und beginnt wieder normal zu arbeiten.
    • Gut: Nach einer Minute oder einer anderen angemessenen Zeit läuft der Mikrocontroller ab, löscht alles im Befehlspuffer (möglicherweise verwirft er einige Meldungen zum Auslösen der Airbags nach der Meldung mit beschädigter Länge) und beginnt wieder normal zu arbeiten.
    • gut: Der Mikrocontroller erkennt sofort, dass der Header (der das Startbyte, das Längenfeld und die Prüfsumme des Headers enthält) einen Fehler enthält, verwirft diesen Header sofort und beginnt erneut mit der Suche nach dem Startbyte. Der Mikrocontroller beginnt sofort wieder normal zu arbeiten und erkennt den ersten gültigen Befehl (die Prüfsumme des Headers ist gut, und auch die Prüfsumme der Daten ist gut) nach dem beschädigten Befehl.
  • Sendet der Mikrocontroller sofort eine ACK, nachdem er sieht, dass die (endgültige) Prüfsumme des Pakets gut ist, führt er dann den Befehl aus und sendet schließlich eine Antwort auf diesen Befehl zurück? Oder ist es besser, nur das ACK oder nur die Antwort zu senden? Welche erleichtert das Debuggen?

Allgemeine Tipps zum Protokolldesign

Es gibt viele mehr oder weniger einfache Protokolle, die im Wikibook "Serial Programming" aufgeführt sind .

Wenn Sie Glück haben, ist vielleicht einer davon bereits perfekt für Ihre Anwendung. Oder zumindest nah genug, dass es nur ein wenig Anpassung erfordert, um zu passen.

So ziemlich jeder, der erfolgreich ein neues Protokoll entwickelt, durchläuft diese Phasen:

  • 1 Ich weiß vielleicht nicht viel, aber das Lesen der Protokolle anderer Leute bereitet mir Kopfschmerzen. Es sieht aus wie ein Haufen unnötiger Komplexität. Lassen Sie uns all das Zeug wegwerfen und ein nettes, einfaches Protokoll erstellen.
  • 2 Es funktioniert nicht. Vielleicht funktioniert es, wenn ich [Funktion 1] hinzufüge.
  • 3 Besser, funktioniert aber immer noch nicht sehr gut. Vielleicht [Feature 2] hinzufügen? ...
  • 98 Endlich funktioniert es. Ich schreibe besser auf, wer was in meinem einfachen Protokoll macht, damit ich mich daran erinnere, wie es geht, wenn ich auf einen anderen Mikrocontroller wechseln muss oder ein besseres Programm auf dem PC schreiben möchte.
  • 99 Komisch, wie viele Seiten es braucht, um mein einfaches Protokoll zu beschreiben.
Ich bin mit dem letzten Absatz nicht einverstanden. Die meisten einfachen seriellen Protokolle sind in der Tat einfach und Sie können mit nur einigen Paket-Timing-Anforderungen und CRC viel erreichen. Textbasierte serielle Protokolle ohne CRC sind eine ganz andere Sache.
Das Buch behauptet, es sei nicht möglich, dass ein Protokoll 8-Bit-sauber ist und gleichzeitig „einfaches Kopieren“ und „eindeutiger Start“ bietet. Diese Aussagen treffen nur zu, wenn man sich auf die 8-Bit-Datenübertragung beschränkt. Wenn man entweder eine 9-Bit-Datenübertragung verwendet oder BREAK-Zeichen verwendet, um den Paketstart anzuzeigen, kann man die anderen gesuchten Vorteile haben.
@supercat - Ah, 9-Bit-Übertragung. Sie haben recht – das ist eine eklatante Auslassung. Warte, während ich es repariere ... fertig. :-). Danke schön.
@davidcary: Gerne. Es kann sich lohnen, lange Unterbrechungszeichen als Sonderfall zu erwähnen, da selbst UARTs, die auf die Verarbeitung von 8-Bit-Daten beschränkt sind, häufig einige Vorkehrungen für Unterbrechungszeichen haben. Während es länger dauert, eine Unterbrechung zu senden als ein normales Zeichen, erfordert die Verwendung von Unterbrechungen für die Signalisierung keinen zusätzlichen Overhead für 8-Bit-Daten.
@supercat - Ja. Ich habe dieser Seite eine kurze Erwähnung der "langen Pause" hinzugefügt. Danke nochmal.
@davidcary: Schöne Beobachtung, dass die "lange Pause" für die Hayes-Escape-Sequenz effektiv eine andere Art von Symbol ist.

Es stehen viele Protokolle zur Verfügung. Einer meiner Favoriten ist der Modbus. Modbus-Protokoll

Dieser ist wirklich schön und einfach. Bleiben Sie einfach bei Modbus RTU und kümmern Sie sich nicht um die Standard-Funktionscodes.

Wenn es nur eine Master-Slave-Verbindung gibt, klingt es so, als hätten Sie alles getan, was Sie tun müssen. Verwenden Sie einen Standard-CRC-Prüfsummenalgorithmus, aber das ist alles, was Sie für eine sinnvolle Standardisierung benötigen. Machen Sie sich keine Sorgen über ein offizielles ISO/IEEE-Protokoll.

Ich weiß nicht, wofür Ihre Anwendung gedacht ist, aber wenn Sie versuchen, etwas in einem "definierten Markt" zu tun, dann recherchieren Sie diesen Markt und versuchen Sie, etwas zu verwenden, das dort implementiert ist. In SCADA ist Modbus in einer seiner zwei oder drei Versionen (zwei sind seriell und eine ist IP) eine gute Wahl. Bei CCTV ist Pelco D eine gute Wahl. Alle diese Protokolle sind einfach zu implementieren und dokumentiert. Außerdem gibt es noch andere Protokolle auf dem gleichen Markt, also haben Sie Spaß bei der Entscheidung, was Sie tun möchten. Jedes Protokoll, das Sie finden können, kann "verbessert" sein, aber wenn Sie vorhaben, eine Schnittstelle zu einigen "echten" Geräten herzustellen, verwenden Sie deren Protokoll, erfinden Sie nicht Ihr eigenes.

uart-Kommunikationsprotokoll
AntwortenHierDatenschutz-Bestimmungen1y, 0v