If you are having issues with the exercises, please create a ticket on DevZone:
Click or drag files to this area to upload. You can upload up to 2 files.

Bare-metal vs RTOS programming

Bare-metal application

A bare-metal application, at its core, is just a big loop in the main function right after you have initialized the hardware/software at the device powerup/reset routines. All the execution is sequential logic, in other words, all instructions are executed in sequence unless interrupted by an interrupt service routine (ISR). So the only non-sequential logic you have in bare-metal programming makes use of exceptions.

While bare-metal programming is often associated with greater power efficiency, reduced memory usage, and potentially faster performance, this isn’t always the case. For simple applications, employing a single sequential logic loop can suffice, benefiting from the inherent power efficiency and memory conservation of bare-metal programs. However, as application complexity grows, maintaining firmware architecture solely through sequential logic can become challenging, unscalable, and unportable. This is where the utilization of a real-time operating system (RTOS) proves advantageous.

RTOS-based application

Designing your application on top of an operating system allows you to have multiple concurrent logics in your application running in different execution units called threads, making your architecture simple, as opposed to just one sequential logic running in your main function in standalone mode.

The core of an RTOS is called the kernel and controls everything in the system. The other big added advantage is the huge resources of libraries, drivers, and protocol stacks that are natively available by an RTOS like Zephyr.

Interrupt Service Routines (ISRs) are available in both RTOS-based applications and bare-metal applications. They are generated asynchronously by the different devices drivers configured(including callback functions) and protocols stacks.

Visualization of bare-metal (left) and RTOS-based (right) application


Having the main() function is optional in Zephyr RTOS-based applications. This is because the main thread automatically spawned by the RTOS will do the necessary RTOS initialization, including scheduler/kernel setup, and core drivers setup.

After that, it will try to call the user-defined main(), if one exists. If no main() function exists, the main thread will exit. The system will still be functional and other threads can be scheduled normally.

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.