0

I'm hoping that this is more relevant to the RPi exchange as a lot of my key concerns relate to issues with GPIO/PWM/serial bus usage with concurrency.

I'm currently writing software for a robotics application that uses a Raspberry Pi Zero (single core CPU) and which will use Python to manage multiple tasks at once. Some of these tasks can be asynchronous and need to occur either regularly or constantly; whereas others will have very strict sequencing (robotics and imaging, mainly).

Examples of the asynchronous/continuous tasks would include:

  • TCP socket constantly listening for commands from networked computer (vital this is always listening and available)

  • UDP socket to send telemetry data

  • Regularly communicating with and sending heartbeat data to connected microcontrollers via UART

  • TCP again to send large volumes of imaging data on regular intervals without blocking other processes

Synchronized tasks that must occur in order would include:

  • Polling serial and I2C sensor arrays and logging data

  • Acting on sensor data in turn (e.g. commanding actuators)

  • Following a sequence of commanded events

  • Sending event telemetry via UDP if something specific occurs

  • Using Pi camera for imaging/video capture (particularly worried about this blocking)

  • Logging data to SD cards, both using logger (thread-safe, not sure about asyncio-safe) and camera data

So, my question is: are threads/asyncio/green threads appropriate solutions for implementing this, or am I going to run into major issues, especially with respect to using GPIO/PWM/I2C etc?

I was first thinking of using threads for all the asynchronous things that can occur simultaneously, especially for the always-listening TCP socket, but I'm wary of race conditions and communicating between threads. I imagine found thread-safe queues would alleviate most worries, though. ThreadPoolExecutor could also help here.

I've been exploring the asyncio library recently, too, which might suit my needs - especially if I can dynamically add and remove tasks to this in response to TCP commands - but I'm not sure if I'm getting far too complicated with this when a couple of threads might work? The asyncio library looks great and I'm keen to learn it, but I only have a few months for this project and it looks like complexity could spiral. I am not certain whether it is suitable for tasks involving GPIO/PWM especially - also nervous about implementation with UART communication to a microcontroller.

Finally, I've looked into green threads as well, though it looks as though they come with their own pitfalls and traps.

I greatly appreciate any advice on this, thank you.

  • 2
    You mention "threads" and Python. Standard interpreted Python doesn't support concurrent multi-threading due to the Global Interpreter Lock (GIL). Independent processes (not threads) would each get their own GIL so they can run concurrently. But also keep in mind the Pi Zero is a single-core CPU. (A Pi 3A+ and B+ are both quad-core.) – Tim Campbell Jul 23 at 15:51
  • 2
    This appears to be a general programming question. – joan Jul 23 at 15:58
  • 1
    Thanks for the input, I'm reading up on the GIL now. It would've been great to have multi-processing, but unfortunately we need to stick with the Zero due to space/power constraints. I understand threads won't run truly concurrently, but I imagine - similarly to asyncio - it would still help with performing multiple tasks considering some will be I/O bound, and the TCP telecommand socket could, for example, be waiting while other work is performed. In this sense I still hope threading (or asyncio etc.) could help with task management i.e. 'concurrent' sockets, robot commands, etc. – TheFaustie Jul 23 at 16:01
  • I remember that Rpi Thonny Python 3.7.3 can use multi-processing which, unlike mult-threading, does not have GIL problem. Moreover, python 3.7.3+ has TCP APIs. So I guess python 3.7.3+ multi-threading is worth trying, at least in the prototyping stage. – tlfong01 Jul 24 at 0:33
  • Unfortunately I think as Tim mentioned, that's not a possibility with a single-core CPU - unfortunate as I would've loved to play around with multi-processing. Thanks anyway, and the TCP APIs is a great point I'll look into and make sure I understand properly. Thanks! – TheFaustie Jul 24 at 15:29
0

Some of these tasks can be asynchronous and need to occur either regularly or constantly; whereas others will have very strict sequencing (robotics and imaging, mainly).

Regularly is not something belonging to time-shared systems. If you want to get regular, you don't want an OS - or you want to run an RTOS. The choice of language is then basically irrelevant; you will NOT get your accuracy by design.

Now, most of the stuff you mention can be driven in a way it introduces very minimal lag and it is possible to build a program which does all those things in a single thread.

It is extremely hard to do all those things without ever blocking anything as 'blocking' is the basic construct of thread synchronization and if you don't want to do it your only option is being "lock-free". Not a thing you would do for much more than a data structure such as a queue or a set.

Keep in mind for example listen isn't realtime by any means as you have no control on the WiFi you'll be using to connect to the Zero! Waiting half a second for listen to be processed (while you do something else) is not going to change a thing.

I am not certain whether it is suitable for tasks involving GPIO/PWM especially - also nervous about implementation with UART communication to a microcontroller. Similar applies to SPI and I2C - they are basically not an issue.

UARTs are asynchronous by design. Your micro depending on its firmware might time out (but it's more a theorical possibility than real issue); the Pi can guarantee at hardware level the signal timings for each UART frame will be just right. Similar guarantees hold for GPIOs and to a certain degree to PWM.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.