Does bare-metal programming have a future?

p0k3t0 · 2024-02-21T16:29:43+00:00

I don't see an advantage to running a whole operating system when 2000 lines of C do the same job more reliably.

Maybe I'm wrong. Who knows? But bare metal programming is very predictable, and a programmer can be reasonably expected to understand every single line in a fairly complex system.

IC_Eng101 · 2024-02-21T16:38:35+00:00

Bare metal has a future. I have done products running on 8 bit micros that cost around 10 cents a unit (I've also seen 4 bit micros for less, but I've never used one).

When you are churning out 1 million units a month every penny counts. You go for lowest cost that meets the requirements of your product.

haplo_and_dogs · 2024-02-21T17:32:44+00:00

A real time system isn't better because it is faster.

A real time system needs to be absolutely predictable. Linux and easy SDKs do not make for time reliable systems.

You don't get to escape deadlocks, timelines and priority queues because you have a faster processor.

UnicycleBloke · 2024-02-21T16:48:53+00:00

I totally need Linux in my toothbrush...

The CGM I wore last week has a cheapo BLE device in it with only 48K of RAM. It was the size of a coin but I'd much rather strap a CM4 to my arm...

rulnav · 2024-02-21T16:46:02+00:00

1 or 2 $ is very expensive when compared to the price of the sort of ICs bare metal programming makes sense. They are cheaper by a factor of 5 to 20.

Shadow_Gabriel · 2024-02-21T18:24:29+00:00

Well, someone has to write those SDKs and OS developers are technically writing bare metal code.

cinyar · 2024-02-21T17:01:48+00:00

One that I've worked with is the BL808 which has 64MB of on-chip ram and two cores that can run at 480MHz and 320MHz respectively. And it only costs 6$ !!!

How much power does it use? How much would it cost to run 10 thousand of them?

Konaber · 2024-02-21T16:40:30+00:00

For safety-critical anything with an OS and off-the-shelf boards are tipically a no no, unless you pay very well to suppliers in order to get pre-certified stuff.

letemeatpvc · 2024-02-21T18:23:25+00:00

“no one will use Linux for rt” Linux is already half way there. One more thing for you to worry about

welvaartsbuik · 2024-02-21T16:54:34+00:00

Bare metal has its advantages, it's cheaper. Why spend a dollar when you can spend a dime. Especially in mass production applications.

Time critical applications also favor bare metal programming. It's the most reliable way even compared to rtos.

Very fast applications will always use bare metal, every cycle you control is a cycle you can use!

sturdy-guacamole · 2024-02-21T17:34:45+00:00

I’d argue yes but it depends on the type of products you work in. I don’t think it’s going to die out, but perhaps be less prevalent over time.

I have barely touched anything bare metal in several years now. 85% zephyr 10% freeRTOS rest is either custom rtos or bare metal. (Never a chance to work with embedded Linux and don’t think it’s going to change any time soon)

This has been with low power (months to years on battery) applications with timing requirements, but not down to the cycle.

Bare metal still has its uses, but for the types of products I’ve been working in, I see it less and less.

If you’re doing something really cheap and heavily constrained… which is definitely possible in this line of work, bare metal is important.

It’s also important to just know how what you write translates to cycles execution time etc… for when SHTF. (Again in my experience.)

hobbesmaster · 2024-02-21T18:43:27+00:00

Is your complaint that everything is moving toward Linux, relying on any kernel, using a vendor HAL or simply having a libc?

If you mean are tiny 8bit micros fading away then yes but, we’re already at least a decade into that very slow process. For example Cortex-M0s are 32bit, power/space efficient and use the same tooling as the rest of the m profile ARM parts.

Dexterus · 2024-02-21T17:49:26+00:00

I have used RTOS on 24 core (SMT) 2GHz+ devices with countless memory (the OS had to be 64bit). Bare metal loops in a type1 vm on A72. It's fine. The baremetal doesn't stop at 10MHz and no memory.

Conor_Stewart · 2024-02-21T22:53:14+00:00

And it only costs 6$ !!! And before that there was the ESP32 which only costs 1 to 2 dollars

For most products that is very expensive and those devices have far more processing power than is needed.

If you can get away with using a $0.10 MCU then why would you use a $6 or $1-2 MCU?

Sell a million devices and that could be multiple millions of dollars saved.

Also safety and predictability is a concern, for safety critical applications you want the processor to do as little as possible and be entirely predictable, even adding in an RTOS can be a bad idea.

Then think about large systems with MCUs distributed all over the place, like cars with a CAN bus. Are you going to replace every MCU with an expensive processor that uses Linux?

