www.mikrocontroller.net

Forum: PC-Programmierung Software-Optimiertes Binärprotokoll


Autor: Henning Di (henning-d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe einen AVR Microcontroller und möchte diesen über eine Software 
fernsteuern (die Kommunikation läuft über USB zu Parallel, später auch 
über Funk, aber das spielt keine Rolle).

Das Kommunikations-Protokoll soll also für PC zu µC optimiert sein, 
sowohl in der Programmierung als auch in der Geschwindigkeit - der 
Mensch muss das Protokoll nicht beherrschen können.

Hauptsächlich stellt die Software auf dem PC Anfragen an den µC, der 
diese immer beantworten muss (typische Response/Request-Kommunikation 
wie bei HTTP) - z.B. Auslesen von Sensoren oder ansteuern von Motoren, 
LEDs, etc..
Allerdings soll der µC auch asynchrone Nachrichten verschicken können, 
um den PC bspw. bei best. Ereignisse zu benachrichtigen (z.B. bei Druck 
eines Drucksensors), um ewiges Pollen zu vermeiden.

Gibts da schon eine fertige Implementierung - ich will das Rad 
schließlich nicht neu erfinden?

Wenn nicht, worauf sollte ich bei der Implementierung achten?

Ein Problem bei der Funkübertragung ist die Integrität, ich müsste also 
Paket-Einheiten definieren und die mit Prüfsummen versehen.
Bei der UART-Übertragung ist dieses Problem nicht in der Art vorhanden, 
das Protokoll sollte hinsichtlich der Kommunikationsart also flexibel 
sein.

Das Protokoll soll also nicht nur wie TCP Datenintegrität gewährleisten 
sondern ein Framework bieten, mit dem schnell übersichtliche Anwendung 
auf beiden Seiten (PC, µC) entwickelt werden können (z.B. sehr einfaches 
RPC wäre nicht schlecht).

Autor: Grübelnder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein Problem bei der Funkübertragung ist die Integrität, ich müsste also
> Paket-Einheiten definieren und die mit Prüfsummen versehen.

> ... das spielt keine Rolle ...

> Bei der UART-Übertragung ist dieses Problem nicht in der Art vorhanden,

falsch

> Das Protokoll soll also nicht nur wie TCP Datenintegrität gewährleisten

falsch

> mit dem schnell übersichtliche Anwendung
> auf beiden Seiten (PC, µC) entwickelt werden können (z.B. sehr einfaches
> RPC wäre nicht schlecht).

Das eine hat mit dem anderen nichts zu tun.

Autor: Henning Di (henning-d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Bei der UART-Übertragung ist dieses Problem nicht in der Art vorhanden,
> falsch

Aber die wahrscheinlichkeit, dass über die UART-Schnittstelle bei kurzer 
Verbindung Daten verloren gehen / falsch ankommen ist im gegensatz zur 
Funk-Verbindung deutlich geringer.
Oder liege ich da falsch?

>> Das Protokoll soll also nicht nur wie TCP Datenintegrität gewährleisten
> falsch

Was ist falsch?
Dass TCP Datenintegrität gewährleistet?
Das kann nicht sein - siehe dazu Wikipedia:
http://de.wikipedia.org/wiki/Transmission_Control_...

Es heißt ja auch nicht umsonst Transmission Control Protocol...

>> mit dem schnell übersichtliche Anwendung
>> auf beiden Seiten (PC, µC) entwickelt werden können (z.B. sehr einfaches
>> RPC wäre nicht schlecht).
>
> Das eine hat mit dem anderen nichts zu tun.

Was hat mit dem anderen nichts zu tun?
Dass Übersichtlichkeit nichts mit Features wie RPC zu tun hat?
Oder dass das Protokoll nicht für RPC zuständig ist?
Das sehe ich anders: Versuch mal mittels POP3 einen Remote Procedur Call 
durchzuführen.
Gut, RPC hat nichts mit Datenintegrität zu tun, aber es ist trotzdem 
eine Sache des Protokolls (so gibt es z.B. SOAP, Simple Object Access 
Protocol - das sorgt für den Zugriff auf Objekte via XML-Requests, ist 
ein Protokoll, setzt auf TCP auf und kümmert sich NICHT um 
Datenintegrität, da TCP dies macht).

Autor: Hansilein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Henning Di schrieb:

>> Das eine hat mit dem anderen nichts zu tun.
>
> Was hat mit dem anderen nichts zu tun?

Das eine ist die Sicherstellung einer fehlerfreien Datenübertragung.
Was dann auf diesem 'gesicherten Übertragungsmedium' an Diensten 
angeboten wird, ist ein anderes Paar Schuhe

> Das sehe ich anders: Versuch mal mittels POP3 einen Remote Procedur Call
> durchzuführen.

Weder POP3 noch RPC kümmern sich darum, wer ihre Daten transportiert und 
welchen Aufwand diese Schicht treibt um fehlerfreie Übertragung zu 
gewährleisten.

Wenn man will kann man POP3 auch mit Brieftauben implementieren.

Autor: Henning Di (henning-d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für Antworten!

@Hansilein :
Danke für den Link, so etwas in der Richtung habe ich gesucht.
Nur ist mir dieses Protokoll etwas zu starr und allgemein:
Ich möchte eigene Features leicht hinzufügen können.
Soetwas wie ein Parser und Interpreter, in den man sich einklinken kann.
Der µC steuert dann nämlich Motoren an, für ihn gibt es Port A, B und C 
(mit je 8 Bits) der Computer soll dem µC aber sagen, dass er z.B. Motor2 
rechtsherum drehen lassen soll (der steuert dann Port A, 3. und 4. Bit 
an).

@Karl heinz Buchegger:

> Was dann auf diesem 'gesicherten Übertragungsmedium' an Diensten
> angeboten wird, ist ein anderes Paar Schuhe

Das stimmt, ich suche aber beides.
Außerdem sind das keine Dienste sondern genormte Protokolle.

> Wenn man will kann man POP3 auch mit Brieftauben implementieren.

;)

Was ihr, bis auf Hansilein, aber macht, ist für mein Problem nicht 
sonderlich förderlich. Mag sein, dass ich mich ein bisschen falsch 
ausgedrückt habe, aber ich denke ihr habt mein Anliegen verstanden?

Es gibt Protokolle für unterschiedliche Schichten - ich suche ein 
Framework mit Protokollen für Schicht 2 bis 5 (wobei die 
Vermittlungsschicht bei einer statischen Punkt-zu-Punkt-Verbindung nicht 
von Bedeutung ist).
(http://de.wikipedia.org/wiki/OSI-Modell)
Schicht 4 ist u.A. für Datenintegrität verantwortlich, Schicht 5 für so 
etwas wie RPC.

Wenn jemand eine Website schreibt, muss der sich auch nicht mit der 
Datenintegrität, dem Ausbügeln von Transport-Fehlern und dem Parsing von 
HTML rumschlagen.
Ich will (natülich nur als Vergleich gemeint!) auf dem µC HTML schreiben 
und am PC Makros für den Browser programmieren. Um alles andere soll 
sich das gesuchte Protokoll (meinetwegen "die gesuchten Protokolle") 
kümmern.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Henning Di schrieb:

>>> Bei der UART-Übertragung ist dieses Problem nicht in der
>>> Art vorhanden,
>>
>> falsch
>
> Aber die wahrscheinlichkeit, dass über die UART-Schnittstelle bei
> kurzer Verbindung Daten verloren gehen / falsch ankommen ist im
> gegensatz zur Funk-Verbindung deutlich geringer.

Ja, aber wenn nur ein einziges Byte nicht ankommt, kommt hinten nur noch 
kompletter Unsinn raus, und du musst die Übertragung auf beiden Seiten 
manuell komplett abbrechen und wieder von vorne starten, da die Systeme 
den Fehler weder erkennen, noch sich davon erholen können.

Autor: Grübelnder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>> Das Protokoll soll also nicht nur wie TCP Datenintegrität gewährleisten
>> falsch

> Was ist falsch?
> Dass TCP Datenintegrität gewährleistet?
> Das kann nicht sein - siehe dazu Wikipedia:
> http://de.wikipedia.org/wiki/Transmission_Control_...

Komm mir hier nicht mit Wiki ! Da steht Müll drin:

Wiki:

> Es prüft daher die Integrität der Daten mittels der Prüfsumme  im
> Paketkopf und stellt die Reihenfolge durch Sequenznummern  sicher.

Total daneben.

Es wird nur über den Header eine Prüfsumme gebildet und nicht über die 
Daten ! Die Daten können also falsch oder richtig ankommen, alles schon 
vorgekommen ... die Datenintegrität für den Payload (die Daten) müssen 
die oberen Schichten sicherstellen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Henning Di schrieb:

> Es gibt Protokolle für unterschiedliche Schichten - ich suche ein
> Framework mit Protokollen für Schicht 2 bis 5 (wobei die
> Vermittlungsschicht bei einer statischen Punkt-zu-Punkt-Verbindung nicht
> von Bedeutung ist).
> (http://de.wikipedia.org/wiki/OSI-Modell)

So liest sich das dann schon besser als die ursprüngliche Fragestellung, 
bei der, zumindest für mich, alles mit allem irgendwie vermanscht war.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grübelnder schrieb:
>>>> Das Protokoll soll also nicht nur wie TCP Datenintegrität gewährleisten
>>> falsch
>
>> Was ist falsch?
>> Dass TCP Datenintegrität gewährleistet?
>> Das kann nicht sein - siehe dazu Wikipedia:
>> http://de.wikipedia.org/wiki/Transmission_Control_...
>
> Komm mir hier nicht mit Wiki !

Du meinst Wikipedia.

>> Es prüft daher die Integrität der Daten mittels der Prüfsumme  im
>> Paketkopf und stellt die Reihenfolge durch Sequenznummern  sicher.
>
> Total daneben.

Aus rfc793 "TRANSMISSION CONTROL PROTOCOL"
 Checksum:  16 bits

    The checksum field is the 16 bit one's complement of the one's
    complement sum of all 16 bit words in the header and text.
                                                     ^^^^^^^^

Autor: Michael Uray (michaeluray)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S.N.A.P (http://www.hth.com/snap/) ist ein relativ einfaches aber 
flexibles Protokoll für die serielle Kommunikation. Es können mehrere 
Teilnehmer adressiert werden und es ist auch eine CRC Prüfung 
integriert.

Allerdings ist es auf Master-Slave aufgebaut. Dh. grundsätzlich kann der 
uc von alleine nichts schicken. Das sehe ich allerdings nicht unbedingt 
als Problem an, da eigentlich nichts gegen ein dauerndes pollen spricht. 
Du kannst ja ein kleines Kommando (eine Art Token) programmieren, mit 
welchem dir der uc nur aktualisierte Daten (z.B. geänderte Temperatur 
seit der letzten Auslesung) schickt.
Du hast dann auch kein Problem damit, wenn du mehrere Teilnehmer auf dem 
System hast, da es so auch zu keiner Kollision am Bus/Funknetz kommen 
kann.

Auf der HTH Seite gibt es auch einiges an Sourcen für AVRs dazu.

Autor: Henning Di (henning-d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super!
So etwas habe ich gesucht!

Vielen Dank!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.