Trust and control. Those are the compelling reasons for "programming at the bare metal" - which is a phrase that I first heard in the early 1980s. At that time, it meant writing programs in assembly language for just about any available computer, especially (though not limited to) micro-controllers like 8080, Z80, 8051 and those weird MicroChip PIC processors. During my undergraduate years in the late 1960s (when we finally got rid of the abacus and slide rule), we all took a shot at bare metal programming on the dinosaurs in the "computing lab". We had an IBM 1620, later replaced by an IBM 360/40.

With the advent of the IBM PC (sounds like an IBM commercial, doesn't it? I actually worked at UNIVAC and TI for a time, so it was just that IBMs were available), there was DOS. If you wanted to do anything fancy, you could use some of the simple services, but you would still end up writing a bunch of bare-metal code. Want to use interrupts for a serial communications program, write them yourself. Want to twiddle bits to make something happen? Write it yourself. I did that enough to get the attention of a publisher. Read all about it in "The Programmer's Guide to MS-DOS" if any copies still exist.

Side note: I was on a compiler writing team at UNIVAC (late 1970s) for a military mini-computer and was responsible for a part of the Pascal compiler and the runtime environment. I spent a year commuting from Minneapolis to Florida doing field work at an installation. I would get updates by courier (no internet), but any bug fixes that I made meant that I inserted a BRANCH instruction in binary form at the point of the fix; insert the fix in high memory in binary with a BRANCH back to the rear of the error. This was all done with toggle switches for each bit of the address and the data with lamps to show the memory contents. You could get really good at entering code that way after a while. Easy place to mess up, too.

Over the years, I have accumulated a hoard of "bare-metal" routines that I use all of the time. That is the control part. I know exactly what is happening in the hardware and software because I wrote it. If something goes wrong, I know that it is my own fault and I fix it. No mistakenly pointed fingers at some company for my own dumb typos. All of the interrupt routines, data structure schemes and program timing are my responsibility; I don't have to trust somebody else to have it right.

I currently use ARM-7 and Cortex processors from various sources. My workspace is awash with development boards - many of which are available for adoption to a good home. I am trying and failing to retire. :-)

My programming model is simple and works well. An infinite loop the repeated calls to major functions in the scheme. Call them "threads" if you wish. Each function is a finite-state machine which either performs the current function or waits for another event (from interrupt, for instance) or waits for a timer to expire. No lengthy loops allowed in the FSM - just enter, do something simple, change the state, if required, and leave.

Which brings me to the innovation that lies between "bare-metal" and RTOS: The manufacturer supplied SDK and drivers. Who knows better than the chip maker on how to use the peripherals? Well, this became a trust issue. How good are the people at NXP, STM, MicroChip, Freescale, etc. at programming their own stuff? Do you trust them? I don't. I use the drivers, but I read them to understand what they are doing.

For instance, there are days when USB drivers appear to be on the edge of magic. I like to use the supplied drivers. It would even be better if they worked properly. I got a great education in USB by debugging the supplied driver from %&$&^. At least I had the source for the driver, found the error, fixed it and notified %&$&^ of the problem and fix. Have no idea what happened after that. Trust and control.

I considered an RTOS at one time. Turned out that I was so deep into "rolling my own" that I had most of the functions covered. I would have had to change some of my style (another reason for "bare-metal") to match the style of the RTOS. Stayed with what I knew.

I think that I have rambled enough.