Bare Metal Programming for Beginners

[Tone L]

TL;DR Summary

What would you define as bare metal programming?

Hey friends, I have had some time on my hand due to the COVID-19 pandemic and I hope everyone at PF is doing well. Thus, I have been learning some introductory electronics. This may be more of an opioniated question but, I am curious to hear from some ~experts~.

From my understanding, bare metal programming is the programming level used to directly interface with hardware, like a microcontroller. A level up from assembly, if you will.

So for example, you are programming an ARM Cortex-M4 microcontroller on STM32F4-NUCLEO development board. To program the microcontroller, we are using Keil, this is a software development environment for a wide range of Arm Cortex-M based microcontroller devices. Keil includes debugger, compiler, etc., so with all this stuff (Keil stuff) are we still technically bare-metal programming, right? We aren’t using an OS on the board or anything. So I think it is.

I think it would be rare for a someone developing some control system circuit to build their own programmer to interface with a microcontroller.

So is the norm for embedded system development to use software like Keil?

Bonus question :) - mbed, I am trying to wrap my head around mbed, but it keeps harping on IoT. Is it like Keil, an IDE?

 

[phinds]

I'd never heard the term before but from what I can see from a brief froray into Google you are right in the context. I don't agree at all that this is "used to directly interface with hardware " since it includes a compiler, which is one level of padding up from assembly language (which IS used to directly interface with hardware).

Even the C language, which is as close to assembly as you can get in a compiled language, is not bare metal programming. For example, the C compiler itself (in UNIX at least) is written in C, but the DRIVERS in the compiler are not written in C but rather in assembly because they have to be bare metal programming.

https://www.physicsforums.com/insights/computer-language-primer-part-1/

 

[Baluncore]

BareMetal, (one word), programming is probably Programming in the BareMetal environment.
https://en.wikipedia.org/wiki/BareMetal

Mbed is a system designed to speed development of ARM products.
Read this then follow the links from here... https://en.wikipedia.org/wiki/Mbed

 

[DaveE]

OK, according to me, bare metal programming is low level programming that maximizes efficiency, in latency, throughput, memory, power consumption, etc. This is usually at the expense of ease in development, readability, elegant structure, reuseability, maintainability, etc.; i.e. low level instead of high level languages.

Once upon a time it was assembly language, but I think that's mostly gone. With the advent of FPGAs and such to efficiently take over the critical tasks and the advent of high power processors, many of these limitations have gone away. Instead of writing really efficient code people now just pay for a bigger, faster processor. Personally, I'm not sure there is any ARM uP that I would consider small. There may be a need in the largest, fastest uP to have a bit of efficiency in doing time-critical HW stuff. However, that's probably something that someone else did in a library or uCode.

Nowadays, I'm not sure what it means, but it must refer to these real world interfacing limitations requiring efficiency in your run-time code so that you can't use the easy tools.

For example, anything that you may do with a PIC8, PIC16, MSP430 that interfaces with something else is as close to bare metal as you'll probably see today.

 

[Joshy]

Great question! I was working on a controller board and called an application engineer for help. One of their first questions was if I was going to use bare metal and I was totally confused.

I still don't have a confident answer, but I think it's when the controller board does not have an operating system (like linux) installed on it.

 

[Tom.G]

Well, Bare Metal programming started out meaning you were interacting directly with the hardware -- as in flipping front panel switches to enter a program.

At this level there was no operating system involved and no programming language. If you had a program stored on a peripheral that you wanted to load, you manually entered a program, in Binary, flipping switches, to read the peripheral and store each byte in memory. (I did that often enough that I had the loader program memorized, usually... every now and then it/I failed and had to get my wife to load it! That's how we both learned machine language programming.)

At some point Bare Metal programming morphed into any program you wrote that directly controlled some hardware.

Here is a photo from a 1975 computer that had only front panel switches for program entry. There were earlier 'professional' computers with similar front panels for a few thousand dollars, but this was the first one aimed at the general public, at a base price of a few hundred dollars.

I still have that computer, and after replacing all the electrolytic filter capacitors last year, it still works!

The row of 16 LEDs across the middle of the front panel indicate the memory address, in this case hex 0081 or octal 000201. The 8 LEDs on the upper right show the memory contents at that address, hex 06 or octal 006. The upper left LEDs show the state of the CPU and Control Bus Status lines.

Cheers,
Tom

 

[anorlunda]

I'm so ancient that I used the methods described by @Tom.G not just for the loader, but to enter and debug the entire application (a training simulator analogous to a flight simulator). Learning to read numerical results in binary with those lights was challenging. My predecessors did apps of similar complexity on a computer that had only 3 (24 bit) words of memory, plus a drum for bulk storage.

A company called Interdata in the 70s had the first hardware debugger. It was a knob labeled "SPEED". You could use the knob to slow down execution enough to watch the progress of your program instruction-by-instruction on those lights.

But in modern times, you can define Bare Metal to mean anything you want. There are no language police. Somebody could make a variant of Python and name it Bare Metal. Don't count on other people using the same meaning of Bare Metal that you do.

 

[anorlunda]

I almost forgot. We can always use The Hacker's Dictionary

bare metal n.

1. [common] New computer hardware, unadorned with such snares and delusions as an operating system, an HLL, or even assembler. Commonly used in the phrase `programming on the bare metal', which refers to the arduous work of bit bashing needed to create these basic tools for a new machine. Real bare-metal programming involves things like building boot proms and BIOS chips, implementing basic monitors used to test device drivers, and writing the assemblers that will be used to write the compiler back ends that will give the new machine a real development environment. 2. `Programming on the bare metal' is also used to describe a style of hand-hacking that relies on bit-level peculiarities of a particular hardware design, esp. tricks for speed and space optimization that rely on crocks such as overlapping instructions (or, as in the famous case described in The Story of Mel (in Appendix A), interleaving of opcodes on a magnetic drum to minimize fetch delays due to the device's rotational latency). This sort of thing has become less common as the relative costs of programming time and machine resources have changed, but is still found in heavily constrained environments such as industrial embedded systems, and in the code of hackers who just can't let go of that low-level control. See Real Programmer.

In the world of personal computing, bare metal programming (especially in sense 1 but sometimes also in sense 2) is often considered a Good Thing, or at least a necessary evil (because these machines have often been sufficiently slow and poorly designed to make it necessary; see ill-behaved). There, the term usually refers to bypassing the BIOS or OS interface and writing the application to directly access device registers and machine addresses. "To get 19.2 kilobaud on the serial port, you need to get down to the bare metal." People who can do this sort of thing well are held in high regard.

 

[essenmein]

I'm by no means an embedded expert, but I'd never heard of this "bare metal programming" before...

I/we've done plenty of work on everything from ATINY24 to Infineon Tricore, most smaller stuff generally doesn't have an RTOS, we just write C functions, sometimes in assembly if needed (esp with resource light 8bit MCU), compile, dump to chip... RTOS and bootloaders are nice, update MCU code over CAN!

 

[Tone L]

Thanks for the feedback everyone

 

[Svein]

Some of us write hardware drivers - and that is "bare metal" programming. Yes, there may be an OS but it will not work until the basic drivers are finished. The most obvious example of hardware drivers are embedded in the BIOS of a computer - it will work even if no OS is installed!

Usually, you develop drivers for new hardware on another computer, using "cross-compilers" (compilers that produce code that is meant to run on other hardware).