search

ArduCAM / ArduCAM_USB_Camera_Shield

This is the repository for ArduCAM USB Camera Shield
125 stars 71 forks source link

Question about multithreading #50

Open dgalland opened 6 years ago

dgalland commented 6 years ago

Hello, In theory, multithreading has two interests For intensive CPU applications balance computing between processors, this is not really the case here Allow threads to concurrently execute IO operations even if they are blocking

All demos create two threads The first thread loops on: ArduCam_captureImage (handle); Launch an image capture task. It seems that this call is not blocking and therefore we add without limit capture tasks?

The second thread loops on: ArduCam_availableImage (handle) Check if the image is available for reading FIFO ArduCam_readImage (handle, frameData) Read a picture data from image FIFO These calls are not blocking and the consequence is that we consume 100% CPU time in this polling It would be better if the avalaibleImage call or the readImage call were blocking

I'm trying now to read a single image

If without creating a thread I try the following sequence ... ArduCam_captureImage (handle); while (ArduCam_availableImage (handle) <= 0) ; ArduCam_readImage (handle, frameData); the program loop without being able to read an image I do not understand why? ...

Finally, how to capture and read a single image? There seems to be a setMode and getSingleFrame functions but not documented Thanks for your attention Dominique Galland

ArduCAM commented 6 years ago

The capture thread just keeps read the data from USB side as fast as possible. The read thread let user to get the image then do processing, you can add sleep in this thread to avoid polling. You can find the following example to get single frame from the camera. ArduCam_Demo_test.txt

dgalland commented 6 years ago

Thanks for your reply ! So I understand that the design with two threads is an absolute necessity, the driver can not work without it. It would be easier for the end user to have these threads located in the driver itself, so we could have written: startCapture (only once) while readFrame (IO blocking until a frame is avalaibel) stopCapture Yes to avoid intensive cpu polling we can add as a workaround a sleep, but how long? Here too, a blocking IO will be easier But I'm not a driver programmer and I do not know if all this is possible ! Note that these are just simple thoughts, we can very well achieve our goal with the current design! Regards