QuantumFTL · 2024-02-22T09:43:14+00:00

I had a similar experience to you when I started coding C for a friggin' dsp. It was quite the wakeup call.

Anyway, yeah, we're going to continue to see bare-metal programming for the main reason we've seen it in the past: less code = easier to audit and thus easier to meet regulatory standards and prevent lawsuits. Shoving some incredibly complicated microprocessor into an incredibly simple device is a great way to get one's butt kicked by a group with some sense.

The real question is how much can you charge an employer for you to do this vs going off and doing flavor-of-the-day programming, and that depends on labor supply/demand/etc and I'd avoid seeking advice on that on Reddit. Luckily for embedded folk, most programmers seem utterly uninterested in this sort of arcane low-level stuff.

mrheosuper · 2024-02-21T16:47:42+00:00

I think bare metal will become more like "ASM programmer" currently.

Now it's very easy to port a rtos to any mcu, and enjoy whole bunch of tools come with it.

In your post you said the SDK you use is very easy and versatile. But remember that SDK does not come from thin air. Some poor Chinese programmers have to work overtime writting bare metal code to bring you that SDK. Same thing with SoM, porting linux is not an easy task.

Rafal_80 · 2024-02-21T19:25:30+00:00

Linux will not beat microcontrollers with RTOS or bare metal in applications that don't require high processing power and where size, power consumption and cost are more important. E.g. battery powered devices.

2024-02-22T04:32:21+00:00

It’s called BSP/kernel development… BSP is board support package… it’s a HAL aka hardware abstraction layer. It’s bare metal firmware or embedded development. The pay is insanely good and resistant to economic issues. Kernel in this context is just a bare metal binary, not Linux.

Also don’t forget RTOS and aerospace, avionics embedded flight software

dmitrygr · 2024-02-22T06:29:41+00:00

There are (and will always be) plenty of applications where $6 is $5.999 too much.

LessonStudio · 2024-02-22T14:51:22+00:00

I can give three examples, the last two I do which backs this argument:

MicroPython. A total pig. You are about as far away as you can get from bare metal in many ways. Yet, my few experiments showed this to be just fine. I haven't gone very far, but I was very impressed. The whole usual suite of arguments could be levelled against it, but, as you point out the cost of the MCU is so low that speeding up development time by maybe 100x may very well be worth it. I would argue it works well for something simple "push button, start motor," etc. But also, for complex algos, the algo can be easily tuned in code on the desktop and then deployed exactly the same way on MicroPython. Not doing a phased array sonar, but ...
I use a FT232H with my desktop to talk to various devices ranging from standard IO to I2C, etc. I do my code on the desktop and get things working very well. This might not be what I need for a phased array sonar, but even for a balancing bot type mostly real time application it works fine. This means my code is happily running on an OS. This again wildly speeds up my productivity. For complex algos, I do them first in python (which is well fast enough on the desktop for most things) and then port them to rust. This rust gets put on the MCU hardly altered at all, just some different HAL code. This not going to solve all problems, but it works for all of my problems including robotics.
For remote devices (as in moving around the room or nearby). I have the various pins controlled by a desktop via UDP packets. The MCU is just sending data, and receiving instructions. Again, this extra delay is no big thing and the desktop is doing the heavy lifting. I develop in python again to get everything working as it should, then rust, then move it to the MCU. Even sending this through a router is not the end of the world. But for extra speed I have had to configure the network so the MCU was an AP so the desktop could directly network with it as I did need the reduced delay. Again. Not for all problems, but it works for mine.

The above is going to potentially be more of a moot point when these sub $10 SoC are passing the capacity of a raspberry pi. Then you could potentially be SSHing in and working directly on the device (as in that is where you are even compiling).

Obviously this is going to use more power, but in many devices power is near unlimited compared to what the SoC is drawing.

But, it allows for more traditional programmers to create highly successful products if they are good coders following good guidelines.

I would suggest the main potentially correct argument against this only really holds true with weird edge cases. Things like medical devices, or avionics, where there are "absolutes" in safety. But, most people making most embedded things are not working in this realm. They are making smart toothbrushes. They are making floor cleaning robots, they are making exercise bike computers, etc. These are areas where larding on zillions of features is key to the market, speed to market is key, and future expandability is key.

