Latest / Hardware Startups with Fexingo: Devices, Robotics, and Manufacturing Tech Companies / How Hardware Startups Use Bare-Metal Programming for Speed
Transcript
- Lucas: So today I want to talk about something that feels almost old school in the hardware world, but it's making a real comeback among early-stage startups. Luna: What's that — going back to assembly language? Lucas: Close, but not quite. It's bare-metal programming. Writing firmware that runs directly on the microcontroller, with no operating system underneath. No FreeRTOS, no Linux, nothing. Luna: Okay, that does sound retro. But I assume there's a reason startups are doing it in 2026? Lucas: Right. The big reason is speed. Not just execution speed, but boot speed. And when you're designing a battery-powered sensor that needs to wake up, take a reading, transmit, and go back to sleep in under a hundred milliseconds, every microsecond counts. Luna: So you're talking about the kind of device where you can't afford the overhead of an OS waking up? Lucas: Exactly. I was talking to a startup last month that's building a soil moisture sensor for precision agriculture. They needed a battery life of ten years on a single CR2032 coin cell. Their target was a fifty-millisecond wake to transmit cycle. With FreeRTOS, they were seeing about a hundred and twenty milliseconds just to get the scheduler running and initialize the drivers. Luna: Ouch. That's more than double their budget. Lucas: Yeah. They went bare metal, stripped out everything unnecessary, and got their boot time down to twelve milliseconds. Suddenly the ten-year battery target was achievable. Luna: What about cost? I imagine running bare metal lets you use a cheaper microcontroller? Lucas: That's the second big advantage. When you don't need to run an OS, you can use a much smaller, cheaper MCU. Think an eight-bit microcontroller with two kilobytes of RAM instead of a thirty-two-bit ARM Cortex with sixty-four kilobytes. That difference can be fifty cents to a dollar per unit. On a run of fifty thousand units, that's real money. Luna: Fifty cents might not sound like much, but for a startup on a tight BOM, that's huge. Lucas: Exactly. And it's not just the chip cost. A simpler MCU means a simpler PCB layout, fewer decoupling capacitors, sometimes even a two-layer board instead of four. The savings cascade. Luna: Alright, but what are you giving up? No multitasking, no USB stack, no file system — you have to write all that from scratch? Lucas: That's the trade-off. You don't get any of the nice abstractions. If you need USB, you're writing the entire USB device stack. If you need over-the-air updates, you're writing a bootloader that can erase and reprogram flash. It's more work upfront, and it requires deeper firmware expertise. Luna: So when does it make sense? Only for super simple devices? Lucas: Not necessarily. It's actually very common in medical devices. If you're building a continuous glucose monitor or an insulin pump, you need deterministic timing. You can't have the OS decide to do a garbage collection cycle right when you need to read a sensor. Bare metal guarantees you're in control of every clock cycle. Luna: And that's a big deal for certification too, right? The FDA wants to see that your firmware is predictable. Lucas: Absolutely. Certifying a device running an RTOS means you have to validate the entire OS as part of your safety case. With bare metal, the code you're validating is just what you wrote. It's a smaller surface area. Luna: That's a strong argument. I can see why a startup building a Class II medical device would go that route. Lucas: And it's not just medical. Think about any industrial IoT sensor that's monitoring vibration on a factory machine. If the sensor misses a reading because the OS was busy, you might miss the early warning sign of a bearing failure. Bare metal lets you set hard real-time deadlines. Luna: So the use case is really anything where timing is critical and power is limited. Lucas: Right. But there's a third reason that I think is underappreciated: it forces you to understand your hardware deeply. When you write bare metal, you have to read the microcontroller's datasheet, configure registers directly, understand clock trees and interrupt priorities. That knowledge makes you a better engineer, and it means when you do eventually move to an RTOS, you know exactly what it's doing under the hood. Luna: Okay, but what about the developer experience? No debugger, no printf over USB — how do you even debug this stuff? Lucas: You use a JTAG debugger and a logic analyzer. It's more hands-on. But honestly, for a small team, that can be a feature, not a bug. You're not fighting with OS configuration issues. The code either works or it doesn't. Luna: And if today was actually useful to you, the way these stay ad-free is listener support — buy me a coffee dot com slash fexingo. Lucas: Yeah, it's a small thing that makes a big difference. Keeps us independent and focused on what matters for builders. Luna: Alright, back to the metal. So let's say a startup decides to go bare metal for their first product. How do they know when it's time to switch to an RTOS? Lucas: Good question. Usually the tipping point is when their feature list outgrows the bare metal approach. Maybe they need to add Bluetooth LE, which has a complex stack. Or they need to support multiple sensor types with different timing requirements. At that point, the effort to write everything from scratch exceeds the effort of integrating an RTOS. Luna: So it's a scaling decision. Start bare metal, prove the product works, then migrate. Lucas: Exactly. And the great thing is, if you wrote clean bare metal code, the migration isn't that painful. You can keep your peripheral drivers and just add an OS layer on top. I've seen startups do that in a matter of weeks. Luna: Any gotchas to watch out for? Lucas: One big one: interrupt latency. When you go bare metal, you have to manage interrupt priorities yourself. If you get it wrong, you can have a low-priority interrupt that never gets serviced. That's a hard bug to find. Luna: Yeah, that sounds like a nightmare to debug. Any tools that help? Lucas: Logic analyzers are your best friend. Trigger on the interrupt line and watch the timing. Also, some modern MCUs have built-in event tracing that can show you interrupt nesting and latency. Use it. Luna: Alright, so for a founder listening who's building their first hardware product, what's the takeaway? Lucas: Don't default to an RTOS just because it's what you know. Ask yourself: how fast do I need to boot? How low does my power need to be? How much can I spend on the MCU? If the answers push you toward a tiny, cheap chip, bare metal is probably the right call. Luna: And if you're not sure? Lucas: Start with bare metal on a development board. Write a simple blink and read sensor loop. See how long it takes. If you can hit your timing targets with room to spare, you might not need an OS at all. Luna: That's surprisingly pragmatic. I think a lot of teams over-engineer their firmware stack. Lucas: They do. And the irony is, the most successful hardware startups I've seen are the ones that ship first and optimize later. Bare metal helps you ship fast. Luna: Great episode. I'm actually rethinking my own approach to a side project now. Lucas: Glad to hear it. That's what we're here for.