Arm Mbed OS support forum

Clarification on OS 6 Empty vs. OS 6 Bare Metal Example Programs (1.0.0)

I am right in thinking that to convert the OS 6 empty example program into a bare metal one, it just involves adding a mbed_app.json with the same contents as the bare-metal example?

I’ve tried this and added some blinky code including the following

ThisThread::sleep_for();

and it compiles fine. Whereas the bare-metal blinky seems to use

thread_sleep_for();

So I’m a little confused as the best approach to use for bare-metal: ThisThread::sleep_for() or thread_sleep_for()?

Thanks!

Hello Craig,

Since the ThisThread::sleep_for() is defined as

void ThisThread::sleep_for(Clock::duration_u32 rel_time)
{
#if MBED_CONF_RTOS_PRESENT
    osStatus_t status = osDelay(rel_time.count());
    MBED_ASSERT(status == osOK);
#else
    thread_sleep_for(rel_time.count());
#endif
}

it calls the thread_sleep_for function when MBED_CONF_RTOS_PRESENT is not defined (which is the case with bare-metal). So they both seem to provide the same functionality but a bare-metal program calling directly thread_sleep_for could be smaller and faster (because of less calls to subroutines). However, that also depends also on the code optimization performed by the used compiler.

Best regards,

Zoltan

2 Likes

They are completely equivalent - one is in C++, the other in C.

As Zoltan said, ThisThread::sleep_for() maps to thread_sleep_for() in the case of bare-metal (i.e. no RTOS). Conversely, when RTOS is available, thread_sleep_for() maps to ThisThread::sleep_for():

    void thread_sleep_for(uint32_t millisec)
    {
        auto d = duration<uint32_t, std::milli>(millisec);
#if MBED_CONF_RTOS_PRESENT
        rtos::ThisThread::sleep_for(d);
#else
        // Undocumented, but osDelay(UINT32_MAX) does actually sleep forever
        mbed::internal::do_timed_sleep_relative_or_forever(d);
#endif
    }
2 Likes

Thanks both! I have been using OS 2 for my teaching and this summer plan to port to OS 6. I need to decide whether to go down the bare-metal route or not (we focus on the device drivers mainly, no RTOS). I just want to be sure to as if the students start to see different ways of doing things, they can quickly become confused (as can I!).