Programm kommunikation

rüdiger

blan schrieb:

Ich weiss ja nicht wie deine Programme verteilt sind aber mit Sockets könnte das Master-Programm auf einem anderen Rechner sein wie die andere Programme - das wäre ein Vorteil den du mit Sockets hast. Du musst dir also nur noch ein kleines Protokoll (wie zB HTTP, FTP - nur viel simpler) ausdenken um den Datenstrom zu koordinieren.

blan

Sockets sind aber auch die langsamste Methode und dürften sich daher nur für den Master lohnen (wenn dieser eine entsprechende Zeittoleranz hat).

Also soll alles auf einem Prozessor laufen.
Master ist auch noch nicht geschrieben und wird hoffentlich nicht von mir geschrieben.
Somit sond die Schnittstellen ebn noch absolut offen.
weshalb ich acuh hier einfach mal frage

Fabeltier

Hallo,

Wie bereits gesagt, es kommt darauf an "wie verteilt" es sein soll, also Du meintest bereits es befindet sich alles auf einer Maschine, dh Du benoetigst einen Mechanismus der IPC.

Unter Linux/Unix gibt's da Pipes (einfache und FIFOs), Shared Memory, Message Queues, Unix Sockets und Signals.

Generell wirst Du wohl einen Prozess schreiben, der die Sensor Prozesse entweder ausforked oder als Threads laeufen laesst (Stichwort Pthreads), dann wirst Du wohl v.a. FIFOs verwenden als IPC Methode, allerdings evtl. auch einen kleinen Signalhaendler schreiben fuer die forks um Zobies zu vermeiden (Stichwort waitpid, das ist idR ein Zweizeiler).

Alternativ gehen auch Einzelprozesse, die miteinander kommunizieren, das laesst sich zB ueber einen Prozess Server ueber Unix Sockets realisieren. Das ist zwar um einiges maechtiger und schliesslich sogar auf physisch verteilte Situationen uebertragbar, allerdings auch um einiges komplexer, da Du Dich dabei evtl erstmal mit verschiedenen Serverimplementierungsarten auseinander setzen solltest. Geschweige denn vom Debuggen. Letztere Methode, v.a. im Hinblick auf Deine ARM Architektur (embedded?) scheint ebenfalls seine Vorteile zu haben.

Als Literatur unter Unix / Linux kann ich Dir da die beiden Buecher von Stevens (IPC und Socket API) empfehlen, vllt gibt's die in ner Buecherei in Deiner naehe

supertux

Wenn der Master noch nicht steht, dann ist jetzt der beste Zeitpunkt, um eine Kommunikations API festzulegen, dann hast du freie Wahl. es muss aber dokumentiert werden, wie Daten auszutauschen sind, sonst werden sie nie miteinander arbeiten können (vor allem, wenn jemand anders den Master schreiben soll).

Ja, es handelt sich um ein embedded system.
Master ist glaub ich mal am selben Prozessor
(weiß nicht ob jemand anderes Anstalten machen wird das mal auf einen anderen auszulagern, also nein)
Trotzdem soll das Programm eigenständig sein (vermutlich weil es doch vorgesehen wird den Master aus zu lagen, naja mich hat noch keiner in Kenntnis davon gesetzt). (als erst Version wurde mir auch vorgeschlagen mal mit File-Input/Output (fopen) zu arbeiten und zu schaun ob mein Mathe-Algo funzt)

Meine Grundlegende Frage bei dem ganzen ist,
da ich mich eben noch gaaar nicht auskenne,
wie sowas prinzipiell klappt.

Die Eckdaten sind ja :
Kommunikation mit dem Master:
-> nur hin und wieder ne Anfrage --> dann hald ein paar daten übertragen
--> Wie wird die Anfrage signalisiert? und worüber soll nacher gesendet werden ?

Kommunikation mit den Sensoren:
--> Wie werden die Daten geholt, so dass sicher gestellt werden kann, das ich immer neue Daten kriege und nicht manchmal 2 mal die selben daten auswerte ? wäre nämlich nicht sinnvoll für die Auswertung ?

http://beej.us/guide/bgipc/
werd mal schaun ob ich am WE zeit finde ...
Schraub gerade noch in Matlab am Algorithmus (nur für den sollte die Verantwortung bei mir liegen)rum

supertux

peter-s schrieb:

Die Eckdaten sind ja :
Kommunikation mit dem Master:
-> nur hin und wieder ne Anfrage --> dann hald ein paar daten übertragen
--> Wie wird die Anfrage signalisiert? und worüber soll nacher gesendet werden ?

das ist es genau, was ich oben meinte: ihr solltet an eine KommunikationsAPI arbeiten, sprich ihr überlegt im Voraus wie ihr die Daten miteinander tauschen wollt. Wovon hängt es ab? 1. Von den Daten selber.

