RTOS package is not being included for baremetal boards meaning ThisThread doesn't work

[davetcc]

After looking through the RTOS source in the mbed framework V5 and V6, I'm pretty sure that the "rtos" package should always be included into the build, even for bare-metal profile. If you look at the bare-metal examples on the mbed website, they always show rtos being included to access the special namespace ThisThread, and potentially other non-rtos constructs.

I'm not a python expert, so please forgive me if I'm wrong, but I think the problem is in the code linked below; where there seems to be an assumption that if RTOS is not enabled, then the "rtos" package is not included. However, ThisThread which is critically important in mbed 6 as many older APIs were removed, is also the prescribed way to perform yielding, sleeping and other such tasks even on bare-metal boards. Further, all other bare-metal incompatible constructs (both in CPP and H files) are protected by checks for RTOS being present.

builder-framework-mbed/platformio-build.py

Line 165 in 152ac44

if MBED_RTOS:

I've done quite a bit of research on this now, and I'm pretty sure this is the right behaviour. But this is a far from simple domain, and there could others with more experience of mbed bare-metal. Up to now, I generally don't use bare-metal, favouring only RTOS boards. However, this is probably the most useful page I found on bare-metal: https://os.mbed.com/docs/mbed-os/v6.4/bare-metal/index.html

Also, take a look at the source in .platformio/packages/framework-mbed/rtos and the source directory under there, you'll see most source is protected by:

#if MBED_CONF_RTOS_PRESENT

This is linked to the following forum post: https://community.platformio.org/t/mbed-rtos-baremetal-and-thisthread-compilation-issues/17555

[davetcc]

So there's a bit more to it than just including that directory, I tried altering my local python file to add rtos regardless. Looking at a build error I got after adding rtos to the build path, it appears that the MBED_CONF_RTOS_PRESENT (and RTOS API) flags appear to be set. It's the only way to explain how it could result in the below error:

Build file for reference:

[env:disco_f051r8]
platform = ststm32
board = disco_f051r8
framework = mbed

Main file for reference:

#include "mbed.h"
#include "rtos.h"  // <<<< this should always work - see link in first comment

DigitalOut led4(LED4);
DigitalOut led3(LED3);

bool running = true;

int main() {
    while(running) {
        led4.write(0);
        led3.write(1);

        ThisThread::yield();

        led4.write(1);
        led3.write(0);
    }

}

And the error:

In file included from C:\Users\aaaa\PLATFO~1\packages\FRA7E3~1\rtos\source\TARGET~1\rtx5\RTX\Source/rtx_lib.h:30:0,
                 from C:\Users\aaaa\.platformio\packages\framework-mbed/platform/source/mbed_os_timer.h:24,
                 from C:\Users\aaaa\.platformio\packages\framework-mbed\events\source\equeue_mbed.cpp:41:
C:\Users\aaaa\PLATFO~1\packages\FRA7E3~1\rtos\source\TARGET~1\rtx5\RTX\Source/rtx_core_c.h:30:10: fatal error: RTE_Components.h: No such file or directory  

File content around that line:

#if MBED_CONF_RTOS_PRESENT
extern "C" {
#include "rtx_lib.h" // mbed_os_timer.h:24,
}
#endif

And the modification I made:

$ diff -u platformio-build.py platformio-build.py_unlatered
--- platformio-build.py 2020-12-06 09:15:36.192960900 +0000
+++ platformio-build.py_unlatered       2020-04-02 13:20:40.000000000 +0100
@@ -176,11 +176,6 @@
     env.Append(
         CPPPATH=[join(FRAMEWORK_DIR, "cmsis", "TARGET_CORTEX_M")]
     )
-
-    src_paths.extend([
-        join(FRAMEWORK_DIR, "rtos")
-    ])
-

I've tried debugging it further, but I think this has exceeded my knowledge of platformIO internals, somehow we are ending up with MBED_CONF_RTOS_PRESENT but I just can't see how, it's certainly not there when doing a --verbose build. I do see this -D__CMSIS_RTOS -D__MBED_CMSIS_RTOS_CM which seems to be always added by mbed_toolchain.py but I cannot see any bridge between the two.

I personally don't know how many users use bare-metal, maybe not many these days, given that RTOS capable CPUs are so cheap and very power efficient. It's quite possible the best thing to do here is to leave it on the back burner.