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
and it compiles fine. Whereas the bare-metal blinky seems to use
So I’m a little confused as the best approach to use for bare-metal: ThisThread::sleep_for() or thread_sleep_for()?
ThisThread::sleep_for() is defined as
void ThisThread::sleep_for(Clock::duration_u32 rel_time)
osStatus_t status = osDelay(rel_time.count());
MBED_ASSERT(status == osOK);
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.
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
void thread_sleep_for(uint32_t millisec)
auto d = duration<uint32_t, std::milli>(millisec);
// Undocumented, but osDelay(UINT32_MAX) does actually sleep forever
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!).