Protokolle zum Sprechen zwischen einer eingebetteten CPU und einem PC

Question

Ich baue ein kleines Gerät mit eigener CPU (AVR Mega8), das an einen PC angeschlossen werden soll. Angenommen, dass die physische Verbindung und die Weitergabe von Bytes abgeschlossen ist, was wäre dann das beste Protokoll, das zusätzlich zu diesen Bytes verwendet wird? Der Computer muss in der Lage sein, bestimmte Spannungen am Gerät einzustellen und bestimmte andere Spannungen zurückzulesen.

Momentan denke ich an ein komplett hostgesteuertes synchrones Protokoll: Computer senden Anfragen, die eingebettete CPU antwortet. Irgendwelche anderen Ideen?

Answer 1

Modbus könnte sein, Wonach suchen Sie. Es wurde für genau die Art von Problem entwickelt, die Sie haben. Es gibt eine Menge Code/Tools da draußen und die Einhaltung eines Standards könnte eine einfache Wiederverwendung später bedeuten. Es unterstützt auch menschenlesbares ASCII, so dass es immer noch leicht zu verstehen/zu testen ist.

Siehe FreeModBus für Windows und eingebettete Quelle.

Answer 2

Es gibt eine Menge zu sagen für Client-Server-Architektur und synchrone Protokolle. Einfachheit und Robustheit, um anzufangen. Wenn die Geschwindigkeit kein Problem ist, sollten Sie ein kompaktes, für den Menschen lesbares Protokoll in Betracht ziehen, das beim Debuggen hilft. Ich denke entlang der Linien von modernen AT-Befehlen: eine "Wakeup" -Sequenz, gefolgt von einem set/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 

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

Je nach Geschwindigkeits- und Zuverlässigkeitsanforderungen können Sie die Befehle in ein oder zwei Bytes codieren und eine Prüfsumme hinzufügen.

Es ist immer eine gute Idee, mit der tatsächlichen Spannung zu antworten, anstatt einfach den Befehl zu wiederholen, da es eine nachfolgende Leseoperation speichert.

Auch hilfreich, um Fehlermeldungen zu definieren, falls Sie debuggen müssen.

Answer 3

USB bus wird alle Ihre Anforderungen beantworten. Es kann sehr einfach sein USB-Gerät mit nur Steuerrohr, um eine Anfrage an Ihr Gerät zu senden, oder Sie können eine Interrupt-Leitung hinzufügen, mit der Sie Host über Änderungen in Ihrem Gerät benachrichtigen können. Es gibt eine Reihe von einfachen USB-Controllern, die verwendet werden können, zum Beispiel Cypress oder Microchip.

Protokoll oben auf der Übertragung ist wirklich über Ihre Anforderungen. Aus Ihrer Beschreibung geht hervor, dass ein einfaches synchrones Protokoll definitiv ausreicht. Was lässt dich wandern und nach einem zusätzlichen Ansatz suchen? Teilen Sie Ihre Zweifel und wir werden versuchen zu helfen :).

Answer 4

Adam Liss macht viele gute Punkte. Einfachheit und Robustheit sollten im Mittelpunkt stehen. Vom Menschen lesbare ASCII-Übertragungen helfen einem LOT beim Debuggen. Tolle Vorschläge.

Sie mögen für Ihre Anforderungen übertrieben sein, aber HDLC und/oder PPP ergänzen das Konzept einer Sicherungsschicht und alle Vorteile (und Kosten), die mit einer Sicherungsschicht verbunden sind. Verbindungsverwaltung, Framing, Prüfsummen, Sequenznummern, erneute Übertragungen usw. sorgen für eine robuste Kommunikation, erhöhen jedoch die Komplexität, die Verarbeitung und die Codegröße und sind möglicherweise für Ihre spezielle Anwendung nicht erforderlich.

Answer 5

Wenn ich nicht erwartet hätte, effiziente binäre Übertragungen zu tun, würde ich für die bereits vorgeschlagene Terminal-Stil-Schnittstelle gehen.

Wenn ich ein binäres Paketformat tun wollen, ich neige 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 Ende mit 0x7e Sie entkommen ein Zeichen, indem Sie es mit 0x7d voranstellen und Bit 5 umschalten (dhxor mit 0x20) So 0x7e wird 0x7D 0x5e und 0x7d 0x5D

Jedes Mal, wenn Sie eine 0x7e sehen 0x7D wird dann, wenn Sie alle Daten gespeichert haben, können Sie es verarbeiten kann.

Ich mache normalerweise hostgetriebene synchrone Sachen, es sei denn, ich habe einen guten Grund, etwas anderes zu tun. Es ist eine Technik, die sich vom einfachen Punkt-zu-Punkt-RS232 bis hin zum Multidrop-RS422/485 ohne Probleme erstreckt - oft ein Bonus.

Answer 6

Meine Stimme ist für die Menschen lesbar.

Aber wenn Sie binär gehen, versuchen Sie, ein Header-Byte am Anfang zu setzen, um den Anfang eines Pakets zu markieren. Ich hatte immer Pech mit seriellen Protokollen, die nicht mehr synchron waren. Das Header-Byte ermöglicht dem eingebetteten System eine erneute Synchronisierung mit dem PC. Fügen Sie am Ende eine Prüfsumme hinzu.

Answer 7

Ich habe Sachen gemacht, wie dies mit einem einfachen binären Format

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 Embedded-System ist ersten Einschalten, und Sie wissen nicht, ob das erste Byte, das es bekommt, die Mitte einer Nachricht ist oder nicht.

