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?
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)
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
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.
> ... 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.
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.