

Building Bare-Metal ARM Systems with GNU - ternaryoperator
http://www.embedded.com/design/mcus-processors-and-socs/4007119/Building-Bare-Metal-ARM-Systems-with-GNU-Part-1--Getting-Started

======
ChuckMcM
This is a really old article (2007) and misses all sorts of stuff. Basically
ARM Holdings Ltd has stepped up to support the arm-none-eabi toolchain on
launchpad.net, there are solid libraries (like
[http://github.com/libopencm3/libopencm3](http://github.com/libopencm3/libopencm3))
and support in tools like OpenOCD. Not to mention my Google+ group (Cortex M
Developers) :-)

~~~
AceJohnny2
Thanks for the info (and diydsp's below).

diydsp linked to [https://launchpad.net/gcc-arm-
embedded](https://launchpad.net/gcc-arm-embedded) which covers Cortex-M and
Cortex-R cores, but importantly doesn't mention ARM11 and Cortex-A cores used
on the Raspberry Pi and BeagleBoard Black.

I suppose the latter aren't considered "embedded" in the sense that, hell,
they run Linux, and so aren't covered by ARM's compiler support effort but by
the community?

~~~
saidajigumi
The line on "embedded" has blurred. I'll wax on for a moment for folks who
aren't clear on the distinction that's grown up. In the most long-lived sense,
"embedded" meant a processor that provided functionality in a non-general
purpose device. In this usage, a robot or refrigerator CPU would be embedded
while the same hardware running a WIMP desktop system would not. I still
consider this usage current.

In the shorter-lived sense, "embedded" referred to low-power, limited
functionality processors such as the ARM7/ARM9 CPUs in TFA. These setups often
didn't have MMUs, would typically run a _very_ bare-bones RTOS with soft- or
hard- realtime support. Remember no MMU means _no process isolation_. If a
task has a stack overrun, it just keeps going into an adjacent task's stack.
If a pointer gets corrupted and the software starts writing who-knows-where in
RAM, pray it dies early, hard, and reproducibly. The code size, ability to use
third-party libraries, etc. were all greatly limited. Very much more the
aesthetic of engineering a one-off custom mechanism, albeit in software vs. in
the machine shop.

These days, the envelope of "embedded" CPUs has embraced _vastly_ more
powerful hardware, while still remaining low power. They have MMUs, they run
real Linux (vs. ucLinux or a traditional RTOS) and are much easier to develop
for. Think Arduino, Rasberry Pi, and on and on. This has been a huge access
revolution for hackers, makers, and anyone who wants to just get down and
prototype some ideas.

~~~
jmpe
Embedded means bare metal access to everything. An OS like Linux shields such
functionality, which is why it's frustrating to implement something as simple
as a triac dimmer in a Linux SoC without doing everything in kernelspace to
avoid kernel jitter and event delays.

Embedded systems typically run on a microcontroller. It almost literally means
something that reads an input from the physical world (EXTI, logic level or
adc) and uses it to control something. Microprocessors typically implement a
bus system and additional units like an MMU. We used to have uC with basic
busses, but that was for different reasons (EPROM, LCD, ...)

These days the word embedded seems to mean "fits in a small box".

~~~
AceJohnny2
Hah, indeed. I consider myself an "embedded developper", imagine my confusion
a few years ago when I started needing mmap() to access registers...

------
markrages
Are other sections available? They are 404 for me.

~~~
zhemao
I searched around a bit and found this PDF link.

[http://www.state-machine.com/arm/Building_bare-
metal_ARM_wit...](http://www.state-machine.com/arm/Building_bare-
metal_ARM_with_GNU.pdf)

It seems to have the full series.

------
aceperry
Pretty old article, I saved a copy from a while ago. It needs to be updated
for the Cortex M series, which is a more appropriate line for bare metal
development.