Ihr könnt euch grundlegende Fragen selbst stellen:

- wie sehen die Daten aus?
- welche Daten sind relevant
- wie liegen sie vor?
- muss dass netzwerkfähig sein?
- laufen Master und Slave auf dem gleichen Rechner?
- gibt es nur ein Slave, oder kann es mehrere geben?
- fall mehrere Slave gibt, soll der Master auf alle reagieren?
- usw.

Das sind Sachen, die nur ihr wissen könnt, nicht wir. Abhängig von den Antworten könnte ihr dann entscheiden: sockets, shared memory, datenbank, was ganz eigenes, was weiß ich...

peter-s schrieb:

Kommunikation mit den Sensoren:
--> Wie werden die Daten geholt, so dass sicher gestellt werden kann, das ich immer neue Daten kriege und nicht manchmal 2 mal die selben daten auswerte ? wäre nämlich nicht sinnvoll für die Auswertung ?

wie Daten aus Sensoren gelesen werden, hängt vom Sensor ab. Sensoren müssen an einem Bus angeschlossen sein, da gibt es für eingebette Systeme sehr viele: RS232 (serielle Schnittstelle), CAN, I²C, USB, Profibus, was ganz eigenes, und und und.... und letztlich hängt es vom Sensor und vom Bus ab. Für die meisten Busen gibt es vordefinierten Bibliotheken. Im Linux Kernel gibt es von Haus aus Support für alle oben genannten Busen (bei profibus bin ich nicht sicher, ist aber jetzt egal), oder ihr müsst euch was eigenes schreiben.

Sensoren kommen mit Datenblättern und Handbüchern, wo drauf steht, wie man sie bedient. Unbedingt lesen, *wir* können nicht hellsehen.

Datenauswerten ist fast ne Wissenschaft für sich Wenn ihr digitale Sensoren habt, dann wär's nicht schlecht einen Blick auf DSP Technicken zu werfen (Bücher darüber gibt es viele). Wie man vermeidet, dass man Daten nicht mehrfach liest, hängt wieder vom Sensor, Bus, Abtastrate, Treibern, usw. ab. *Das* können wir auch nicht hellsehen, siehe Datenblatt des jeweiligen Sensors.

Naja die Daten die der Master haben will sind
Momentan in 5 Matrizen (20x20) weil in Matlab.
Für C müsst man das hald optimieren denk ich.

Master ist hald auf selben Prozessor.
und ist gut möglich das der noch andere Programme die ähnliche Aufgaben haben abfragt.

Sorry das ich jetzt immer Sensoren geschrieben habe.
Es sind natürlich wie in meiner Zeichnung Sensor-Programme,
weshalb eben auch Programm-Kommunikation (Prozess Kommunikation) gesucht ist.
Die Sensoren-Programme haben schon die Sensoren angesprochen,
die Daten abgeholt, vorgefiltert und spucken sie momentan als File aus.
In Tabellen mit 15 Spalten.
Theoretisch kommen dann pro Sekunde mindestens 30 Zeilen dazu
(kann auch gut mal das 10fach sein). (ist ne Kamera)

Ich denke meine Problem bei der Entscheidungsfindung sind

Das ich bei den verschiedenen Verfahren
(Pipes, Shared Memory, Message Queues, Unix Sockets und Signals)
nicht nur nicht weiß wie man sie exakt anwendet,
sondern ihre Grundlogik nicht kenne, und damit nicht ihre Vor/Nachteile abwiegen kann.

2)auf 1) resultiert auch, das ich mir damit keine Kommunikationslogik vorstellen kann.
Weil ich Matlab einfach mit Testaten, also einer vollständigen Tabelle (mit paar 1000nd)
Werten Arbeite die ich einfach zu beginn rein Lade, und dann Zeile für Zeile durcharbeite.

Muss wohl schauen wo ich einen kürzeren überblick über diese IPC- Möglichkeiten finde als "bgipc"

Fabeltier

Hallo, ich geb noch mal meinen Senf dazu

Also ich denke auch, dass Du Dich vllt mehr um den Aufbau Deiner Daemons, Childs bzw Threads kuemmern solltest, als noch zusaetzlich um die Treiberimplementierung und deren digitale Signal Auswertung selber.

Die Idee mit der "Kommunikations API" halte ich fuer sehr wichtig oder anders gesagt, halte ich es zumindest allgemein schon fuer wichtig eher auf Interfaces hin zu programmieren. Da Du ja schon sagst dass Du auf einem Embedded System arbeiten wirst, noch ein paar Dinge die mir dazu einfallen. Soll das ganze eigentlich echtzeitfaehig sein? Das heisst fuer Dich als Programmierer v.a. dass einige Deiner Funktionen mit der Prioritaet eines Systemcalls laufen muessen. Die Programmierung kann dadurch etwas komplizierter werden und ich weiss nicht wie weit RT Linux momentan schon ist, aber der Klassiker auf diesem Bereich ist dann doch immer noch VxWorks (nicht gratis!). [zumindest war er das 2008 noch].

