Hallo Leute Bin gerade mit einer Ansteuerung eines Atmega168 per Laptop beschäftigt. Die Kommunikation realisiere ich per USB. Diese funktioniert soweit problemlos. Nun möchte ich ein eigenes Kommunikationsprotokoll zwischen Laptop und Mikrocontroller definieren. Es werden Steuerbefehle sowie Daten bidirektional zwischen den beiden Teilnehmern ausgetauscht. Da ich noch nie ein eigenes Protokoll implementiert habe, frage ich hier mal nach ob meine Ideen der Praxis entsprechen. Ich hab mir vorgestellt, dass die Datenpakete wie folgt aussehen: STX | Data Length | Data | CRC Dabei habe ich folgendes definiert: STX = 0x02 ACK = 0x06 NACK = 0x15 diverse Befehle = 0x10 bis 0x14 Meine Überlegungen waren folgende: 1. Die Kommunikation soll mit einem definierten Zeichen beginnen, wird ein anderes Zeichen empfangen, bevor ein STX angekommen ist, wird das empfangene verworfen. 2. Da ein Datenwert gleich dem STX Wert sein kann, gebe ich die Länge der folgenden Daten an. Somit kann ein Datenwert nicht als Startwert missverstanden werden 3. Die Daten bestehen entweder aus einem einzelnen der definierten Befehle, bzw Antworten oder aus Messwerten, welche der uC dem PC überträgt 4. Als CRC habe ich einfachheitshalber eine XOR Verknüpfung über die Daten vorgesehen. Ist dies sicher genug oder sollte zwingend ein CRC-8 oder CRC-16 verwendet werden? 5. Jedes empfangene Datenpaket wird entweder mit einem ACK oder NACK beantwortet. ACK signalisiert eine korrekte Übertragung und NACK signalisiert ein nicht verstandener Befehl und der Kommunikationspartner wird gezwungen, das Frame erneut zu senden. Wie findet ihr meine Grundüberlegungen? Eigentlich handelt es sich um eine überschaubare Menge von Befehlen und Datenaustauschen. Ist mein Protokoll trotzdem geeignet oder ist es für mein Vorhaben schon zu aufwändig? Die Länge des USB Kabels beträgt rund 5m. Die Umgebung, in welcher das Ganze zum Einsatz kommt, verzeichnet nicht viele Störsignale. Ist daher ein CRC Check nötig? Ich hoffe ihr könnt mir auf den richtigen Pfad helfen und meine Fragen beantworten. Für Verbesserungsvorschläge bin ich natürlich sehr dankbar. Grüsse stefan
Stefan schrieb: > Ich hab mir vorgestellt, dass die Datenpakete wie folgt aussehen: > > STX | Data Length | Data | CRC > > Dabei habe ich folgendes definiert: > > STX = 0x02 > ACK = 0x06 > NACK = 0x15 > diverse Befehle = 0x10 bis 0x14 Ist schon in Ordnung und macht Sinn. Denke aber bitte daran, wie du die Kommunikation debuggen willst bzw. ob der Aufwand gerechtfertigt ist. Willst du nur eine handvoll Befehle vom Laptop zum Controller senden, fände ich das Overhead. Die USB-Verbindung ist nicht so störanfällig, dass du unbedingt CRC oder STX bräuchtest (unter der Annahme, dass der USB/232-Wandler nahe dem Controller sitzt!). > Wie findet ihr meine Grundüberlegungen? Eigentlich handelt es sich um > eine überschaubare Menge von Befehlen und Datenaustauschen. Ist mein > Protokoll trotzdem geeignet oder ist es für mein Vorhaben schon zu > aufwändig? Die Länge des USB Kabels beträgt rund 5m. Die Umgebung, in > welcher das Ganze zum Einsatz kommt, verzeichnet nicht viele > Störsignale. Ist daher ein CRC Check nötig? Grundsätzlich ist deine Idee gut. Aber denke mal praktisch: musst du unbedingt ein Binärprotokoll verwenden? ASCII-Daten sind leichter zu debuggen und eine BCD-Wandlung ist nicht übermäßig teuer. 'Ne Statemachine musst du dir eh bauen für den Receiver und so haste die Möglichkeit, auch ohne PC-Software deinen Controller nur über's Hyperterminal zu steuern. Und gerade bei Synchronisierungsfragen hilft dir das mehr als selbstgeschriebene Software. Falls es unbedingt ein binäres Protokoll sein muss, würde ich dir empfehlen, dir ein gescheites Terminalprogramm zu organisieren - sowas wie Docklight (http://www.docklight.de). Macht die Sache deutlich einfacher.
Falls du USB-CDC nutzt -- wenn du nur einfache Texte (ein Komando eine Zeile) nimmst, kannst du ein Terminal-Programm zum testen nehmen. Verlorenen Zeichen sind eigentlich kein Problem. Normalerweise geht da eher die ganze USB-Verbindung verloren und das Betriebssystem initialisiert das Gerät neu.
Moin, Glückwunsch, du hast gerade 3964R neu erfunden :-) MfG
Stefan schrieb: > 2. Da ein Datenwert gleich dem STX Wert sein kann, gebe ich die Länge > der folgenden Daten an. Somit kann ein Datenwert nicht als Startwert > missverstanden werden Das funktioniert nicht. 1. Kannst du auch Datenwert + nächstes Byte als STX + Länge fehlinterpretieren. 2. Kannst du das zum Zeitpunkt des Empfangs des ersten Zeichens nicht entscheiden. Es hilft alleine auszuschliessen, dass die Mengen an Steuer- und Datenzeichen disjunkt sind. Dies kann man a) durch eine eindeutige Anordung erreichen (die du ja eben nicht hast und durch das Steuerzeichen erst herstellen willst) oder b) durch eine Codierung der Datenzeichen, die eine Überdeckung mit den Steuerzeichen ausschließt. (z.B. 4B5B bei 100BASE-TX)
Schau dir eventuell das SLIP-Protokoll an, da werden auch Frames über eine serielle Verbindung geschickt. Ist auch sehr einfach zu implementieren...
Stefan schrieb: > STX | Data Length | Data | CRC Sowas ist noch kein Protokoll. Frag dich lieber zu allererst, was du da eigentlich übertragen willst. Dateien? Texte? Kommandos? Screenshots und anderes binäres? Dann frag dich, wer hier mit wem kommunizieren will, der PC mit dem µC oder beide miteinander? Als nächstes: was ist mit Daten, Kommandos usw. die der jeweilige Empfänger nicht versteht, weil z.B. noch nicht implementiert? Und noch eins zum Schluß, falls du Kommandos geben willst: Mache wenn möglich atomare Kommandos, also solche, die nur eine einzige Wirkung haben und anderen kommandos nichtin die Quere kommen. Obendrein ist es besser, grundsätzlich den einzigen Parameter eines Kommandos VOR dem Kommando zu schicken. Das macht die Dekodierung und Ausführung klarer und einfacher. W.S.
Wie sicher muss die Übertragung sein? Da der verwendete µC nicht direkt USB spricht, sondern offenbar über UART arbeitet, besteht die Möglichkeit, dass er sich in eine laufende Übertragung in den Bitstrom mittendrin aufschaltet. Wenn es dann aufgrund der Zufälle der Daten passieren kann, dass er diesen als gültig ansieht, dann hast du evtl. ein Problem. Das wird nicht oft geschehen, kann aber in seltenen Fällen passieren. Eine CRC16 sichert dieses ziemlich gut ab, CRC8 oder XOR weniger gut. Eine gezielte Pause vor dem Start eines Frames stellt auch sicher, dass die Bytesynchronisation der UART korrekt aufsetzt. Krasser Fall: Bei einem pausenlosen Bitstrom aus 0x55 ist eine Bytesynchronisation unmöglich.
Wenn Du das über USB machst brauchst Du kein Protokoll. USB garantiert die sichere Datenübertragung sicher. Du schickst einfach immer (z.B.) 64 Bytes raus. Das wars.
Potter schrieb: > Wenn Du das über USB machst brauchst Du kein Protokoll. Und dann bist du aufgewacht.
Potter schrieb: > Wenn Du das über USB machst brauchst Du kein Protokoll. USB garantiert > die sichere Datenübertragung sicher. Nur hat der ATmega168 kein natives USB.
Soll an dem Bus nur ein Teilnehmer sein also 1 PC und ein MC oder sollem da mehrere Teilnehmer Beteiligt sein? Soll es Master - Slave Struktur sein oder nicht?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.