Serial comms & USB camera in parallel/threaded?

Question

My project is currently using OpenCV to controll a pair of motors via hardware PWM (am using the pigpio library for GPIO control). The video input is from a USB webcam.

I would like to add some serial comms via USB without interupting the video stream. So I'm assuming I can have the serial & video on seperate threads?

Is this possible in Python or will I need to recode in C or Java?

Or can I have 2 seperate Python codes running which have access to a shared memory? Edit: I would like the video stream to make use of data from the serial stream

Answer 1

Interprocess (or interthread) communication has two major challenges, concurrency and scheduling. Concurrency deals with the situation where access to the same memory can happen at the same time in multiple places. Scheduling deals with the situation where one thread waits on another because it is waiting for it to provide information or because there is no free CPU time, there is less risk on multicore system like RPI, but major for single core embedded MCU as only one thread is alive at the same time.

Depending on the volume of information, a pipe or socket would be a very Linux way to handle this using completely separate processes, with the vision thread "reading" from the.serial comms thread as if from a file, but it is pipe (fifo) or socket. The serial thread is writing data to the fifo or socket. One can check the fifo or socket to see if a message is available in a non-blocking way.

For single application, multiple threads can exchange data with qeues or mailboxes, there are other interprocess tools. They can also simply use common global variables. Note that even a single shared variable has concurrency problems, but if you can tollerate corrupted data occasionally one can get away with no special concurrency protection if there is only one reader and one writer thread

A simple approach that avoids all blocking calls is tor have two variables, one being read from and one to write to, and swap every serial message. Depending on load a third buffer maybe added as a backup

It is not recommended to use locks for concurrency in this case because they will always lead to problems with thread jitter and lock thrashing, since you have one direction of communication it isn't the best solution. (Locks are good to manage a single shared resource with multiple subscribers -like a single serial port used by several programs)

If the serial read is.occasional and brief it can also be done synchronously with vision thread every several few cycles , however if it done often or there is complex actions like waiting for response this may impact performance/fps and CPU load.