Protokolle verwendet, um zwischen einer eingebetteten CPU und einem PC zu sprechen

StackOverflow https://stackoverflow.com/questions/310826

Frage

Ich baue ein kleines Gerät mit einer eigenen CPU (AVR Mega8), die an einen PC angeschlossen werden soll. Unter der Annahme, dass die physikalische Verbindung und Weitergabe von Bytes erreicht worden, was wäre das beste Protokoll, das auf dieser Bytes zu benutzen? Der Computer muss in der Lage sein, bestimmte Spannungen auf dem Gerät zu setzen und bestimmte andere Spannungen zurückgelesen.

Im Moment denke ich ein völlig Host-driven synchrones Protokoll: Computer senden Anfragen, die eingebetteten CPU Antworten. Jede andere Ideen?

War es hilfreich?

Lösung

Modbus sein könnte, was Sie suchen. Es wurde für genau die Art von Problem entwickelt, die Sie haben. Es gibt eine Menge Code / Tools gibt und die Einhaltung einer Norm später einfache Wiederverwendung bedeuten könnte. Es ist auch für Menschen lesbare ASCII unterstützen, so dass es immer noch leicht zu verstehen / Test.

Siehe FreeModBus für Fenster und Embedded-Quelle.

Andere Tipps

Es gibt eine Menge an für die Client-Server-Architektur und synchrone Protokolle gesagt werden. Einfachheit und Robustheit, zu starten. Wenn die Geschwindigkeit ist kein Problem, könnte man ein kompaktes, für Menschen lesbaren Protokoll zu helfen, mit Debugging betrachten. Ich bin nach dem Vorbild des Modems AT-Befehle zu denken. „Aufgeweckt“ -Sequenz durch einen Satz gefolgt / get-Befehl, gefolgt von einem Terminator 

Host -->  [V02?]      // Request voltage #2
AVR  -->  [V02=2.34]  // Reply with voltage #2
Host -->  [V06=3.12]  // Set voltage #6
AVR  -->  [V06=3.15]  // Reply with voltage #6

Jede Seite Timeout könnte, wenn es nicht den Schließbügel nicht sehen, und sie würden auf der nächsten Klammer auf neu synchronisieren, die nicht in der Nachricht erscheinen selbst.

Je nach Geschwindigkeit und Zuverlässigkeit Anforderungen, können Sie die Befehle in ein oder zwei Bytes codieren und eine Prüfsumme hinzuzufügen.

Es ist immer eine gute Idee, mit der ist Spannung zu antworten, anstatt einfach Echo des Befehls, da es eine nachfolgende Leseoperation speichert.

Auch hilfreich Fehlermeldungen zu definieren, für den Fall, müssen Sie debuggen.

Meine Stimme ist für den Menschen lesbar.

Aber wenn Sie binäre gehen, versuchen, einen Header-Byte am Anfang setzen den Beginn eines Pakets zu markieren. Ich habe immer Pech hatte mit seriellen Protokollen nicht synchron zu bekommen. Der Header-Byte ermöglicht das Embedded-System neu zu Synchronisierung mit dem PC. Fügen Sie außerdem eine Prüfsumme am Ende.

Ich habe Sachen wie diese mit einem einfachen binären Format getan 

struct PacketHdr
{
  char syncByte1;
  char syncByte2;
  char packetType;
  char bytesToFollow;  //-or- totalPacketSize
};

struct VoltageSet
{ 
   struct PacketHdr;
   int16 channelId;
   int16 voltageLevel; 
   uint16 crc;
};

struct VoltageResponse
{
   struct PacketHdr;
   int16 data[N];  //Num channels are fixed
   uint16 crc;
}

Der Sync-Bytes ist weniger kritisch in einem synchronen Protokoll als in einem asynchronen ein, aber sie immer noch helfen, vor allem, wenn das eingebettete System zunächst nach oben ist die treibende Kraft, und Sie wissen nicht, ob das erste Byte es ist die Mitte wird von eine Nachricht oder nicht.