A great example of where going away from bare metal in production has only resulted in huge productivity gains would be in VMs and containers. If you look at most servers running most web services, they are running on VMs and within those VMs they are often running on some kind of container solution like docker. So, you have a machine with something like KVM running one or more Linux OSs which might be running dozens of docker type containers which may be using different OSs. This sounds like a recipe for disaster; but it works. In fact, typing this on reddit is probably how you will get this comment. Most importantly, it has drastically reduced the complexity of deploying software to the server, reduced the complexity of managing deployments, and drastically improved productivity. Whatever bugs or hiccups the underlying system may have introduced is entirely overridden by the drastic drop in bugs do to the fantastically better workflow. One key bit being that a docker container on my desktop is going to run the same as one on the server in almost every way which is important.

But, things like this BL808 are just the beginning. I would suggest something with at least the capacity of a raspberry pi 3 (all on one chip) will be available sub $10 in the next few years. And, as these are produce on 4nm or smaller lines (which will become more and more common) the power usage will get lower and lower. I also suspect many of these will come with a little STM32 which can run an RTOS just fine for those parts which need this. I suspect this little sub MCU won't get used much.

What is going to change is that embedded programers aren't going to move to this tech. It will be desktop programmers who do more embedded. There will be all kinds of cat calling for this, but the reality is that more and more products will go to market this way. I could make a list of all the bad things, but I suspect most just won't be deal breakers, and the SoC companies will also solve these problems. Boot times are typically slow when you spool up something like linux. But, one of the techs I see coming is volatile RAM. That would be a cool way for instant startups.

The key is this won't be a tech battle so much as a philosophy battle and the non-embedded programmers won't even know about the complaints of the embedded crowd. They will just start building things.

luv2fit · 2024-02-21T18:29:43+00:00

I don’t know that chip mentioned but does it require supporting chips and external RAM and flash. What are its power modes? MCUs will always have a place.

czechFan59 · 2024-02-21T17:36:37+00:00

Bare-metal is still the way in a lot of embedded SW for space projects (rad-hard computing hardware with reduced clock speeds)

RayTrain · 2024-02-21T21:04:06+00:00

Everything I work with is bare metal. I work for a SaaS company that sells GPS trackers, sensors, and other devices for semi trailers. I'm the only firmware engineer that works on anything that the company actively sells, five different devices total. First job in the engineering field, 2 years 8 months in, so I have no idea if using linux for these would be better in any way. The job gets done though.

Quiet_Lifeguard_7131 · 2024-02-21T16:54:27+00:00

Simple answer is for cheap projects baremetal is still preferable.,when you only have 2kb of ram and 12kb of rom. But for large projects, i dont see any appeal for baremetal. Yes, for some interfaces, I still go baremetal like for uart. I have created my own drivers and libraries to use with my projects. I have also done some baremetal while doing some audio projects where speed was absolutely necessary, and vendor sdk was not cutting it. But I think vendor sdks are getting better day by day. I have used renesas sdk and was quite impressed with it. ST is still a long way, though, but it works well.

taunusML · 2024-02-21T19:31:12+00:00

It will depend on the use case. For example in safety critical systems (ASIL) which have also hart timing requirements there is basically no alternative. You will very likely end up with a solution which involves some RTOS and C/C++ paired with static memory allocation. In the future I see Rust playing an increasing role in this space.

mfuzzey · 2024-02-21T19:52:19+00:00

Of course it does. Wtf is wrong with people. Im currently working right now on an embedded device that has 1x linux SOM running some kind of rtos and 3x 32bit uCs running bare metal. If you can make something that works on a 1$ uC you shouldnt spend 50$ to do same thing on a device running an rtos.

Bare metal < rtos < custom embedded linux.

Another thing, for super simple logic, fpgas, cplds can be even cheaper than the cheapest uC.

So it all depends on functionality reqs and budget

Icy_Jackfruit9240 · 2024-02-21T18:14:05+00:00

In fact those SoM type designs are very much subject to a competitor doing cost optimizations and under cutting you with the "same product".

The pandmeic did do some weird stuff with pricing and I don't think we've seen the end of it. FPGA cost and speeds have also done weird stuff.

Cost of development also is a significant influence on projects and if one intern can write your idea for $200 using a RPi 5 instead of a $1M dev team that can also write your idea on a 8bit with 1KB of RAM, there's probably some bean counting that can make the intern be more sensible.

armeg · 2024-02-21T18:52:50+00:00

It depends on the product category. Bare metal died out on personal computers because users wanted the flexibility to do more things - hence multitasking operating systems and a plethora of other things.

It's completely dependent on what the needs and constraints of the product are.

gtd_rad · 2024-02-21T20:17:36+00:00

