Multiple Task support

boron
Tags: #<Tag:0x00007f1ca3727150>

#1

Hello,

I’m new to the Particle community and I’m try to get as much information as possible before diving into DeviceOS code to look for some desired functionalities.

For this new project I’m looking to develop a modular system with tasks handling specific services and probably interacting via dispatcher/broker internally.

From what I learn so far about the DeviceOS the user application is running under a thread? in the DeviceOS task itself; is it correct?

Next I would like to know what we current have in terms of supporting user tasks running at the same level of the DeviceOS, or if some tried it before.

And finally if a bare-minimal version of DeviceOS is offered in case I want to build a custom monolithic firmware incorporating only some aspects of the DeviceOS as a driver lib of sorts, and building on top of it.

Thank you for your help!


#2

Yes, you are right, by default application and system are running on the same FreeRTOS thread.
To decouple the two, you can just use SYSTEM_THREAD(ENABLED)

To spawn additional threads for your desired tasks you can read here


#3

Tnx @ScruffR , I read the post and the documentation section and it was really helpful.

According to the documentation I noticed that the “loop” function, is being called even with threads enable.

Is it possible to disable this behavior to avoid unnecessary context switching?


#4

No you cannot disable the main/primary application thread, but since that will be there by default, why not use it productively?


#5

I see, tnx!

Definitely, I sure can think on uses for that, but the my main focus is that all tasks/modules are idle most of the time.


#6

How many threads are you intending to spin up?
While this might appear an appealing strategy, have you considered the overhead you are creating with that?
Each thread will require its own stack, context, potential synchronisation, … for hardly any action I gather.
Is this really worth it?

Others fight for every single byte of RAM to accomodate their project - for that the extra overhead would make the difference between make or break.


#7

I definitely agree with you regarding the overhead, and specially the stack requirements, that’s why I’m trying to get as much information I can before start developing any component.

In fact that also bring me back to one question from the OP. Is it possible to disable some modules of the DeviceOS in order reduce the RAM usage?

Edit:
and if it really turns out to be problematic in terms of resources, I can use the same design using callbacks, as I guess you do with the “User Applications”