Bare Metal Programming for Beginners

Click For Summary

Discussion Overview

The discussion revolves around the concept of bare metal programming, particularly in the context of microcontroller development. Participants explore its definition, implications, and practical applications, including the use of development environments like Keil and mbed. The conversation touches on both historical and modern perspectives of programming directly with hardware.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested

Main Points Raised

  • One participant suggests that bare metal programming involves directly interfacing with hardware, using an ARM Cortex-M4 microcontroller as an example, and questions whether using an IDE like Keil still qualifies as bare metal programming.
  • Another participant disagrees with the characterization of bare metal programming as involving a compiler, arguing that true bare metal programming is closer to assembly language and does not include such abstractions.
  • A different perspective defines bare metal programming as low-level programming that maximizes efficiency in various metrics but notes that modern practices often favor higher-level programming due to advancements in hardware.
  • Some participants recount historical experiences with bare metal programming, describing methods of entering programs directly into hardware without an operating system, illustrating the evolution of the term.
  • One participant mentions that the definition of bare metal programming has become flexible, suggesting that it can mean different things to different people, and that there are no strict definitions governing its use.
  • References to external sources, such as The Hacker's Dictionary, provide additional context on the term's meaning and its implications in programming practices.

Areas of Agreement / Disagreement

Participants express differing views on what constitutes bare metal programming, with no consensus reached on its definition or the implications of using development environments like Keil. The discussion remains unresolved regarding the boundaries of the term and its application in modern programming.

Contextual Notes

There are varying assumptions about the relationship between programming languages, compilers, and hardware interaction, leading to different interpretations of what qualifies as bare metal programming. The discussion also highlights the evolution of programming practices over time.

Tone L
Messages
72
Reaction score
7
TL;DR
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?
 
Engineering news on Phys.org
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/
 
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.
 
  • Like
Likes   Reactions: Tone L
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.
 
  • Like
Likes   Reactions: Tone L and 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.

Altair Front Panel.png

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
 
  • Like
Likes   Reactions: cnh1995, Tone L, Jody and 2 others
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.
 
I almost forgot. We can always use The Hacker's Dictionary

http://hackersdictionary.com/html/The-Jargon-Lexicon-framed.html said:
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.
 
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!
 
  • Like
Likes   Reactions: Tone L
  • #10
Thanks for the feedback everyone :biggrin:
 
  • Like
Likes   Reactions: berkeman and Tom.G
  • #11
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).
 
  • Like
Likes   Reactions: Tone L, anorlunda and berkeman

Similar threads

Replies
4
Views
5K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 17 ·
Replies
17
Views
24K
Replies
8
Views
4K
Replies
4
Views
3K
  • · Replies 11 ·
Replies
11
Views
8K
Replies
10
Views
5K
  • · Replies 6 ·
Replies
6
Views
7K
  • · Replies 7 ·
Replies
7
Views
4K