C ++ Qt异步进程快速计时建议

Question

i'm currently dealing with a Qt GUI i have to set up for a measurement device. The device is working with a frame grabber card which grabs images from a line camera really fast. My image processing which is not that complex takes 0.2ms to complete, and it takes about 40ms to display the signal and the processing result with QCustomPlot which is totally okay. Besides the GUI output the processed signal will also be put out as an analog signal by a NI DAQ device.

My problem is that i have to update the analog signal with a constant frequency and still update the GUI from time to time.

My current approach or idea was to create a data pool thread and two worker threads. One worker thread receives the data from the frame grabber, processes it an updates the data pool. The second worker thread updates the analog channel of the NI DAQ with a certain frequency of about 2-5kHz given by a clock in the NI DAQ device. And the GUI thread would read the data pool from to time to time to update the signal display with a rate of about 20-30Hz.

I wanted to use the Qt thread management and he signal-and-slot mechanism because of its "simplicity" and because i already worked with threads in combination with Qt and its thread classes.

Is there maybe a better way, does somebody have an idead or any suggestion? Is it possible that i get problems in the timing of the threads?

Furhtermore is it possible to assign one thread to one single CPU core on a multi core CPU, so that this core only processes this single thread?

Answer 1

Is there maybe a better way, does somebody have an idead or any suggestion? Is it possible that i get problems in the timing of the threads?

Signal/Slot mechanism is fine, try it and if you get into performance issues you can still try to find another approach. I used Signal/Slot Mechanism for real-time video processing with QAbstractVideoSurface and Mediaplayer. It worked for me.

Furhtermore is it possible to assign one thread to one single CPU core on a multi core CPU, so that this core only processes this single thread?

Why would you do that? The operating system or threading library has a scheduler, which takes care of such things. As long you got no good reason doing this yourself, you should just use the existing way.

Answer 2

I would try it with three threads: 1)UI thread, 2)grab-and-process thread, 3)analogue output thread.

The trick is to use a triple buffer to connect output of grab-and-process to input of analogue output.

Say, at moment t , thread(2) finishes processing frame[(t+0)%3] , change output destination to frame[(t+1)%3] immediately, and notifies thread(3), which is looping through data in frame[(t+2)%3] , to switch to frame[(t+0)%3] when appropriate.

I used this technique when I was working on an image processing project that has a 10fps processing frame rate and a 60fps NTSC output frame rate. To eliminate the tearing effect , a circular buffer with three buffers is the least.