开云体育

I really hate going this far off topic (yea - I know "Don't")

MSDOS is an OS. Not really bare metal programming:







Note:
"Bare machine (or bare metal), in computer parlance, means a computer executing instructions directly on logic hardware without an intervening operating system. "

and where it states:
"Bare machine programming remains in common practice in embedded systems <>, where microcontrollers <> or microprocessors <> often boot directly into monolithic, single-purpose software, without loading a separate operating system. Such embedded software <> can vary in structure, but the simplest form may consist of an infinite main loop <>, calling subroutines responsible for checking for inputs, performing actions, and writing outputs."

Bare metal means you really have no OS at all, you do all memory management, I/O interface and any thread management yourself.

MSDOS provides hooks to the hardware to allow for these tasks - so DOS programs really aren't running "bare metal" If you recall MSDOS had memory managers , like EMM386 that allowed access to memory beyond 640K.

For example

Just do a dir /s on the root of a fresh install of MSDOS or FreeDOS and you'll see all the drivers and files that are booted by the OS...

In fact the key part of the MSDOS acronym is the DOS part - Disk Operating System
On a true bare metal system, you'd being doing your disk reads and writes at low level in your code - not just calling the OS to handle it.


For the rest of this rant, a note to those that speak "English":

When I mention non-volatile, equate that to your PC's hard drive. Stuff that has to survive a power down.
When I mention volatile, equate that to your PC's memory sticks. A place for temporary storage.


Typically bare metal programming is usually limited to microcontrollers (see below).

In my day job I develop hardware with things like ARM M and A series cores -some are standalone (NXP/Qualcomm, Microchip/Atmel, ST Micro, etc...). Some are combined on "System on a Chip" architectures where they're combined with additional logic (in some case reconfigurable logic such as in a Field Programmable Gate Array [FPGA])

The M series is a self contained microcontroller (similar to 8 bit things like old Z80, 8051, old Moto 68xx, AVR) offering 32 bit architectures.

These M series have a small MMU [Memory Management Unit] that deals with the on-board RAM and FLASH, and some offer and extended external bus that's limited ( for instance EBI). The non-volatile code for things like the program is stored in Flash, the SRAM (Static RAM) is the working memory where the application stores things like variables.



This memory - both non-volatile and volatile is on the orders of kilobytes to low-megabytes. Yes - kilobytes. Remember those?

For instance -an Arduino has kilobytes of flash and even less ram. It's an 8 bit processor (even the Mega's) and can run at clock speeds of 20MHz or so. Some of the more capable 32 bit ARM M series can run in hundred of Megahertz.


What's on something like a Raspberry PI is known as an A series ARM. This has a more sophisticated MMU for things like gigabytes of external memory (ie - external from the CPU IC) used as working memory . Boot code and/or OS as well as user programs are often in some sort of external non-volatile storage such as an SD Card; some microcontrollers offer booting via USB devices.

ARM A series stuff can run in the Gigahertz speed range. Much more capable. Not as much as a modern Intel or AMD "microprocessor" but still not too shabby. Unless your doing something that require heavy math, graphics, etc...

These usually requires an OS - tho my one coder Sanjay has done some stuff for local aerospace guys that runs "sort of bare metal" - ie no OS. Still heavy reliance on porting of OS drivers for use in single thread bare metal stuff he does...

These A series have an MMU that can run external memory similar to what's in your desktop or laptop (typically DRAM of some type) - in fact they offer little memory on the actual CPU integrated circuit(beyond some small on-chip memory registers and basic initialization/boot code) .

Also note that DRAM is a bit more complex to deal with than SRAM.

Not enough to really run any kind of program - typically require and OS of some sort to manage the larger off-chip DRAM memory.

So...

ARM A series (like in your smart phone or on a Raspberry PI ) usually run an OS. Much more memory (both non-volatile and volatile/working). Higher clock speeds. Support for some higher level graphics and peripherals, with higher speeds. Usually not considered "bare metal" programming,

Phones run an OS like Android or Apple. The Rasp PI runs a version of Linux...

ARM M series run things like your washing machine. Small amounts of memory and slower clock speeds. Slower peripheral speeds.

Typically don't run an OS - tho recently things like FreeRTOS and some embedded linux will run on M style non-MMU devices. FreeRTOS is also an operating system that contains realtime extensions. Usually programmed "bare metal" tho, most microcontrollers have some sort of Integrated Development Environment (IDE) that provides a framework of code - ie, usually the mfg of the IC or architecture will provide "driver" level libraries that hook to things like on-board peripherals and chip features such as DMA.

And a lot of these are flakey as poo... In fact, as I write this one of my coders is battling stoopid in FreeRTOS with regard to vendor supplied framework code for an on-board peripheral


To get on machining topics and as an example - a Cortex M3 series TI LM3S6918 part is what's in the Smoothstepper ESS.


"The ESS also has a microcontroller, which is used for additional processing that the USS would be unable to do."
It's possible that Warp9 is running an OS. These TI parts are what he uses for the actual Ethernet connection - these parts offer both the MAC and the PHY on chip.

For that he's probably using a network stack called LightWeight IP.

So even this isn't really "bare metal" - he's leveraging opensource software for the network functions. Believe me, trying to write your own TCP/IP stack would not be easy...

So now you have a similar situation as what you face with an OS - code that sits between you and your program. Again not totally "bare metal" - you're relying on someone lses code.


So it gets even more arcane - bit more on the Microcontroller vs Microprocessor:



-



The difference between a microcontroller and a microprocessor is getting blurred all the time.

ARM's - both A and M series - are usually considered microcontrollers, tho some of the newer ARM architectures like those from Allwinner and found in things like Personal Electronic Devices (PEDs - can anyone tell I've had to endure security training?) can almost be considered microprocessors.

But this is getting even fuzzier with companies that manufacture A series devices (ones without on-board memory and a more sophisticated MMU as per a microcontroller) offering things like DDRx (1,2,3,4) on a single substrate or multichip module - mimicking a lot of what delineates a "microcontroller".

Typically a microcontroller boots from some sort of on-board, non-volatile memory and has on-board SRAM for things like variable storage and working memory

Typically a microprocessor has some sort of "system bus" that interfaces the CPU to external memory. It has some sort of BIOS firmware to get everything in order on a pwoer up, and boots up from some sort of external non-volatile storage. It usually runs DRAM for working memory


Note that in recent microprocessors more of what used to be supported via a "chipset" is now being put on-board (whether is be on-die or on a multichip module)

As has been typical in the past, a microprocessor usually only offers the CPU and has a system bus that handles things like memory; additional IC's are sometimes used called and MCH (Memory Controller Hub - North Bridge) and an ICH (I/O Controller HUB - South Bridge)

(computing)


Around 2008, Intel incorporated these function into a PCH (Platform Controller Hub)


To extend performance even further, newer things like the latest Intel microprocessors incorporate the PCH features into stuff like the sandy bridge:


Regardless, these higher level architectures really require an OS with support for these features. Granted there are some guys in areas the audio world - one being Voxengo - that writes a lot of stuff in x86/x64 assembly. But it's still not "bare metal" per se... they still require the support of an OS.

Trying to do "bare metal" on an x86 or x64 architecture is do-able, but writing all the support for something like even an older x86 would be a daunting task.



.