What is bare metal embedded programming?

Bare metal embedded programming refers to developing firmware directly on microcontroller hardware, without relying on any operating system (OS). The programmer writes all the low-level code to directly interface with the processor and peripherals. This provides precise control over the hardware but requires in-depth knowledge of the specific microcontroller architecture.

Key Characteristics of Bare Metal Embedded Programming

• No operating system (OS) – The firmware runs directly on the hardware without any OS abstraction layer.
• Direct hardware access – The code directly configures and manages the microcontroller’s registers, memory, peripherals etc.
• Precise timing control – The programmer has complete control over the instruction timing cycles.
• Limited external dependencies – Code is self-contained with few calls to external libraries.
• constrained optimizations – Code has to be tightly optimized to fit in small memory footprint.
• Manual resource management – The developer directly allocates and deallocates resources like memory, peripherals etc.

Why Go Bare Metal?

Here are some of the key advantages of bare metal embedded programming:

• Predictability – No OS means no unexpected context switches or thread priorities to disrupt program flow.
• Determinism – Precise control over instruction timing gives deterministic execution.
• Optimized performance – No OS overhead allows pushing the hardware to its limits.
• Low memory footprint – No OS minimizes RAM usage allowing smaller and cheaper microcontrollers.
• Low power – Carefully optimized code reduces power consumption.
• Hardware access – Direct low-level access to peripherals and hardware features.

Bare metal programming gives real-time performance and complete control required in many embedded systems. Some examples include:

• Small IoT edge devices
• Wearables and medical devices
• Industrial automation systems
• Automotive body controllers
• Low-cost microcontrollers

Challenges of Bare Metal Programming

However, bare metal development also poses some key challenges:

• Steep learning curve – Requires in-depth knowledge of the hardware architecture and toolchain.
• Portability – Code is tightly coupled to the specific microcontroller.
• Limited debugging – On-chip debugging facilities are more constrained.
• No standard API – The developer manages everything manually.
• Increased testing – Hardware-specific code requires extensive testing.
• Limited features – Advanced features like networking, file system need to be implemented manually.

While these factors increase development effort, they may be an acceptable trade-off for the gains in performance, determinism and control.

Typical Bare Metal Embedded System Architecture

A typical bare metal system consists of:

• Microcontroller – This is the heart of the system. Popular choices include ARM Cortex-M, AVR, PIC, 8051 etc.
• Clock circuit – Provides clock signals to drive the microcontroller.
• Memory – On-chip memory like flash and RAM. External memory may be added e.g. EEPROM.
• Power supply – Regulated power for the circuits. May include brown-out detection.
• Peripherals – On-chip peripherals like GPIO, timers, ADC etc. External peripherals can be interfaced over buses like SPI, I2C.
• Programming interface – Debug access like JTAG or SWD for programming and debugging.

The main program logic and hardware interfacing code runs directly on the microcontroller. Typically no other software component is present between the hardware and firmware.

Bare Metal Programming Process

Developing bare metal embedded systems requires careful planning and rigor compared to OS-based development. Here is a typical workflow:

1. Requirements analysis – Define the exact hardware and firmware capabilities needed.
2. Microcontroller selection – Pick MCU with suitable features, peripherals, memory and interfaces.
3. Architecture design – Plan out overall system architecture and component interfaces.
4. Toolchain setup – Get appropriate compiler, debugger and programmer tools.
5. Board bring-up – Initialize core MCU features like clocks, memory, GPIO etc.
6. Peripheral driver development – Low-level drivers for on-chip and external peripherals.
7. Application coding – Implement main program logic on top of the drivers.
8. Testing and debug – Validate functionality via unit testing, system integration, and debugging.

Careful design is necessary to fit code into limited MCU memory and meet timing requirements. Coding standards like MISRA C help enforce portable code.

Bare Metal Programming Models

Several coding models and architectures are commonly used in bare metal systems:

Procedural

All code resides in a single main loop. Peripherals are initialized at the start and application code runs sequentially in the main loop. Simple but suffers from lack of structure in complex systems.

State Machine

The application is modeled as a state machine with distinct states and explicit transitions between them. State functions encapsulate state behavior. State machines impose discipline but can get complex with many states.

Event-Driven

Peripherals and resources are abstracted into objects that emit events on specific activity. Event handler functions implement application logic triggered by specific events. This provides separation of concerns but requires complex event propagation mechanisms.

Interrupt-Driven

Hardware interrupts handle time-critical tasks while main loop runs control tasks. Fast response to critical events but requires careful design to avoid race conditions and resource conflicts.

Cooperative Multitasking

Application tasks cooperatively yield control periodically allowing time-sharing of CPU cycles. Manual context switching gives more control than preemptive multitasking but risks deadlocks.

Preemptive Multitasking

Tasks run in separate contexts and preempted based on priorities/timeslicing. Harder to implement but prevents deadlocks and ensures task isolation.

Bare Metal Programming Tools and Environments

Here are some common tools used for bare metal embedded programming:

• Compilers – Convert C/C++ code to target processor instructions. GCC, LLVM, IAR, Keil compilers are popular.
• Debuggers – Debug, trace and profile code executing on the target. Support stepping, watchpoints, variable inspection etc.
• Emulators – Emulate target processor execution. Allow debugging before hardware available.
• Programmers – Flash binary onto target system memory chips. e.g. JTAG and SWD interfaces.
• Simulator – Simulate microcontroller and some peripherals. Fast but simplified model.
• IDEs – Integrated development environments like Eclipse, Keil MDK combining editor, compiler, debugger.

Unit testing frameworks allow automation of tests. Static analysis helps detect bugs before running code.

Case Study: Bare metal Firmware for a PWM-controlled LED

Let’s go through a simple example of bare metal firmware development using an ARM Cortex-M4 microcontroller.

The goal is to control the brightness of an LED using pulse width modulation (PWM). The firmware should provide APIs for:

• Initialize system clocks, GPIO pins, timers and PWM.
• PWM output with configurable duty cycle to control LED brightness.
• Control LED On/Off state.

We will use a Cortex-M4 processor on a Nucleo development board. The board provides a user LED connected to the MCU GPIO pin PA5 supporting hardware PWM.

Using the MCU datasheet and programming manual, we setup the clock, GPIO, timers and PWM modules with direct register writes in the board bring-up code. PWM is configured for 1 KHz frequency and 10-bit resolution.

The LED control APIs use the configured PWM to output waveforms with programmed duty cycle. Timer counters allow accurate PWM period timing and GPIO configuration toggles the LED.

A main loop sets LED brightness by calling the control APIs with different duty cycle values. It demonstrates smoothly increasing and decreasing brightness levels.

The small self-contained firmware provides fine-grained hardware control meeting the requirements. With careful coding and testing, the bare metal approach allows predictably driving the LED with accurate PWM control.