Arduino: now a Single Board Computer!

I have no problem with this use of Single-Board Computer.  The earliest SBCs had very simple processors like Intel 8080 or MOS Technology 6502, which didn't have MMUs and didn't address much memory.  When I hear the phrase "Single-Board Computer", I still think of Multibus

I have no problem with this use of Single-Board Computer.  The earliest SBCs had very simple processors like Intel 8080 or MOS Technology 6502, which didn't have MMUs and didn't address much memory.  When I hear the phrase "Single-Board Computer", I still think of Multibus

John Beetem wrote:

 

When I hear the phrase "Single-Board Computer", I still think of Multibus

The rival VME Bus in my case --- I still have some self-made 68k-based VME boards in a box somewhere, and I wrote a program to lay out VME backplanes to link them up.  Motorola did everything much more elegantly than Intel in those days.

But to avoid the confusion of meanings, I highly recommend "bare metal microcontroller" to refer to this type of board and processor.  It was unambiguous .... er, until now.

Morgaine Dinova wrote:

 

But to avoid the confusion of meanings, I highly recommend "bare metal microcontroller" to refer to this type of board and processor.  It was unambiguous .... er, until now.

Well, I use the term "bare-metal programming" to mean programming a processor at the machine/assembly language level (usually using C as a portable assembly language) with no device drivers restricting my access to the hardware.  So I can in principle do "bare-metal programming" on any processor -- with or without MMU -- whether or not it is capable of running a mainframe OS like GNU/Linux.  Now it's generally easier to do bare-metal programming on a small microcontroller since you don't need 50-100 pages of initialization code, but as long as the hardware is documented it's certainly possible to treat an ARM Cortex-A15 as a bare-metal processor.

By the way, jamesh at RasPi doesn't like the term "bare-metal" since he thinks you're programming at the silicon level.  I didn't bother to explain to him that once the chip is in a package, you can only access it through the metal pins.  However, I do use the phrase as often as possible chez RasPi just to be cheeky.

You're right in an absolute sense, since you can do "bare-metal programming" even on an applications processor by booting into your application directly instead of into an O/S kernel first.  You can also do the opposite, for example run uClinux on a microcontroller and program as if you weren't actually hitting the bare metal (you realize that you are though as soon as things go wrong).

However, in a practical sense, the use of these two types of programming does actually correlate very strongly with the type of device being programmed.  In practice you never do bare metal programming on an applications processor (unless you're developing the kernel or a kernel driver) and likewise, you never do anything but bare-metal programming on a microcontroller without an MMU even when the illusion is sometimes offered.

This distinction corresponds to the different levels of programming abstraction in the two cases.  On an applications processor running a system like Linux, the kernel creates an execution environment for user-mode processes that is a virtual abstraction which has very little to do with the details of the hardware, and this abstraction is enforced by the hardware MMU so it cannot be broken, bugs aside.  On a microcontroller lacking an MMU, there is no such virtual abstraction enforced by hardware, so even if software wizardry provides a superficially similar environment, when you're programming in C then a single errant pointer can penetrate the facade and ruin your whole day.

And to complete the picture and my (greatly relieved) total reversal, John, there won't be any need for bare-metal programming on the Galileo.  We can happily write bug-ridden code in the cosy abstraction of MMU-protected processes.