Sponsored by Nordic Semiconductor
Introduction
Imagine that you’re designing a simple Bluetooth LE temperature sensor for the new Nordic nRF54L Series. You’ve never worked with an RTOS before, and frankly, the learning curve looks steep. Thread priorities, semaphores, mutexes—it all seems like overkill for a device that just needs to read a sensor and send data over Bluetooth LE. You want to get your prototype running quickly, but you’re concerned about diving into the technical details of the Zephyr RTOS.
This is exactly why Nordic Semiconductor created the nRF Connect SDK Bare Metal option—a development solution for simple Bluetooth LE applications on nRF54L Series that doesn’t require RTOS knowledge. It offers a quicker entry point to nRF Connect SDK for developers not familiar with RTOS concepts, while still providing access to Nordic’s powerful tools and the beloved SoftDevice Bluetooth LE protocol stack.
What makes this approach particularly compelling is that you’re not locked into a decision. Both Bare Metal and Zephyr RTOS development coexist within the same SDK and nRF Connect for VS Code environment. You can start more quickly with the Bare Metal option and upgrade to the full SDK feature set of Zephyr RTOS when your application needs to grow. It’s the best of both worlds—a gentle on-ramp with a clear upgrade path.
Whether you’re migrating from the nRF5 SDK and want to leverage your existing SoftDevice knowledge, or you’re new to Nordic but want to avoid the steep learning curve of an RTOS, this guide will show you how nRF Connect SDK Bare Metal can get you to market faster with simple Bluetooth LE applications.
What is Bare Metal Programming?
The term “bare metal” might conjure images of exposed circuit boards and manual bit manipulation, but the reality is both simpler and more nuanced. At its core, bare metal programming means writing code that runs directly on the hardware without an operating system acting as an intermediary. Your code is in direct conversation with the processor and peripherals, with nothing standing between your instructions and their execution.
Think of it like the difference between driving an automatic and a manual transmission car. With an RTOS (the automatic), you tell the system what you want to do, and it handles the complexity of making it happen. With bare metal (the manual), you have direct control over every gear shift, every clutch engagement. This direct control can be more efficient and predictable, but it also means you’re responsible for not stalling the engine.
Why Bare Metal for Simple Bluetooth LE Applications?
Here’s where things get interesting. Simple Bluetooth LE applications—the kind that make up the majority of IoT devices—don’t always benefit from incorporating an RTOS. Think about it: a temperature sensor or a proximity beacon. These devices follow predictable patterns: sleep, wake, sense, transmit, sleep. They’re perfect candidates for bare metal development.
The nRF Connect SDK Bare Metal is specifically designed for these simple Bluetooth LE applications. It brings the popular SoftDevice from the nRF5 SDK to the modern nRF Connect SDK, providing a familiar API for developers migrating from nRF52 Series to nRF54L Series. If you’ve worked with SoftDevice before, you’ll feel right at home. The architecture and API similarity eases migration of existing codebases while providing access to the latest nRF54L Series hardware capabilities and tooling available in the nRF Connect SDK.
The advantages of bare metal for Bluetooth LE applications go beyond just philosophical alignment. When you remove the RTOS layer, you eliminate kernel overhead, thread stacks, and scheduling delays. Memory that would have been consumed by OS structures becomes available for your application. You have direct control over power modes, allowing you to avoid running the CPU and clocks when they are not needed. Interrupt response times become more predictable because there’s no scheduler deciding whether your interrupt handler should run now or after the current thread’s time slice expires.
The nRF Connect SDK Architecture
To truly appreciate what makes the Bare Metal option special, we need to understand how the nRF Connect SDK is structured.
nRF Connect SDK with Zephyr
The nRF Connect SDK is built on top of the popular Zephyr Project, which brings not only an RTOS but also extensive functionality, a build system, and tooling infrastructure.. When you build an application with the SDK, you’re getting a full technology stack with multiple layers: your application code at the top, nRF Connect SDK libraries (Bluetooth, crypto, sensors, etc.) in the middle, the Zephyr RTOS (kernel, drivers, services) providing the foundation, and finally the hardware layer (nRF SoCs) at the bottom.
This layered approach brings tremendous power to your fingertips. The Zephyr kernel provides preemptive multithreading, allowing you to structure your application as multiple independent tasks that appear to run simultaneously. Device drivers offer a unified API for hardware peripherals, meaning your GPIO code can work across different Nordic chips with minimal changes. The network stacks support not just Bluetooth, but also Thread, Zigbee, and other protocols. You even get file system support if you need to store configuration data or logs.
All of this functionality is fantastic when you need it. But here’s the thing—what if you don’t? What if your application is a simple temperature sensor that wakes up every minute, takes a reading, and goes back to sleep? In that case, you’re carrying around a lot of baggage you’ll never use, and that baggage costs you in terms of RAM, NVM, and power consumption. It is worth mentioning that Zephyr is quite configurable, and many unnecessary features can be disabled, but it does come with a bit of a learning curve.
nRF Connect SDK Bare Metal
This is where the Bare Metal option comes in. I imagine Nordic’s engineers asked themselves something like: what if we could keep all the good parts of the modern nRF Connect SDK—the build system, the tooling, the hardware abstraction layer, the battle-tested Bluetooth stack—while stripping away the complexity of the RTOS? The result is a streamlined architecture with your application code on top, bare metal libraries (SoftDevice, HAL, services) providing essential functionality, a minimal runtime layer (no kernel, purely event-driven), and the hardware at the base.
The nRF Connect SDK Bare Metal option diverges the most from Zephyr-based development by offering a single-threaded, event-driven system, as opposed to the multi-threaded nature of Zephyr RTOS. But unlike starting from scratch with raw register programming, you still have access to Nordic’s excellent hardware abstraction layer and, crucially, the SoftDevice Bluetooth stack.
The SoftDevice deserves special mention here. It’s Nordic’s proprietary Bluetooth stack that has been refined over many years and millions of deployed devices. By using the SoftDevice in bare metal mode, you get all the benefits of a proven, certified Bluetooth implementation without the overhead of an RTOS. The SoftDevice handles all the complex timing requirements of the Bluetooth protocol, leaving your application code to focus on business logic.
In nRF Connect SDK Zephyr-based development, the SoftDevice controller (the lower part of the stack) is coupled with the Zephyr Bluetooth host (the upper part of the stack), which is tightly integrated with Zephyr RTOS functionality. However, with the Bare Metal option, Nordic offers the SoftDevice as a full stack, to decouple from having to use Zephyr, and keeps the same host and API that was available for SoftDevice in their previous nRF5 SDK
Coexistence: One SDK, Two Approaches
One of the most innovative aspects of nRF Connect SDK is that Bare Metal and Zephyr RTOS development coexist within the same SDK and development environment. This isn’t just a technical achievement—it’s a strategic advantage for your development process.
The Unified Environment
Both Bare Metal and Zephyr RTOS applications use the same nRF Connect for VS Code extension, the same toolchain, and the same SDK infrastructure. This means:
- Shared Learning Curve: Learn the tools once, use them for both approaches
- Easy Experimentation: If you’re new to RTOS, you can develop your main project in bare metal, while experimenting with Zephyr samples for later adoption
- Common Tools: Many tools work with both approaches, including those outside the SDK, such as nRF Connect for Desktop
- Unified Documentation: Documentation for both approaches in nRF Connect SDK is available in Nordic’s unified TechDocs documentation portal
The Upgrade Path
This coexistence enables a powerful development strategy. Start with Bare Metal for your MVP or proof of concept. Get to market quickly without wrestling with RTOS concepts. As your new designs evolve and requirements grow, you have a clear path to adopt Zephyr-based development and access all the SDK features and capabilities:
- Phase 1: Bare Metal MVP – Simple Bluetooth LE peripheral, fast time to market
- Phase 2: Feature Addition – Still in bare metal and reusing nRF5 SDK-based code
- Phase 3: Complexity Threshold – Requirements on new designs exceed bare metal’s sweet spot
- Phase 4: RTOS Migration – Smooth transition to adopting Zephyr-based development for advanced features
The beauty is that you’re not relearning everything—the development environment, workflow, build system, and many APIs remain consistent. Your team’s investment in learning the nRF Connect SDK pays dividends regardless of which approach you choose.
Additionally, Nordic offers comprehensive support to ease the Zephyr learning curve through their Developer Academy, which includes the nRF Connect SDK and Bluetooth LE-specific courses with a hands-on approach.
Technical Differences
Now, let’s examine what really changes when you decide to go down the bare metal or the Zephyr route for developing your application. The differences go far deeper than just removing a few kilobytes of kernel code.
Memory Management
Memory is often the scarcest resource in embedded systems, and how you manage it can make or break your project. In Zephyr-based development, memory management follows a familiar pattern if you’ve worked with any RTOS. The kernel maintains its own data structures for managing threads, semaphores, mutexes, and other synchronization primitives. Each thread gets its own stack, sized according to its needs. Multiple kilobytes per thread is common, and various system threads consume their own allocations.
The bare metal approach takes a radically different view. There’s only one stack because there’s only one thread of execution. The kernel data structures? Gone. Thread stacks? Not needed. The result is dramatic: that same “hello world” Bluetooth LE peripheral that required substantial memory in the standard SDK runs with significantly less RAM in bare metal.
As your designs get more sophisticated and the benefits of adopting Zephyr become stronger, the small resource overhead is more diluted and less significant. This is because your firmware’s overall needs are likely to grow as you add features, and since the Zephyr overhead is largely static, it has less relative impact on your overall resource usage.
Additionally, the RTOS functionality will help optimize your application’s resource usage, which will also help balance the scale.
Execution Model
The execution model is where the philosophical differences between RTOS and bare metal become most apparent. In Zephyr-based development, you think in terms of tasks and threads. Your application might have a main thread handling user interface, a sensor thread periodically reading data, and a Bluetooth thread managing connections. Each thread has its own priority, its own stack, and its own illusion of running independently.
The bare metal approach throws all of this out the window in favor of a simpler model: one thread, one loop, handle events as they come. Your entire application becomes a state machine that responds to stimuli, such as events from the SoftDevice or interrupts from nRF54L hardware peripherals.
In the bare metal model, your main function initializes the system and then enters an infinite loop. This loop processes any pending log messages, checks for events (like sensor data being ready or Bluetooth LE events pending), handles them accordingly, and then puts the processor to sleep until the next event. It’s a straightforward event-driven pattern: check flags, handle events, clear flags, sleep, repeat.
At first glance, this might seem primitive—and in a way, it is. But this simplicity brings powerful benefits. There’s no context switching overhead because there’s only one context. There are no priority inversions because there are no priorities. There’s no risk of deadlock because there are no locks. The flow of execution is completely predictable: events happen, you handle them, you go to sleep.
Real-World Use Cases and Examples
Ideal Bare Metal Use Cases: Simple Bluetooth LE Applications
The nRF Connect SDK Bare Metal is specifically designed for simple Bluetooth LE applications that don’t require RTOS features. Let me paint you a picture of where this approach truly excels.
Imagine you’re designing a simple Bluetooth LE temperature sensor for the nRF54L Series. This sensor needs to periodically wake up, read temperature, and advertise the data. That’s it. No complex state management, no concurrent operations, just a straightforward sense-and-send pattern. This is exactly the type of simple Bluetooth LE application where Bare Metal shines—and where an RTOS would be overkill.
Or consider a Bluetooth LE beacon for retail proximity marketing. It broadcasts a UUID at regular intervals to trigger mobile apps when customers walk by. This simple Bluetooth LE application doesn’t need thread scheduling, memory management, or any RTOS features. With Bare Metal, you can implement this in minimal code that runs efficiently on nRF54L Series hardware.
Industrial sensors often choose Bare Metal for simple Bluetooth LE applications because simplicity increases predictability. A vibration sensor that just needs to detect thresholds and send Bluetooth LE alerts doesn’t need an RTOS. It needs straightforward, predictable code that’s easy to validate and certify.
When to Choose nRF Connect SDK Zephyr-based Development
Now let’s flip the script and talk about when you absolutely need the full power of the nRF Connect SDK. Consider an IoT gateway that bridges between Bluetooth LE devices and the cloud. This device might be managing connections to dozens of Bluetooth LE sensors while simultaneously maintaining a cellular or Wi-Fi connection to the internet. It needs to buffer data when the network is down, manage a local web server for configuration, and handle firmware updates for both itself and the connected sensors.
This is where an RTOS shines. You’ve got genuinely concurrent activities that need different priorities and resources. The thread handling cellular communications can’t block the thread processing Bluetooth LE events. The web server needs to respond to requests while data logging continues in the background. Trying to implement this in a single event loop would be like juggling chainsaws—theoretically possible but practically inadvisable.
Migration Strategies: Bringing Your nRF5 SDK Experience Forward
The nRF Connect SDK Bare Metal was designed with a clear mission: ease the migration of existing codebases from nRF52 Series to nRF54L Series by maintaining architecture and API similarity to nRF5 SDK. If you’ve invested years in nRF5 SDK development, this is your bridge to modern hardware.
The SoftDevice Advantage
The key to smooth migration is the SoftDevice. By bringing this popular and proven protocol stack to nRF Connect SDK, Nordic has preserved the programming model that millions of devices rely on. Your existing SoftDevice knowledge transfers directly:
- Same Event Model: Bluetooth LE events are dispatched and handled the same way
- Familiar APIs: Most SoftDevice calls map directly or with minimal changes
- Proven Reliability: The same battle-tested stack you’ve been shipping for years
- Consistent Behavior: Timing, power management, and radio scheduling work as expected
This isn’t just about code compatibility—it’s about preserving your team’s expertise. The engineers who’ve spent years mastering SoftDevice quirks and optimizations can apply that knowledge immediately on nRF54L Series hardware.
Migration Path from nRF52 to nRF54L
For those maintaining products on nRF52 Series, the migration path is remarkably smooth. The biggest change will be the build system. Gone are the days of Makefiles and sdk_config.h. In their place, you’ll find CMake and West (Zephyr’s meta-tool for managing repositories) along with Kconfig for configuration and Devicetree for hardware description.
First, get comfortable with the new build system. Don’t try to port your entire application on day one. Instead, create a simple “hello world” Bluetooth LE peripheral using the bare metal SDK samples. Get it building, get it running on your development board, and get familiar with the workflow.
The SoftDevice migration is very smooth. Nordic has maintained API compatibility where it makes sense, so your Bluetooth LE event handlers will need only minor tweaks. The biggest changes are in the initialization sequence and some of the configuration structures, but your core application logic can remain largely intact.
Migrating from sdk_config.h to Kconfig
One of the adjustments for nRF5 SDK developers is moving from the monolithic sdk_config.h file to Kconfig. The good news is that many familiar settings retain similar names—your NRF_SDH_BLE_PERIPHERAL_LINK_COUNT becomes CONFIG_NRF_SDH_BLE_PERIPHERAL_LINK_COUNT, just with the CONFIG_ prefix that Kconfig requires.
The key improvements with Kconfig:
- Hierarchical organization instead of one flat file with thousands of defines
- Automatic dependency management – enable Bluetooth, and required subsystems are automatically enabled
- Clean prj.conf files with just your application-specific settings (dozens of lines instead of thousands)
- Hardware/software separation – pin assignments go in devicetree, software config in Kconfig
For example, where you had dozens of UART defines in sdk_config.h, you now have CONFIG_SERIAL=y in prj.conf and pin assignments in devicetree—a much cleaner separation of concerns.
Single-Bank DFU: More Space for Your Application
One of the most compelling advantages of nRF Connect SDK Bare Metal is its introduction of a single-bank Device Firmware Update (DFU) solution. This might sound like a technical detail, but it has profound implications for your product design.
In traditional DFU schemes, you need two complete copies of your application in flash: one running, one being updated. This means that if your application is 200KB, you need 400KB of flash just for the application, plus space for the bootloader. On devices with limited flash, this can be a deal-breaker.
The Bare Metal SDK introduces a single-bank DFU solution that dramatically reduces flash requirements:
- More NVM for Application: Instead of reserving 50% of flash for DFU, you can use that space for your application
- Smaller Chip Selection: You might be able to use a lower-cost nRF54L variant with less flash
- Room for Features: That saved flash can store configuration data, logs, or additional functionality
- Cost Optimization: Less flash requirement can mean significant cost savings at scale
This single-bank DFU approach is particularly valuable for simple Bluetooth LE applications that don’t need the complexity of dual-bank updates. And here’s the exciting part: this technology will later be expanded to Zephyr RTOS application development, benefiting the entire nRF Connect SDK ecosystem.
RTOS-Agnostic Design: Freedom to Choose
One of the most forward-thinking aspects of nRF Connect SDK Bare Metal is that its key software assets are RTOS-agnostic. This isn’t just a technical detail—it’s a fundamental design philosophy that gives you unprecedented flexibility.
The Bare Metal key software assets are RTOS-agnostic, enabling their use with a third-party RTOS outside of the nRF Connect SDK. This flexibility allows you to integrate Nordic’s optimized Bluetooth LE stack and drivers with your preferred RTOS and development environment.
This flexibility is particularly valuable for companies with existing RTOS investments or specific certification requirements. You’re not forced to adopt Zephyr just to use Nordic’s latest hardware—you can keep the infrastructure and development environment of your own RTOS, and bring the Nordic optimized SoftDevice Bluetooth LE stack and nrfx drivers to leverage the increased performance and low-power of nRF54L Series.
Conclusion: The Right Tool for Simple Bluetooth LE Applications
After exploring the intricacies of bare metal versus RTOS development, the value proposition is clear: nRF Connect SDK Bare Metal is the ideal development solution for simple Bluetooth LE applications on nRF54L Series that don’t require Zephyr RTOS.
This isn’t about choosing sides in an RTOS versus bare metal debate. It’s about recognizing that many Bluetooth LE applications—especially those that only require peripheral functionality—are fundamentally simple. They don’t need thread scheduling, complex memory management, or sophisticated synchronization primitives. They need to sense, process, and communicate via Bluetooth LE efficiently and reliably.
For developers not familiar with RTOS concepts, the Bare Metal option offers a quicker entry point to the nRF Connect SDK. You can get your simple Bluetooth LE application running on the nRF54L Series without learning about threads, semaphores, or priority scheduling. This faster time-to-market can be the difference between capturing an opportunity and missing it.
For teams migrating from the nRF52 Series, the architecture and API similarity to the nRF5 SDK make the transition smooth. Your SoftDevice expertise transfers directly, your existing codebase ports with minimal changes, and you gain access to the latest nRF54L Series capabilities.
What makes Nordic’s approach particularly compelling is the coexistence of Bare Metal and Zephyr RTOS within the same SDK and development environment. You’re not locked into a decision:
- Start Simple: Begin with Bare Metal for your MVP or proof of concept
- Grow Naturally: Add features while staying in the familiar bare metal environment
- Upgrade When Needed: Transition to Zephyr RTOS when complexity demands it
- Or Stay Flexible: Use the RTOS-agnostic components with your preferred third-party RTOS
The introduction of single-bank DFU further sweetens the deal, leaving more NVM space for your application—a game-changer for cost-optimized products.
In the end, nRF Connect SDK Bare Metal option represents Nordic’s commitment to meeting developers where they are. Whether you’re building your first Bluetooth LE device or migrating a mature product line to nRF54L Series, Bare Metal provides a pragmatic path forward for simple Bluetooth LE applications. It’s not about abandoning modern development practices—it’s about choosing the right approach for your specific needs.
Important Resources
Additional Resources
Your journey with nRF Connect SDK Bare Metal doesn’t end here. The Nordic ecosystem is rich with resources to help you succeed:
- The Nordic Developer Academy offers the perfect place to get started with the nRF Connect SDK and the Zephr-based development solution.
- The official nRF Connect SDK Documentation should be your next stop. It’s comprehensive, well-maintained, and includes both conceptual guides and API references. Don’t skip the getting-started guides—even experienced developers will find nuggets of wisdom there.
- The Nordic DevZone community forum is where the magic happens. Nordic’s engineers actively participate, and the community is generally helpful and knowledgeable. Before posting a question, search the archives—chances are someone has faced your exact issue before.
- Don’t overlook the example projects in the SDK’s
samples/directory. Start with these examples and modify them to suit your needs, rather than starting from scratch.
Happy coding, and may your nRF54L-based devices run for years on a single battery!🔋