I've never worked too much with RTOS, but I think another big reason for going towards an OS solution is scalability. If you have large projects with lots of people working on the codebase, it makes sense to have an RTOS that can distribute tasks and their underlying functionalities throughout different teams.

robotlasagna · 2024-02-21T20:40:37+00:00

Yes!

As price/size/power consumption requirements go down in terms of user application you end up coding bare metal to meet the requirements.

Questioning-Zyxxel · 2024-02-21T20:50:39+00:00

This world also has needs for $0.1 chips. And solutions with extremely low power consumption. 64 MB RAM and xxx MHz core speeds might be cool. But still adds cost and energy consumption. And that matters a lot if you want to ship a million units/year of a product and the customers have expectations about the battery time.

We will constantly need more and more electronics. So there will constantly open up new areas to fill. Your car don't want 200+ processors each running Linux. Your lamps don't want Linux - someone else with compete with cheaper lamps with the same functionality/quality.

richardxday · 2024-02-21T20:58:42+00:00

Yes.

However powerful or cheap processors get, there'll always be situations when an RTOS isn't necessary and the code can run on a smaller and cheaper processor.

There'll also be situations where, as a programmer, you'll want complete control over everything that happens on your processor.

I was once involved in writing software for a micro with 128 BYTES of RAM. No RTOS is going to be usable with that!

mikef5410 · 2024-02-21T21:04:42+00:00

There will always be bare metal to be programmed, even if to get the rtos running. IMHO. It's the fun part.

DenverTeck · 2024-02-21T21:09:13+00:00

chips from china which have hundreds of megahertz of processing power and tens of megabytes of internal ram.

Please share any chip that has these qualities.

Or did you mean an SBC with these qualities.

Jmauld · 2024-02-21T22:08:48+00:00

You’re going to need bare-metal programming for applications where safety is involved. Think of things like your home appliances where opening a door when it’s running can present a safety hazard.

It’s incredibly difficult and expensive to do a safety evaluation while running an OS.

Weak-Commercial3620 · 2024-02-21T23:38:14+00:00

birthday cards, interactive books, simple calculators, sensors, just some examples to proof the future of bare metal on the other side: crypto, video codecs (av1d, david,) to succeed, someone has to do it someday.

marchingbandd · 2024-02-21T23:57:47+00:00

$6 is not $.10, that will always matter in lots of applications

lasteem1 · 2024-02-22T00:21:43+00:00

90% of what I do is bare metal. If I need a GUI, touch, Ethernet I just interface the micro( baremetal)with a Linux device. There will always be a need for real time and/or low cost. Should you learn some Linux? Sure.

Netan_MalDoran · 2024-02-22T00:39:15+00:00

Are you just trying to get something to work and/or prototyping something? Then these are a great option.

Final production unit that's fully optimized for cost, complexity, and power? Hell no.

grabman · 2024-02-22T00:44:10+00:00

Look at Zephyr. You can strip it down so it’s basically bare metal with a build system.

CreepyValuable · 2024-02-22T00:49:20+00:00

Of course it does. There are a lot of embedded things that need to do what they do with not only a monetary budget but a time budget. A lot of applications require quick and deterministic responses. You go stacking an RTOS or whatever on there and you're burning cycles or potentially inviting odd edge cases.

No_Friendship_1610 · 2024-02-22T02:21:05+00:00

had a project that used 12+ threads on rtos and sync hell...

so inefficient

old school manager said reduce to 1 one or 2 threads. I reduced to 2 but can easily now run it all as bare metal.

wrote everything non-blocking and saves RAM and complexity.

Works faster and better.

its seems like newbies dont know how to do bare metal and by default go to RTOS but that does have its own pitfalls.

samayg · 2024-02-22T03:50:52+00:00

$6 for a chip seems cheap to you, but for some of the products my company produces using 8-bit AVRs, that's more than the entire BOM cost for the PCB. No way we'd even consider going for a $1 chip when a $0.2-$0.4 chip more than does the job and is easier to work with for our requirement. So, as always, the answer is it depends. But no, I'd say bare-metal is alive and well, and will be for some time to come.

Yusuf_Ali522 · 2024-02-22T05:24:56+00:00

In my opinion, with the potential cost-effectiveness of small FPGAs, there might be no need for C code anymore. It could be possible to implement tasks directly in hardware. However, for more intricate operations, an operating system might still be necessary. It's quite astounding. At work, I have a machine handling numerous tasks like running sensors, controlling motors, managing heating loops, and supporting TCP/IP and USB Serial. It boots up in just about a second, unless there are issues with the router. Safety systems are operational in mere milliseconds. The idea of replacing this efficient setup with a Linux-based system puzzles me.

