POSIX OS Interprocess Communication

[RevoAutomation]

Dear experts,

it would be great, if microPython could communicate with other (maybe native) applications on FreeRTOS, Zephyr or RT-Thread. Both offer IPC mechanisms to let threads communicate by mailboxes, semaphores and pipes. (for example https://www.rt-thread.io/document/site/programming-manual/ipc2/ipc2/)

On Zephyr or RT-Thread are so many existing applications, written in C, what could interact with a microphython application by such an IPC mechanism. The big Python do have IPC, the POSIX variant on Linux.

Or is there an other way, how a microPython application can communicate resource efficient with an other app on Zephyr or RT/Thread? Someone could write something into a filesystem, and the other thread read it back, but that sounds very inefficient. Pins can raise an interrupt, but not transmit message data. Using assembly to write into a specific register? This may crash the RTOS.

What do you think?
Michael

[stinos]

Have you considered using sockets? It's cross-platform (unlike MCU-specific mailboxes etc) so would work for any port supporting the socket module.

[RevoAutomation]

Have you considered using sockets? It's cross-platform (unlike MCU-specific mailboxes etc) so would work for any port supporting the socket module.

Hmmmm, Sockets are for network communication. I am looking for a efficient a on-chip, thread-to-thread communication. Sockets are build on top of a network stack, what itself is resource intensive. Even Sockets support something like "localhost" to "localhost", it would be quite ineffecive.

Mailboxes are NOT MCU specific, as long as the RTOS cover this. For example, Zephyr or RT-Thread or even FreeRTOS of one unique Mailbox interface independent of the MCU architecture or chip. Thanks to POSIX, they may even be OS indepenent. Only a bare-metal microPython could not access the RTOS implementation, but the bare-metal microPython also dont need this. No RTOS, no foreign apps to interface.

The official way for every application, what run on top of Zephyr or RT-Thread or FreeRTOS, to communicate with other threads or processes, is the use of the official IPC (Interprocess communication) API. This is the most effective, in terms of cpu cycles and memory consumption, communication. While the ports of microPython to Zephyr or RT-Thread or FreeRTOS could easily implement Mailboxes, the question is how bring these data into the microPython main loop.

[stinos]

Sockets are for network communication

If 2 processes communicate then that can be acalled IPC, irregardless of the underlying layer.

I am looking for a efficient a on-chip, thread-to-thread communication.

Sorry I didn't really get that; because your title is 'POSIX OS Interprocess Communication' :)

[RevoAutomation]

Sockets are for network communication

If 2 processes communicate then that can be acalled IPC, irregardless of the underlying layer.

I am looking for a efficient a on-chip, thread-to-thread communication.

Sorry I didn't really get that; because your title is 'POSIX OS Interprocess Communication' :)

yes, I forgot the word efficient in the title. There are a lot of ways to let 2 processes communicate, including sockets. Only a few are efficient, and those are offered by the OS. For example, FreeRTOS have no network stack, so LwIP must run in top of if. But FreeRTOS have POSIX compliant IPC with Semaphores, Pipes and Mailboxes. So, why not implement it when its available?

Using a truck to buy a box of cigarettes is inefficient, even it can be done so. Small MCUs are very limited with resources. These are the minimum memory requirements of LwIP (from https://community.nxp.com/t5/LPCware-Archive-Content/LWIP-memory-requirements/ta-p/1123380)
Total RO Size (Code + RO Data) 43800 ( 42.77kB)
Total RW Size (RW Data + ZI Data) 67208 ( 65.63kB)
Total ROM Size (Code + RO Data + RW Data) 43848 ( 42.82kB)

So 65kB RAM only to implement IPC. The mailbox interface may require 1kB, or less.

[andrewleech]

FWIW sockets are quite efficient if the port/board you're using already has networking so has LWIP enabled anyway - this then also has great software support in that you can choose any number of robust communication / RPC libraries to run on top of them etc.

Going back to your original suggestion of IPC APIs though, yeah I think exposing them in micropython would be a great idea!
They're pretty likely to end up being _port _ specific though...

Yes it would make sense for the zephyr port to provide a python wrapper over its IPC APIs, same goes for esp32 and if any other "multi-process RTOS" with IPC becomes officially supported that would be good too.

Ideally anyone interested in implementing this should attempt to design a machine.IPC API that could be "wired up" to both of these ports APIs along with any hypothetical port providing "POSIX inter-process semaphores, shared memory and message queues on platforms supporting the POSIX Realtime Extensions a.k.a. POSIX 1003.1b-1993."
I don't know these APIs myself, maybe all three are pretty well aligned already?

Maybe this (C)python package could be used as a guide for designing what a python API for these functions could look like: https://github.com/osvenskan/posix_ipc

Then it's "simply" a matter of writing the C code to create that module and some hopefully simple wrapper functions to expose the underlying C functions to python.

Lastly, you'll need to define/document a build process for these ports to show users how to compile a separate C process into the micropython firmware on these platforms, I'm not sure how easy that would be? Maybe not to hard using the user-C-modules build pattern.

[andrewleech]

My point about port specific was based on me not knowing if the supported ports actually implement POSIX threads? Zephyr maybe? There is no "freertos" port here, esp32 uses it sure, but their APIs for everything are often customised.
There's also no RT-Thread port here.

A different suggestion that does already exist in micropython is OpenAMP.
It's an IPC mechanism designed for communicating between processes running on different processors but it's intended to be efficient and async. It's implemented here on some ports so could be extended where needed.

[RevoAutomation]

OpenAMP
Wow, OpenAMP looks really interesting. Thanks for hinting this. Does OpenAMP run on all micropython supported MCUs, also those with just 1 core? If so, I would just use OpenAMP.

[stinos]

I couldn't find how much RAM OpenAMP uses, but it's quite a lot of code.

[andrewleech]

I haven't actually used it myself so can't really comment on its overheads. I don't know if it's available on all ports yet or what it takes to enable it. I only know about it because I might be using a large dual core processor on a project soon so it's on my list of things to look into closer.

[RevoAutomation]

I haven't actually used it myself so can't really comment on its overheads. I don't know if it's available on all ports yet or what it takes to enable it. I only know about it because I might be using a large dual core processor on a project soon so it's on my list of things to look into closer.

The more I read about OpenAMP, the more I realize that OpenAMP is made to let 2 OS run on the same chip. Examples are these FPGAs with hard- and softcores, the STM32 M7+M4 cores (as used by Arduino Giga), these NXP MX6/MX7 multicore, TI AM57x and so on. The then enable communication between Linux on one core, and Zephyr or FreeRTOS on the other core. So it will not the most efficient way to communicate in the same OS, with just 1 core.

So the OS IPC mechanism with Semaphores, pipes or Mailboxes, to communicate on 1 OS, with 1 core, is still the most efficient. As I see it.