Der Typ sollte eine Enumeration, die erzählt, wie das Paket an intepret. Größe konnte vom Typ abgeleitet werden, aber wenn Sie es ausdrücklich senden, so kann der Empfänger unbekannte Typen handhaben, ohne Würgen. Sie können ‚Gesamtpaketgröße‘ oder ‚Bytes folgen‘ verwenden; letzteres kann den Empfänger Code ein wenig sauberer machen.

Der CRC am Ende bringt mehr Sicherheit, dass Sie gültige Daten haben. Manchmal habe ich das CRC im Header zu sehen, die einfacher zu erklären Strukturen machen, aber es am Ende setzen lässt Dich einen zusätzlichen Durchlauf über die Daten vermeiden, wenn die Nachricht gesendet wird.

Der Absender und Empfänger sollten beide Timeouts beginnend nach dem ersten Byte eines Pakets empfangen ist, falls ein Byte fallen gelassen wird. Die PC-Seite muss auch ein Timeout, den Fall zu behandeln, wenn das eingebettete System nicht angeschlossen ist, und es gibt keine Antwort überhaupt.

Wenn Sie sicher sind, dass beide Plattformen IEEE-754 Schwimmer (PC do) und haben die gleiche endianness, dann können Sie schwebt als Datentyp verwenden. Ansonsten sicherer ist es ganze Zahlen zu verwenden, entweder roh A / D-Bits oder eine vorgegebene Skala (das heißt 1 Bit = .001V gibt einen +/- 32,267 V-Bereich)

Adam Liss macht eine Menge großer Punkte. Einfachheit und Robustheit sollte der Schwerpunkt sein. Für Menschen lesbare ASCII Transfers helfen, eine Menge während des Debuggen. Große Vorschläge.

Sie können viel des Guten für Ihre Bedürfnisse, aber HDLC und / oder PPP in dem Konzept einer Datenverbindungsschicht, und alle Vorteile (und Kosten) hinzufügen, die mit einer Datenverbindungsschicht kommen. Link Management, Rahmung, Prüfsummen, Sequenznummern, Neuübertragungen usw ... alle helfen robuste Kommunikation zu gewährleisten, aber die Komplexität, die Verarbeitung und die Codegröße und kann nicht notwendig sein für Ihre Anwendung.

USB-Bus alle Ihre Anforderungen beantworten. Es könnte sein, sehr einfaches USB-Gerät mit nur Steuerrohr Anfrage an das Gerät zu senden oder Sie können ein Interrupt-Rohr hinzufügen, die Sie Host über Änderungen in Ihrem Gerät benachrichtigen können. Es gibt eine Reihe von einfachen USB-Controller, die verwendet werden können, zum Beispiel Cypress oder Microchip .

Protokoll über die Übertragung ist wirklich über Ihre Anforderungen. Aus Ihrer Beschreibung scheint es, dass einfaches synchrones Protokoll auf jeden Fall genug. Was machen Sie wandern und für weitere Vorgehen aussehen? Teilen Sie Ihre Zweifel und wir werden versuchen zu helfen :).

Wenn ich nicht brauchen erwarte effiziente binäre Übertragungen zu tun, die ich für die Terminal-Stil-Schnittstelle bereits vorgeschlagen gehen würde.

Wenn ich ein binäres Paketformat tun wollen, neige ich dazu, etwas zu verwenden, lose basierend auf dem PPP-Byte-ASNC HDLC-Format, die sehr einfach und leicht zu senden und empfangen, im Grunde:

Pakete beginnen und enden mit 0x7e Sie entkommen ein Zeichen, indem sie es mit 0x7d prefixing und Makeln Bit 5 (d xor mit 0x20) So 0x7e wird 0x7d 0x5e und 0x7d wird 0x7d 0x5D

Jedes Mal, wenn ein 0x7e dann sehen, wenn Sie irgendwelche Daten gespeichert haben, können Sie es bearbeiten.

ich in der Regel Host-driven synchrone Sachen tun, wenn ich einen sehr guten Grund haben, es anders zu machen. Es ist eine Technik, die von einfachen Punkt-Punkt-RS232 verlängert RS422 / 485 ohne Aufwand zur Multidrop -. Oft ein Bonus

Wie Sie aus allen Antworten bestimmt sind bereits nicht direkt Sie auf ein Protokoll zu leiten, dass eine Rolle Ihre eigenen Ansatz die beste Wahl zu sein.