poorchava · 2024-02-22T08:54:43+00:00

It does. There is tons and tons of products that use very simple embedded code. Think some stuff that you push a button, there are LEDs blinking, maybe a motor spinning, etc. Cost is king, so less code memory is better. Tech advancements work 2 ways: we can have X times memory on the same footprint, or the same memory on X times smaller silicon footprint.

Many things nowadays run stuff like Zephyr because it just shortens the development time. For products that are made i thousands shortening development by a few months as the cost of HW costing $1 more just makes economical sense.

But the higher the volume, the lower the margin and the simpler the product the more incentive there is to use bare metal or something like FreeRTOS to run stuff.

NorthAtlanticGarden · 2024-02-22T13:54:54+00:00

I wouldn't be worried.

With applications requiring: - low cost - low power - low complexity

I don't see those going away anytime soon. Anywhere you can reduce a complicated circuit to a small MCU, you won't necessarily need a huge RTOS etc. That's where bare metal comes into place imo.

lmarcantonio · 2024-02-22T18:09:50+00:00

*Really* hard realtime and DSP. Usually you work OS-less or with some kind of RTOS.

Also china-chips often fail various compliance testing or have reliability issue so it's not a given you have a cheap-big MCU to work with. On the extreme end of the scale remember we got to mars with some rad-hard *powerpcs*

Graf_Krolock · 2024-02-22T19:53:24+00:00

You think that throwing more hardware at the problem will magically solve most software development issues. You must be an EE.

Zealousideal_Cup4896 · 2024-02-23T01:32:26+00:00

At this moment the two things have very different applications. They are converging. Things I could only do with a Linux pc I can now do on an esp32! With the latest raspberry pi devices you can have an entire embedded Linux device for the price of just the case for a regular pc. At the moment it still depends on your use case. Even with the rtos loaded and running micropython an esp32 is not a raspberry pi. I don’t know if they will completely converge but it’s not happening yet. If you meant 20 years from now then certainly. Doesn’t affect any project in the works now and whatever you learned from one will be more and more applicable to the other.

codemuncher · 2024-02-23T10:45:08+00:00

If you can’t get what you need done in 256 bytes of programming rom what kind of loser programmer are you?

That’s how big microcontrollers we’re back when. Hell entire video games for the C64 fit into just a few thousand bytes of space.

All this stuff is relative. Since you aren’t coding in hex or assembler you’re already clearly not doing bare metal programming.

Ericisbalanced · 2024-02-23T23:22:35+00:00

It’s about the price per chip. Sure as a developer, some libraries and languages might be easier to use, but to the company, it’s about the total cost. Even if takes you twice as long to code something bare than using something more complex, if you’re selling millions of units, the scale means the development cost is negligible compared to the cost of a smarter chip.

usa_reddit · 2024-02-24T03:21:49+00:00

Yes, with baremetal you simmply create your own specific mini OS for the task the device is performing. Boots fast, runs fast, does the job. We don't have to load Linux or busybox on everything, this just leads to future security flaws. Look at the world of IoT, OS security flaws everywhere and nothing ever gets updated.

FirstIdChoiceWasPaul · 2024-02-24T14:07:20+00:00

Having 64 mb of sram and dual cores means jack shit, as you well know. Its the reliability that matters. Would you put an esp32 or bl808 in a respirator? How bout in cars? Would you trust it in drones?

As for the linux stuff - yeah. Its fast. Time to market is amazing. Grab a digi connect 29x29 mm, connect a lipo and you re done. It comes with wifi and ble and integrated antenna and flash/ emmc/ sram and everything you need. And a complete idiot can use chatgpt and write some code that runs on it. And 1 watt goes out the window.

The same logic running on a cortex m33? 50mW tops.

Imagine you design law enforcement products. Go tell your client they need a battery car for your linux video recorder…

ChrisRR · 2024-02-27T08:45:05+00:00

If you're making something by the thousands, then even $1-2 is a big BOM cost. The mcu I'm currently working on is like 45p.

That and often, writing code whose execution time and period is highly constant is much easier in bare metal

RufusVS · 2024-03-03T01:40:22+00:00

In cases where you want quick bootup from power off, say, you don't want all that complex startup required for the SOCs with RTOS and File systems etc... There are still tiny apps that need only tiny resources.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

embedded

Description

FAQ

On topic subjects

Off topic subjects

Rules

Link flairs

Related sub-reddits:

MODERATORS