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()?
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 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
}
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!).