Also, das hat mir denken und gut, hier sind ein paar meiner Gedanken -

Da dieser Chip 6 ADC-Kanäle, die meisten wahrscheinlich, dass Sie RS-232 serielle Kommunikation (eine Vermutung aus Ihrer Frage) verwenden, und natürlich der begrenzte Coderaum, eine einfache Befehlsstruktur definieren helfen, wie Adam weist darauf hin, - Sie empfehlen Sie, auf dem Chip die Eingangsverarbeitung auf ein Minimum zu halten, so binär klingt attraktiv, aber der Kompromiss ist in einfacher Entwicklung und Wartung (Sie Schwierigkeiten haben, können einen toten Eingang 6 Monate ab jetzt schießen) - Hyper-Terminal ein leistungsfähiges Debugging-Tool ist -. so, dass hatte ich zu denken, wie eine einfache Befehlsstruktur mit guter Zuverlässigkeit zu implementieren

Einige allgemeine Überlegungen -

Keep-Befehle die gleiche Größe - erleichtert Decodierung

.

Framing die Befehle und optionale Checksumme, wie Adam leicht weist darauf hin, um Ihre Befehle gewickelt werden. (Mit kleinen Befehlen, eine einfachen XOR / ADD-Prüfsumme ist schnell und schmerzlos)

Ich würde eine Start-up-Mitteilung an den Host mit der Firmware-Version bei Reset empfehlen - zum Beispiel „HALLO, Firmware Version 1.00z.“ - der Host würde sagen, dass das Ziel gerade gestartet und was läuft

Wenn Sie in erster Linie die Überwachung sind, können Sie einen „freien Lauf“ -Modus zu prüfen, wo das Ziel wäre einfach Zyklus durch die analogen und digitalen Messwerte - dies natürlich nicht kontinuierlich sein muss, kann es sein Abstand bei 1, 5, 10 Sekunden, oder einfach nur auf Befehl. Ihr Mikro immer hört so einen aktualisierten Wert zu senden ist eine unabhängige Aufgabe.

Beenden jede Ausgangsleitung mit einem CR (oder andere Zeichen) macht die Synchronisation auf dem Host gerade nach vorne.

zum Beispiel Ihres Mikro könnte die Saiten einfach Ausgang; 

  V0=3.20
  V1=3.21
  V2= ...
  D1=0
  D2=1
  D3=...
  and then start over --

Auch könnten Befehle sein wirklich einfach -

? Alle Werte - -. Es gibt nicht so viele von ihnen, so bekommen sie alle

X = 12.34 - „“ einen Wert zu setzen, das erste Byte ist die Port, dann ist die Spannung, und ich würde empfehlen, die „=“ zu halten und die als Framing ein gültiges Paket, um sicherzustellen, ob Sie die Prüfsumme verzichten.

Eine andere Möglichkeit, wenn Ihre Ausgaben innerhalb eines festgelegten Bereichs liegen, man konnte sie PRESCALE. Wenn zum Beispiel der Ausgabe genau sein nicht, könnten Sie so etwas wie

senden 
5=0 
6=9
2=5

, die auf Port 5 aus, Port 6 bis vollständig eingestellt würde, und Port 2 auf den halben Wert - Mit diesem Ansatz ascii und binäre Daten sind nur etwa auf die gleiche Stufe in Bezug auf die Rechen- / Decodierung Ressourcen auf der Mikro. Oder für mehr Präzision, machen den Ausgang 2 Bytes, zB 2 = 54 - OR, eine xref-Tabelle hinzufügen und die Werte nicht einmal linear sein müssen, wo die Daten Byte ein Index in einer Look-up-Tabelle ist .. .

Wie ich sagen; einfach ist in der Regel besser, es sei denn, es ist nicht.

Hope, das hilft ein wenig.

einen anderen Gedanken, während wieder gelesen hatte; ein „*“ Befehl hinzufügen können die Daten mit HTML-Tags und jetzt Host-App umleiten könnte einfach die Ausgabe von Ihrem Mikro an einen Browser und wala, Browser bereit gewickelt anfordern -

:)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top