Weil Du gerade von "Sensoren" sprichst, faellt mir da TinyOS ein, das v.a. fuer Sensor Netzwerke verwendet wird, das verwendet einen eigenen C Dialekt "nesC" (etwas eingeschraenkter, afair), und afair sind alle Calls nonblocking.

Gut, aber um das nicht allzu komplex werden zu lassen, denke ich, muesste ein Prototyp auf Linux mit ein paar Prozessen und Kommunikation per Unix Socket oder sowas, fuers erste locker reichen. Kompliziert wrids von alleine, gerade wenn man das das erste mal versucht. Viel Spass!

Also ich denke auch, dass Du Dich vllt mehr um den Aufbau Deiner Daemons, Childs bzw Threads kuemmern solltest, als noch zusaetzlich um die Treiberimplementierung und deren digitale Signal Auswertung selber.

Den Satz verstehe ich nicht ganz.
Naja ich suche nach ne passenden Lösung für die Programm die miteinander Kommunizieren Einerseits einen Weg der einbahn mäßig viele Daten Liefer (von den Sensoren zu mir) (Die Sensoren werden von nem anderen Programm abgefragt, aber wie eben dieses die Daten an mich liefert ist noch nicht klar) und andererseits die Abfrage vom Master. Hab da eben keinen Plan wie so abfragen zw.Programmen funktionieren, und das ganze jetzt mal ganz unabhängig davon ob embedded oder nicht.

supertux

peter-s schrieb:

Also ich denke auch, dass Du Dich vllt mehr um den Aufbau Deiner Daemons, Childs bzw Threads kuemmern solltest, als noch zusaetzlich um die Treiberimplementierung und deren digitale Signal Auswertung selber.

Den Satz verstehe ich nicht ganz.

ganz einfach, du solltest dir nur Gedanken machen, um den Teil, was du schreiben musst.

peter-s schrieb:

Naja ich suche nach ne passenden Lösung für die Programm die miteinander Kommunizieren

wir können dir nicht helfen, wenn du zu waage bist, du lieferst einfach viel zu wenig Information, so dass wir nur von generellen Kozepten reden können anstatt konkrete Vorschläge zu machen.

- was musst du denn genau alles schreiben? Den Client? den Master?
- wer macht den Rest?
- was ist bereits programmiert?
- wird alles auf dem selben Rechner laufen?
- müssen alle von einander getrennte Programme sein?

peter-s schrieb:

Einerseits einen Weg der einbahn mäßig viele Daten Liefer (von den Sensoren zu mir) (Die Sensoren werden von nem anderen Programm abgefragt, aber wie eben dieses die Daten an mich liefert ist noch nicht klar) und andererseits die Abfrage vom Master. Hab da eben keinen Plan wie so abfragen zw.Programmen funktionieren, und das ganze jetzt mal ganz unabhängig davon ob embedded oder nicht.

das hab ich aber schon 2 Mal gesagt. Wenn es die Programme nicht gibt, dann musst du oder dein Team, sich zuerst ein Protokoll überlegen, denn nur ihr kennt die Daten, wie sie vorliegen, wie viele es sind, usw. Siehe meinen letzten Post, oder liest du denn überhaupt unsere Antworten? Wenn nicht, dann können wir alle einfach den Thread vergessen.

Meine grobe Vorgehensweise wäre:
Falls es alle Komponenten nicht gibt und alle auf dem selber ES laufen sollen und zwar als eigenständige Programme:

1. Protokoll zum generellen Datenaustausch überlegen. Das kann ein einfaches 'Text' Protokoll, XML, oder was ganzs schweres sein, je nachdem welche Anforderungen ich hab. Ich würde am wahrscheinlichsten Sockets basiert arbeiten mit einem XML-like Protokoll.
2. das gesamte Team muss dem Vorschlag zustimmen
3. ich schreib eine Bibliothek, die das ausgedachte Protokoll implementiert und gebe damit eine API frei, um Daten miteinander auszutauschen.
4. Der/Die Miterabeiter/in, der/die den Master schreibt, kennt die Bibliothek und verwendet sie, um eine Schnittstelle zu schaffen, so dass er mit Clients Daten mittels der Bibliothek austauschen können
5. Der/Die Miterabeiter/in, der/die die Clients schreiben, kennen ebenfalls die Bibliothek und verwenden diese um sich mit dem Master zu verbinden, und Datenaustauschen, ebenso um Daten von den Sensorprogrammen zu bekommen.