1
\$\begingroup\$

This question already has an answer here:

I take it an ARM MCU can be run without an OS - at which point might it become necessary to install one?

Can the mbed SDK run without the mbed-os or any other mbed for that matter?

\$\endgroup\$

marked as duplicate by Bence Kaulics, Dave Tweed May 26 '16 at 19:03

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • \$\begingroup\$ You better consult the dedicated documentation. \$\endgroup\$ – Eugene Sh. May 26 '16 at 17:41
  • 2
    \$\begingroup\$ It is hardly ever necessary but it can certainly become wise once you end up spending more than a little time re-creating standard operating system services within the custom code of your application. Typically that involves things like threading or process models, and/or complex I/O such as networking and interacting with users. There will always be transition zones where a sound project can be built with or without, and absurd zones off of each end of that where the atypical choice counts as "doing things the hard way" - an OS for too small a task, or none for too big of one. \$\endgroup\$ – Chris Stratton May 26 '16 at 17:46
4
\$\begingroup\$

You never need a operating system. It's a convenience that comes at a cost. Only you can say whether the advantages outweigh the costs for your application.

In general, operating systems give you a abstracted interface to the machine's raw capabilities. The abstraction is often designed to make the application interface independent of the hardware details.

The abstraction is more than a hardware-independent layer over the real hardware. There are also abstractions added that are purely creations of the software, or are only partially assisted by hardware. For example, your ARM core can only process a single instruction sequence at a time. However, the OS can give the appearance of multiple independent threads. On systems with hardware memory protection, this can be expanded to multiple processes assumed to be hostile towards each other, each with multiple threads.

Then there are many other features usually provided by OSs, like a file system above the non-volatile storage, virtual memory, timers, semiphores, shared memory, pipes, and lots more.

All this comes at a cost, which is lots of extra cycles and lots of code between your application and the hardware. In many cases there is more than enough memory and cycles for the app, so the main cost is logistic in having to integrate your app into the OS environment.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.