A thermocouple is mounted on the rig. The board is powered, the sensor is wired, and the measurement you actually care about is one working program away. Then you open the toolchain and remember what that means. Register maps. A linker script. An interrupt vector table. A main loop you have to write from nothing before a single number appears anywhere you can look at it.
That gap between having hardware and having data is where most embedded projects lose their first weeks. Bare metal is not the problem. Bare metal without an application layer is the problem.
What bare metal asks of you before you measure anything
Running on bare metal means your code talks to the silicon directly, with no operating system sitting in between. It is a legitimate and often excellent approach. It is also unforgiving about the order of operations.
Before your first reading is logged, a bare metal project typically requires you to configure clocks, initialise peripherals, manage memory addresses by hand, and handle timing yourself. Practical guides to bare metal programming spend a lot of their early chapters on pointers and memory precisely because that is the layer you are working at. You are not writing about your experiment. You are writing about the machine that will eventually let you write about your experiment.
The classic demonstration in vendor documentation is a program that prints Hello World over UART. That is the right size of example for teaching, and the wrong size of example for the work you have in front of you. The distance between blinking a message out of a serial port and running a multi-channel acquisition job with logging, timestamps and a live view is where schedules quietly disappear.
The dependency trap that catches bare metal teams
Bare metal gets harder when you step outside the microcontroller you know. Vendor software development kits for connectivity are a common example. Many WiFi SDKs from large silicon vendors, including Realtek, TI and MediaTek, are built to run on an operating system rather than directly on the hardware. That constraint is documented well enough that one long-time bare metal developer wrote publicly in June 2020 about why he moved to operating systems instead.
The pattern repeats across peripherals, stacks and file systems. You pick a component, then discover it assumes a scheduler, a heap and a networking stack you were planning to write yourself. Each dependency is small. Together they determine your architecture.
What an application layer actually is
An application layer is everything that sits between your intent and the silicon. A runtime that loads and runs your program. A language environment. Scheduling. Communications between boards. A way to see data while the experiment is still running.
The important word is supplied. A framework you assemble from libraries and forum posts is not an application layer, it is a second engineering project. An application layer arrives with the hardware, so the first thing you build is your measurement rather than the platform that will carry it.
That shift is the whole argument. The value is not that low-level control disappears. It is that low-level control stops being your default task.
What the EDDIE application layer puts above the metal
EDDIE boards are industrial-grade, modular DAQ and embedded systems built for scientists and engineers, with Australian-based support. The design decision behind them is that the application layer ships with the board rather than being left as an exercise.
An operating system and language environment, already there
EDDIE comes with its own native operating system and language environment. There is no boilerplate ritual to complete before your program does something useful. You are working in a defined environment with defined behaviour, which means the mental model you build on day one still applies on day fifty.
Write and test on the device, live
Programs are written, interacted with and tested directly on the hardware, in real time. The familiar compile-and-flash loop is gone, which changes how fast you learn what your system is doing. Debugging becomes a conversation with the instrument instead of a cycle of waiting and guessing.
Multitasking without architecting an RTOS
Native multitasking lets multiple processes run concurrently out of the box. You do not have to design a real-time operating system from scratch, or reason about the failure modes of one you built yourself. Acquisition, logging and a live interface can each be their own process rather than sections of one tangled main loop.
Board-to-board telemetry that already works
Built-in telemetry infrastructure lets multiple EDDIE boards synchronise, communicate and work together. Channels can be distributed across hardware without anyone writing custom networking scripts. Scaling a rig outward stops being an integration project and becomes a wiring decision.
A desktop IDE and dashboard
A companion desktop environment handles visualisation, management and analysis of your data. Measurements are visible while they are happening, not only after a session ends. That matters when you need to know whether a setup is behaving before you commit an afternoon to it, or an overnight run.
Bare metal versus a supplied application layer
Aspect | Bare metal, no application layer | EDDIE with a supplied application layer |
|---|---|---|
First working measurement | After toolchain, peripheral and memory setup | After writing the program that performs it |
Testing cycle | Compile, flash, observe, repeat | Write and test directly on the device |
Concurrency | Built by hand, often as a single main loop | Native multitasking out of the box |
Multiple boards | Custom networking code | Built-in telemetry infrastructure |
Seeing your data | Whatever you build to display it | Desktop IDE and dashboard included |
New team member onboarding | Depends on who wrote the low-level code | Same environment for everyone |
The costs you stop paying
The most visible saving is time to first data. The larger saving is the one that shows up in staffing.
Bare metal codebases carry a lot of institutional knowledge in one or two heads. When those people move on, the replacement inherits register-level decisions with no context, and the project slows while someone reconstructs intent from comments and commit history. Staff turnover on a bare metal platform is expensive in a way that rarely appears on a project plan.
A supplied application layer makes work legible to the next person. The environment is the same, the language is the same, and the hardware behaves the same way. That is what being re-invention ready looks like in practice. You can start a new rig, hand it to a different engineer, or rebuild an experiment from last year without a weeks-long archaeological dig first.
Where bare metal is still the right call
Bare metal has not become obsolete, and a fair comparison should say so. It remains a strong choice where hardware resources are genuinely constrained, where a device performs one fixed function that will never change, where a specific timing behaviour must be guaranteed and verified at the instruction level, or where volumes are high enough that per-unit cost dominates every other consideration.
The honest question is not whether bare metal is capable. It is whether your project is the kind that benefits from you writing the platform layer, or the kind that benefits from someone having already written it and tested it on your behalf.
What to ask before you commit to an approach
How long until the first real measurement, not the first Hello World over UART?
Which vendor SDKs and stacks does the design depend on, and do they expect an operating system?
Who maintains the low-level code, and what happens when they leave?
How will multiple boards synchronise, and who writes that code?
Can measurements be inspected live, or only after a run finishes?
How much of the schedule is measurement work, and how much is plumbing?
Answer those six honestly and the architecture tends to choose itself. If most of your answers point at plumbing, an application layer that arrives with the hardware is not a shortcut. It is the correct starting point, because it lets a capable engineer spend their time on the problem they were actually hired to solve.
Frequently Asked Questions
What does bare metal mean in embedded development?
Bare metal means your program runs directly on the processor with no operating system between your code and the hardware. You control memory, peripherals and timing yourself. It offers complete control and predictable behaviour, and it also means every service your application needs, from scheduling to communications to display, is something you build or integrate before your actual work begins.
Is an RTOS the same thing as an application layer?
No. A real-time operating system is one component that an application layer might include, typically handling scheduling and task priorities. An application layer is broader. It covers the language environment, the development and testing workflow, communications between boards, and the tooling you use to see your data. An RTOS alone still leaves plenty of integration work in front of you.
Can I still access low-level hardware with an application layer?
An application layer changes your default, not your ceiling. The platform handles the routine plumbing so you are not rewriting it for every project, while direct hardware interaction remains available when a specific measurement demands it. You keep the option of going low-level for the cases that genuinely require it, without making that the starting point for everything.
Does an application layer slow down measurements?
The relevant question is where the time goes. Time spent writing peripheral setup and networking code is time not spent measuring, and that cost lands on every project regardless of how fast the hardware runs. A supplied layer removes that overhead once. What remains is the acquisition work itself, running on hardware designed for it.
How do I know if my team needs an application layer?
Look at where your engineering hours actually land. If a significant share goes to toolchain setup, debugging cycles, concurrency design and board-to-board communications rather than the science, the platform is competing with your project for attention. Teams with turnover, expanding rigs or repeated new builds tend to feel this most sharply.
