www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik abstrakter Datenaustausch zwischen 2 Embedded Systemen? Sockets? RPC?


Autor: Alexander I. (daedalus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich entwickle gerade ganz abstrakt gesagt, einen Kommunikationskanal 
zwischen zwei Embedded Systemen.

Erst mal ein paar Rahmenbedingungen, die als gegeben anzusehen sind:
- Die Kommunikation erfolgt mit Halb-Duplex über RS485
- Es wird ein eigener propritäter Protokollstack verwendet, der 
OSI-Layer 1 bis 4 abbildet. Da es bis in alle Ewigkeit nur diese 2 
Teilnehmer geben wird, ist eine Vermittlungsschicht nicht nötig.
- System 1 ist ein dicker PowerPC mit mächtig "Bumms".
- System 2 ist ein kleiner ARM-Controller LPC2387.

Die Kommunikation soll völlig transparent ablaufen, also die darauf 
aufsetzende Applikation sieht das als ausfallsicheren Datenkanal an und 
soll diesen Datenkanal beliebig nutzen können:
- Effiziente bidirektionale Übertragung von Nutzdaten
- Übermittlung von "Aufgaben" an anderen Teilnehmer
- Client/Server-ähnliche Verhaltensmuster

Eine solche Aufgabe könnte z.B. lauten:
- "Mach die Datei XY auf deiner SD-Karte auf und schicke mir die ersten 
1000 Bytes davon".
- "Was gibt's Neues?"
- "Verschicke diese Daten mal über dein CAN-Interface"

Es ist also nicht damit getan ein einfaches RxTx-Gedingel zu machen und 
ein paar Bytes auszuwerten, sondern sollte möglichst flexibel und 
generisch nutzbar sein, ohne dass der Applikationsentwickler die Bits n' 
Pieces des Übertragungskanals kennen muß. Da kommen natürlich gleich 
solche Stichworte wie Sockets, RPC, CORBA, usw. in Betracht. Allerdings 
beschäftigen sich diese Standard-APIs alle mit zuviel IP-Adressen, 
Portnummern und Routing-Geschichten, das brauch ich alles gar nicht und 
bläst den Code nur unnötig auf. Was fällt euch als einfaches generisches 
Übertragungsinterface ein, das oben genannte Anforderungen erfüllen kann 
und einen gegebenen Übertragungskanal nur per "connect, disconnect, 
recv, send" einfach nutzt und sich dahinter ein "Miniserver" oder 
"Miniclient" versteckt, der Aufgaben ausführt?

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube du wirfst da etwas durcheinander...
Sockets haben nicht zwangsläufig was mit RPC zu tun und RXTX gedingel 
wirste zwangsläufig machen müssen.

Erstmal must du dir überlegen was der Kommunikationskanal sein soll.
RS232/CAN/USB/Ethernet/TWI... alles ist möglich.

Dann mußt du dir überlegen wie Datenaustausch von statten gehen soll 
und wie Angang und Ende von Frames/Datenpaketen erkannt werden.

Danach kannst du anfange dir über Client/Server geschichten Gedanken zu 
machen...
das HTTP Protokoll könnte sich hier anbiete, sowas ist aber prinzipiell 
auch über RS232 komplett ohne IP Adresse, Sockets, Ports und Routing 
möglich. (Nicht umsonst werden Sockets in den meisten APIs einfach als 
Ein/Ausgabe 'Datei' dargestellt)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander I. schrieb:
> Die Kommunikation soll völlig transparent ablaufen, also die darauf
> aufsetzende Applikation sieht das als ausfallsicheren Datenkanal an und
> soll diesen Datenkanal beliebig nutzen können:

Du kannst der Hardware zwar sagen: "Du bist jetzt ausfallsicher", aber 
sie wird Dir was husten.
Die Applikation muß damit zurechtkommen, daß die Verbindung zeitweilig 
gestört ist, z.B. werden beide Geräte zu unterschiedlichen Zeiten 
eingeschaltet oder eins macht mal einen Reset, oder die CRC ist falsch 
usw.
Ansonsten wartet Deine Applikation beim ersten Huster bis zum St. 
Nimmerleinstag.

> - Effiziente bidirektionale Übertragung von Nutzdaten

Effizient ist was anders, jedoch nicht "Halb-Duplex RS485".
Du brauchst einen Mechanismus zur Kollisionsauflösung, das kostet Zeit.


Peter

Autor: Alexander I. (daedalus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

über den Protokollstack muß ich mir separat Gedanken machen, das ist 
nicht der Fokus worauf es mir hier ankommt. Vielleicht habe ich mich 
nicht deutlich genug ausgedrückt. Die Sache mit dem RS485 usw. hab nicht 
ich bestimmt, das ist halt einfach so gegeben und ich muß das nutzen. 
Die ganze Sache mit CRC-Prüfung, State-Machine's für die 
Protokollabläufe, Aushandeln von Parametern usw. sind mir klar und 
werden teil des Protokollstacks. Ums RxTx-Gedingel komme ich natürlich 
nicht herum, es soll nur nicht Bestandteil dieser Fragestellung sein. Es 
geht mir nur darum, eine darauf aufgesetzte Middleware zu finden, die 
das Bindeglied zwischen einer Applikation und einem Protokollstack 
darstellt und mehr die Prozesskommunikation statt den Kommunikationspfad 
in den Vordergrund stellt.

Das es Kommunikationsfehler geben kann, ist mir schon klar und wird auch 
entsprechend gekapselt und rückgemeldet. Es geht nur darum, dass sich 
die Applikation keine Gedanken machen muß um Verbindungsaufbau, 
Aushandeln von Parametern (MTU, Framing, usw.) sondern nur connect, 
disconnect, send und recv nutzt und davon ausgehen kann, dass das im 
Normalfall klappt. Wenn dazwischen mal die Verbindung abbricht oder gar 
nicht erst hergestellt werden kann, kapselt das swoeit möglich der Stack 
und meldet das Problem nur wenn's richtig kracht bis nach oben. 
Irgendwann kommt schlägt der Fehler dann natürlich bei der Applikation 
auf.

Ich muß diese Middleware schon jetzt - zumindest in groben Zügen - 
wissen, denn auf der anderen Seite (Applikation) soll bereits 
dahingehend entwickelt werden und am Schluss wird beides aneinander 
angeflanscht werden. D.h. ich muß frühzeitig eine generische 
Schnittstelle für die Applikation beschreiben, ohne dass der 
Protokollstack schon steht.

Deshalb wollte ich ein paar Stichworte wissen, welche evtl. vereinfachte 
Prozesskommunikationsmodelle (ohne das ganze TCP/IP-Geraffel) es da noch 
gibt als die vom PC üblichen.

Autor: tuppes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... sondern nur connect, disconnect, send und recv nutzt ...

> ... D.h. ich muß frühzeitig eine generische Schnittstelle
> für die Applikation beschreiben ...

Klingt für mich so, als wär genau das (connect, disconnect, send, recv) 
deine generische Schnittstelle. Das ist ein Transportschicht-API 
(entspricht TCP oder UDP in der TCP/IP-Familie).

Darunter liegt eine triviale Netzwerkschicht (trivial deshalb, weil es 
in Netzen mit genau zwei Stationen nicht viel zu vermitteln gibt), eine 
Sicherungsschicht, die u.a. die Richtungssteuerung der RS485-Treiber 
enthält und eine Bitübertragungsschicht, die die UARTs der Controller 
bedient.

Über dem Transportschicht-API liegen die verschiedenen Dienste 
(Dateisystem-API, CAN-API und was dir noch so einfällt) und darüber die 
Applikationen, die diese Dienste benutzen.

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.