Der Typ sollte eine Aufzählung sein, die angibt, wie das Paket zu interpretieren ist. Die Größe kann vom Typ abgeleitet werden, aber wenn Sie es explizit senden, kann der Empfänger unbekannte Typen ohne Erstickung behandeln. Sie können "Gesamtpaketgröße" oder "Bytes folgen" verwenden. Letzteres kann den Empfängercode etwas sauberer machen.

Die CRC am Ende gibt mehr Sicherheit, dass Sie gültige Daten haben. Manchmal habe ich die CRC in der Kopfzeile gesehen, was das Deklarieren von Strukturen einfacher macht, aber wenn man sie am Ende anbringt, vermeidet man ein zusätzliches Übergeben der Daten beim Senden der Nachricht.

Der Absender und der Empfänger sollten beide Zeitüberschreitungen haben, die nach dem Empfang des ersten Bytes eines Pakets beginnen, falls ein Byte gelöscht wird. Die PC-Seite benötigt auch eine Zeitüberschreitung, um den Fall zu behandeln, wenn das eingebettete System nicht verbunden ist und überhaupt keine Antwort vorliegt.

Wenn Sie sicher sind, dass beide Plattformen IEEE-754-Floats (PC's) verwenden und die gleiche Endiannität haben, können Sie Floats als Datentyp verwenden. Ansonsten ist es sicherer Ganzzahlen zu verwenden, entweder rohe A/D Bits oder eine voreingestellte Skala (dh 1 Bit = .001V ergibt einen Bereich von +/- 32.267V)

Answer 8

Wie Sie vielleicht schon aus allen Antworten nicht direkt ermittelt haben Sie zu einem Protokoll führen, dass ein eigener Ansatz Ihre beste Wahl ist.

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 verwenden (eine Vermutung von Ihrem Frage), und natürlich der begrenzte Coderaum, der eine einfache Befehlsstruktur definiert, wird helfen, wie Adam hervorhebt - Sie möchten vielleicht die Eingabeverarbeitung auf dem Chip auf ein Minimum beschränken, so dass Binär klingt attraktiv, aber der Kompromiss ist in Einfache Entwicklung UND Wartung (Sie müssen vielleicht in 6 Monaten einen toten Input erledigen) - hyperterminal ist ein leistungsfähiges Debug-Tool - also habe ich darüber nachgedacht, wie man eine einfache Befehlsstruktur mit guter Zuverlässigkeit implementiert.

Einige allgemeine Überlegungen -

Halten Sie die gleiche Größe Kommandos - macht Decodierung einfacher.

Framing der Befehle und optionale Prüfsumme, wie Adam hervorhebt, kann leicht um Ihre Befehle gewickelt werden. (mit kleinen Befehlen, eine einfache XOR/ADD-Prüfsumme ist schnell und schmerzlos)

Ich würde eine Startup-Meldung an den Host mit der Firmware-Version beim Zurücksetzen empfehlen - zB "HALLO; Firmware Version 1.00z" - würde Sagen Sie dem Host, dass das Ziel gerade gestartet wurde und was ausgeführt wird.

Wenn Sie hauptsächlich überwachen, möchten Sie vielleicht einen "Freilauf" -Modus in Betracht ziehen, bei dem das Ziel einfach durch die analogen und digitalen Messwerte läuft - das muss natürlich nicht kontinuierlich sein Abstand von 1, 5, 10 Sekunden oder nur auf Befehl. Ihr Mikro hört immer zu, daher ist das Senden eines aktualisierten Werts eine unabhängige Aufgabe.

Wenn Sie jede Ausgangsleitung mit einem CR (oder einem anderen Zeichen) terminieren, wird die Synchronisation auf dem Host problemlos möglich.

zum Beispiel könnte Ihr Mikro einfach die Saiten ausgeben;

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

Auch könnten Befehle wirklich einfach sein -

? - Lesen Sie alle Werte - es gibt nicht viele, also nehmen Sie sie alle.

X = 12.34 - Um einen Wert zu setzen, ist das erste Byte der Port, dann würde die Spannung und ich empfehlen, das "=" und das "." als Rahmen, um ein gültiges Paket sicherzustellen, wenn Sie auf die Prüfsumme verzichten.

Eine andere Möglichkeit, wenn Ihre Ausgänge innerhalb eines festgelegten Bereichs liegen, können Sie sie vorskalieren. Wenn zum Beispiel der Ausgabe genau sein nicht, könnten Sie so etwas wie

5=0 
6=9 
2=5 

senden, die auf Port 5 aus, Port 6 zu voll, und Port 2 auf dem halben Wert gesetzt würden - Mit diesem Ansatz Ascii und binäre Daten sind in Bezug auf die Berechnung/Decodierung von Ressourcen im Mikrobereich ungefähr gleichgestellt. Oder für mehr Genauigkeit, mache die Ausgabe 2 Bytes, zB 2 = 54 - ODER, füge eine Xref-Tabelle hinzu und die Werte müssen nicht einmal linear sein, wo das Datenbyte ein Index in eine Nachschlagetabelle ist. .

Wie ich gerne sagen; Einfach ist normalerweise besser, es sei denn, es ist nicht.

Hoffe das hilft ein bisschen.

---

Hatte einen anderen Gedanken beim erneuten Lesen; ein „*“ Befehl hinzufügen können die Daten mit HTML-Tags eingewickelt anfordern und jetzt Host-App einfach könnte die Ausgabe von Ihrem Mikro an einen Browser und wala, Browser bereit umleiten -

:)