boost::thread und eine Camera
-
Nicht wenn du ein Betriebssystem mit preemptiven Multitasking hast. Das soll ja gerade immer die Prozesse/Threads unterbrechen. Vielleicht hilft es was an den Prioritäten zu schrauben.
-
Natürlich sollen alle Threads mal dran kommen. Soweit ich weiß werden boost::threads aber nur an ganz bestimmten Punkten unterbrochen, z.B. sleep oder wait.
Ich vermute aber es findet ein Threadwechsel statt an einer Stelle wo ich es nicht brauchen kann, nämlich da wo mein Modul auf die Camera zugreift und eben 8,5ms Belichtung abwarten muss. Kann man dafür sorgen dass es in diesem Block nicht unterbrochen wird?
Würde das höherprisrisieren etwas bringen?Generell ist das ein Problem, da wir ein Regelungssystem bauen einen genauen Takt (1/60 Sekunden) brauchen.
-
Ich glaube diese Unterbrechungspunkte beziehen sich auf Unterbrechungen durch den User. Das Betriebsystem ist halt davon nicht betroffen. Soll es ja wie gesagt auch nicht. Wenn du das wirklich so genau brauchst, dann nimm ein Echtzeitbetriebssystem. Die Dinger sind berechenbar.
Höherpriorisieren sorgt unter Umständen dafür, daß der Thread nach einer Unterbrechung schneller wieder drankommt.
-
Warum nimmt die Kamera nicht einfach ein Bild auf und meldet sich dann wenn sie fertig ist (bei den Interessenten)?
-
Tyrdal schrieb:
Warum nimmt die Kamera nicht einfach ein Bild auf und meldet sich dann wenn sie fertig ist (bei den Interessenten)?
Die Kamera kann man Softwaretriggern, Freerunningmode und Hardwaretriggern. Wenn man sie Hardwaretriggert könnte man das so machen. Aber wie kann sie sich melden??
-
Kommt auf deine Software an. Ich programmiere gerade was mit Qt, da gibts bspw. den Signal/Slot Mechanismus um Ereignisse zu melden. Du könntest aber auch ne Threadbedingung nutzen (boost::condition_variable).
-
Tyrdal schrieb:
Kommt auf deine Software an. Ich programmiere gerade was mit Qt, da gibts bspw. den Signal/Slot Mechanismus um Ereignisse zu melden. Du könntest aber auch ne Threadbedingung nutzen (boost::condition_variable).
Aber das wäre doch wieder innerhalb des Threads der die Camera anspricht, deshalb wird das doch nicht zeitlich berechenbarer!?
-
Zeitlich berechenbar wirds sowieso nur in einem Echtzeitsystem. Evtl. wirds aber schnell genug.
-
Kannst du mir mal ein Beispielkode zeigen oder aufzeigen wie du dir das vorstellst? Die Kamera ist ja ein USB Gerät.
-
Code direkt nicht, da ich eh nicht weiß wie deine API aussieht.
Wenn du ein Bild haben fragst du ja die Kamera und die signalisiert dir irgendwann, daß ein neues da ist, richtig? Wenn ja, dann lass das Ganze doch in nem eigenen Thread laufen und pack das Bild in einen Zwischepuffer. Der andere Programmteil holt sich dann immer die Bilder aus dem Puffer. => Wenn der Puffer größer als ein Bild ist haste ein Producer-Consumer-System. Wenns nur ein Bild ist, läßt du den abholenden Thread eben auf das Eintreten der Bedingung warten (die der Kamerathread natürchlich setzen muß).