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).
> 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.
>> 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_Protocol#Datenintegrit.C3.A4t_und_Zuverl.C3.A4ssigkeit 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).
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.
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.
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.
>>> 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.
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.
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"
1 | Checksum: 16 bits |
2 | |
3 | The checksum field is the 16 bit one's complement of the one's |
4 | complement sum of all 16 bit words in the header and text. |
5 | ^^^^^^^^ |
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.
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.