1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
% ----------------------------------------------------------------------------
\chapter{Embedded Linux} \label{chap:embedded-linux}
% ----------------------------------------------------------------------------
\begin{flushright}
\emph{
If you treat your beta-testers as if they're \\
your most valuable resource, they will respond \\
by becoming your most valuable resource.\\
}
\textsc{\small Eric S. Raymond}
\end{flushright}
Once upon in time embedded systems didn't need operating systems. Things
have been so easy: all a developer needed was a good toolchain,
consisting of compilers and other development tools, probably an EPROM
burning device and things started working. After some time every
register of the CPU was known, a variety of library routines have been
developed and our brave developer was able to do his project with the
more and more well known system. The controllers had legacy interfaces
like RS232, i2c or SPI which connected them to the outside world and the
main difference between the controllers available on the marked was the
number of GPIO pins, UARTS and memory ressources.
Over the time, things have changed. Hardware manufacturers have weakened
the border between microcontrollers --~devices meant to work in embedded
systems~-- and full blown microprocessors. Structures became much more
complicated: where our good old controllers had just some interrupts
with some small interrupt service routines we today need complicated
generic interrupt infrastructures, suitable for generic software
frameworks. Where we had some linearly mapped flash ROM and some data
RAM we today have multi-stage-pipeline architectures, memory management
units, virtual address spaces, on-chip-memory, caches and other
complicated stuff, which is not exactly what the embedded system
developer wants do every other day.
Entering embedded operating systems. Although there are still some
processors out there (like the popular ARM7TDMI based SoCs) which can be
programmed the good old non-operating-system way, it is becomming more
and more difficult. On the other hand, legacy I/O interfaces like RS232
are increasingly replaced by modern plug-and-play aware communication
channels: USB, FireWire (IEEE1394), Ethernet \& friends are more and
more directly being integrated into today's microcontroller hardware.
Whereas some of these interfaces can "`somehow"' be handled the old
controller-style way of writing software, the developer following this
way will not be able to address the security and performance issues
which come up with the modern network accessable devices.
During the last years, this resulted in more and more of the small-scale
companies which developed little embedded operating system being pushed
out of the market. Nearly no small company is able to support all the
different interfaces, communication stacks, development tools and
security issues out there. New interfaces and -variants (like USB
on-the-go) are developed faster than operating system developers can
supply the software for them. This today results in a market
consolidation: only the largest commercial embedded operating system
supplyers will survive.
Only the largest commercial...? There is one exception: when the same
situation came up in the "`mainstream"' computer market at the beginning
of the 1990ies, people started to develop an alternative to the large
commercial operating systems: Linux. Linux did never start with a
ready-to-use solution: people had a problem, searched for a solution but
didn't find one. Then they started to develop one themselves, often
several people did this in parallel, and in a huge community based
evolution mechanism the best solutions found their way into the Linux
kernel, which over the time formed one of the most reliable and
performant kernels available today. This "`develop-and-evolute"'
mechanism has shown it's effectiveness over and over again in the
server and desktop market today.
Also for embedded systems Linux grew more and more popular. Studies have
shown that more than 70\% of the embedded developers are not satisfied
with a black box operating system: they want to adapt it to their needs,
to their special hardware situation (which most times is Just Different
than anything available). Embedded projects are even more variegated
than desktop- or server projects, due to the fact that there exist so
many different embedded processors with lots of peripherals out there.
Linux has evolved from a i386 only operating system to a kernel running
on nearly every modern 32 bit processor available today: x86, PowerPC,
ARM, MIPS, m68k, cris, Super-H etc. The kernel supplies a hardware
abstraction layer which lets our brave embedded developer once again
concentrate on his very special problem, not on handling neglibilities
like memory management.
But Linux is only half of the story. Besides the kernel, a Linux based
embedded system consists of a "`Userland"': a filesystem, containing all
the small tools which form a small Unix system. Only the combination of
the kernel and a Userland let's the developer run "`normal"' processes
on his x86 development machine as well as on his embedded target.
Whereas the mainstream developers were always able to use normal Linux
distributions like SuSE, RedHat, Mandrake or Debian as a base for their
applications, things are different for embedded systems. Due to the
restricted ressources these systems normally have, distributions had to
be small and should only contain that things which are needed for the
application. Additionally, they had to be auditable and reproducable:
Embedded developers usually want to know what's in their systems -- be
it that they have to support their software for a long time span
(something like 10-15 years are usual product lifetimes in automation
applications) or that they have such a special scenario that they have
to maintain their integrated source of their Userland themselves.
Entering PTXdist.
|
