Embeded Linux

www.elektor-magazine.
com
magazine
Embedded Linux
Made Easy
Part 1: Kickoff
Part 2: Hardware
Part 3: Software Development
Part 4: A Look at the Kernel
Part 5: I/O, ADC, PWM, LAN & Web Server
Part 6: Networks and Servers
Part 7: I2C, Serial Ports and RS485
Personal Download for Fernando Faria Corra | copyright Elektor
MICROCONTROLLERS
Embedded Linux
Made Easy(1)
Part 1: Kickoff
By Benedikt Sauter (Germany)[1]
Today Linux can be found running on all sorts of

devices, even coffee machines. Many electronics
enthusiasts will be keen to use Linux as the basis of a new
microcontroller project, but the apparent complexity of the
operating system and the high price of development boards has been
a hurdle. Here Elektor solves both these problems, with a beginners course
accompanied by a compact and inexpensive circuit board.
There are many introductory courses available for eight-bit microcontrollers, but comparatively little literature and comparatively
few websites address the needs of beginners in embedded Linux. Many descriptions assume too much prior knowledge
or descend too quickly into cryptic source
code, specialist topics or other unwanted
detail. However, Linux is at its heart just a
classical, well-structured and very modular
piece of firmware, and, despite its apparent
complexity, it is possible to understand it in
terms of ordinary microcontroller concepts.
What do we need to take our first steps in
this world? In the early days of computing
and microprocessors it was relatively easy
for an interested user to understand the
hardware, the operating system, the applications, drivers and all other parts of his
machine. The main reason for this is that
there was not the same enormous choice
of components as we enjoy today, and so
it was easier to focus ones efforts on the
components and tools that were available.
Normally people built and operated their
hardware in their own individual way, and
hence it was usually down to the individual
to fix his own bugs and faults. This in turn
demanded an in-depth knowledge of how
the system worked.
This is the approach we will take to understanding Linux in this series of articles. Our
hardware will be a compact board that
includes everything necessary for a modern

embedded project (Figure1): a USB interface, an SD card connection and various
other expansion options. It is also easy to
hook the board up to an Ethernet network,
as we shall see later in the series. The Elektor
Linux board is based on the Gnublin open
source project, which was developed at the
Augsburg University of Applied Sciences for
teaching purposes[2].
There are no specialist components on
the Linux board. The printed circuit board
has two layers and is available from Elektor
ready populated (see Figure2). The second
part of this series will look more closely at
the circuit diagram, but we also show it here
(Figure3) for the sake of completeness. The
hardware is available under the freedomdefined.org/OSHW licence, which means that
the CAD files are also available[3]. Needless to say, the software for this project is
also entirely open source, and is as always
available for download from the Elektor
website[3].
Step by step
Figure4 shows an outline of the roadmap
for this course. The first thing for Linux
beginners to understand is where the most
important applications and software components originate from. These components
form the basis of our Linux system, just as
they do of any PC-based Linux system. We
will also learn how the hardware is constructed and how it operates. And then we
will see how to install a suitable Linux development environment on a PC to compile
our own source code: when installing Linux
on a microcontroller it is much easier if the
host PC development environment is also
running Linux (for compatibility of directory path names if nothing else). Windows
users have the option of installing Linux in
a virtual machine.
By the end of the course we hope you will
have gained a better understanding of how
the Linux operating system works through
practical example applications. Our final
goal will be to construct a simple heating
controller with a graphical display and data
analysis via a browser.
The origins of GNU and Linux

It is important for anyone using Linux seriously to understand why and how the free
GNU/Linux implementation of Unix arose
and how it is organized. This allows better
understanding of where the boundary of
the operating system lies and, most importantly, to work out which piece of software
or hardware might be responsible for a
problem.
Significant development of Unix[4] began
in 1969 at Bell Laboratories in the USA. Ken
Thompson wrote the first version in assembler. To get a better idea of what interfaces
MICROCONTROLLERS
Features of the Elektor Linux board
Elektor Linux Board
For USB hardware
For load switching

As root console
7 - 12 V
DC
Power supply
1.2 V
USB interface
for
peripherals
Relays
Silabs CP2102
USB console
GPIO/AD/
I2C/SPI
IO, AD channels,
I2C and SPI
3.3 V
NXP
LPC3131
Processor
1.8 V
AMIC
DRAM
memory
IO
Wire terminals
Power supply
Pushbuttons
3.3 V output
CLK
Non-volatile
memory
Wire terminals
and drivers would be needed he wrote,

along with Dennis Ritchie, the game Space
Travel. From a microcontroller programmers point of view this approach is easy to
understand: when developing an embedded system it is important to plan from
the beginning how the software (including
hardware drivers and utility functions) will
be structured to maximize the reusability
of the source code. Ken and Dennis soon
worked out which components belonged
in the operating system and how the
whole thing should be organized. Between
1972 and 1974 they re-wrote the heart of
the operating system from scratch using
the C programming language, which had
also been developed at Bell Laboratories.
The operating system, including a C compiler, was distributed to universities free of
charge.
At the end of the 1970s AT&T, the carrier
behind Bell Laboratories, realized that there
was potential to market Unix commercially.
Until that time it was normal for software to
be shared and exchanged freely. Pirating
and other such illegal acts were unheard
of. Software was distributed with the goal of
improving it collaboratively. This underlying
attitude still lies at the heart of the free and
open-source software movement[5],[6].
Once AT&T had started to sell Unix it could
no longer be exchanged freely. Suddenly,
because of the high licence costs, it was
no longer feasible to use it in university
courses or for self-study. At this time more
and more companies started to licence their
own Unix variants: one example is Siemens
SINIX, which has its origins in the Xenix version of Unix from Microsoft.
Richard Stallman, at MIT in the USA[7],
was not happy that Unix was now in general only available to companies. It seemed
that the happy days when Unix was copied and shared between colleagues and
friends were over. There was only one solution: a complete new and free version of the
Unix system had to be developed from the
ground up.
And so GNU[8] (for GNUs not Unix) was
born in 1983. A huge amount of work lay
ahead of Richard Stallman: everything had
to be reimplemented in order to create a
100% free operating system. He would
need:
two-layer board using readily-available components

no special debugging or programming hardware required
fully bootable from an SD memory card
Linux pre-installed
180MHz, 8MB RAM (32MB optional), 64MB swap
integrated USB-to-RS-232 converter for console access
relay, external power supply, and pushbuttons for quick testing
four GPIO pins, 3 A/D channels and a PWM channel on-board
I2C and SPI buses accessible from Linux
USB interface for further expansion
I/O and A/D

channels
Bootloader
MicroSD card
up to 32 GB
120026 - 13
Figure1. The board makes a powerful basis for custom microcontroller projects.
A network interface is also available.
Figure2. The printed circuit board is available from Elektor ready-populated.

3
MICROCONTROLLERS
+1V2
C6
C4
+3V3
+3V3
L3
47n
R13
C13
3n3
4uH7
R6
AS1324
DNP
10u
VOUT/
VFB
SW
SPI_MOSI
B7
B8
M13
M12
M11
N14
F12
E14
G10
TP1 TP2
LPC_RXD
P12
LPC_TXD
N12
N13
TP5
P14
TP6
B9
PWM_DATA
USB_VDDA12-PLL
GPIO3
I2SRX_WS0
GPIO4
SPI_CS_OUTO
MGPIO6
SPI_SCK
MGPIO7
SPI_MISO
MGPIO8
SPI_CS_IN
MGPIO9
SPI_MOSI
MGPIO10
GPIO12
MI2STX_BCK0
GPIO13
MI2STX_WS0
GPIO14
MI2STX_CLK0
GPIO15
I2STX_DATA1
GPIO16
I2STX_BCK1
GPIO17
I2STX_WS1
GPIO18
B6
MUART_RTS_N
ADC10B-GPA1
PWM_DATA
A10
R26
Q2
C30
10k
LPC_MCI_CMD
A5
LPC_MCI_DAT0
B5
LPC_MCI_DAT1
C5
LPC_MCI_DAT2
A4
LPC_MCI_DAT3
J14
GPIO14
J13
GPIO15
GPIO2
GPIO18
H11
GPIO19
SV1
GPA0
A14
GPA1
C14
S3
C11
+3V3
10k
LPC_D10
A1
LPC_D11
C2
LPC_D12
G3
LPC_D13
D3
LPC_D14
E3
LPC_D15
F3
LPC_DQM0
H1
LPC_WE
J2
J1
J3
K1
K2
E6
E7
D4
EBI_D_6
MLCD_DB_6
IC6.B
EBI_D_7
MLCD_DB_7
EBI_D_8
MLCD_DB_8
EBI_D_9
MLCD_DB_9
EBI_D_10
MLCD_DB_10
EBI_D_11
MLCD_DB_11
EBI_D_12
MLCD_DB_12
EBI_D_13
MLCD_DB_13
EBI_D_14
MLCD_DB_14
EBI_D_15
MLCD_DB_15
LPC313XFET180
EBI_DQM_0_NOE
EBI_A_0_ALE
EBI_A_1_CLE
EBI_NWE
EBI_NCAS_BLOUT_0
NAND_NCS_0 EBI_NRAS_BLOUT_1
NAND_NCS_1
NAND_NCS_2
MLCD_RS
NAND_NCS_3
MLCD_RW_WR
MNAND_RYBN0
MLCD_E_RD
MNAND_RYBN1
MLCD_CSB
N6
LPC_A2
P6
LPC_A3
N7
LPC_A4
P7
LPC_A5
K6
LPC_A6
P5
LPC_A7
N5
LPC_A8
L5
LPC_A9
K7
LPC_A10
N4
LPC_A11
K5
LPC_A12
P4
LPC_A13
P3
LPC_A14
N3
LPC_A15
B3
LPC_A0
A2
LPC_A1
G1
LPC_CAS
H2
LPC_RAS
P8
L8
DAT3
CMD
V+
CLK
GND
DAT0
DAT1
SW_A
SW_B
SD-CardSocket
C18
C19
10u
100n
10n
4 GPIO15
10k 10k 10k 10k 10k 10k
L7
L12
C12
+1V2
C2
10u
301k
+1V8
C33
10u
100n
F5
10n
G5
H5
+1V8
10u
M7
C25
100n
M9
10n
+3V3
D7
LPC_CKE
K8
C22
10u
E8
C17
100n
G12
10n
MNAND_RYBN3
L10
VSSA12
LPC313XFET180
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOB
VSSE_IOB
VDDE_IOB
VSSE_IOB
VDDE_IOB
VSSE_IOB
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VSSE_IOC
K11
+3V3
IC6.C
VDDE_IOC
D5
C23
VSSI
VSSE_IOB
C13
LPC_CS
VDDI
VDDE_IOB
M5
C26
VSSI
VSSE_IOA
L4
C27
VSSI
VDDI
VDDA12
E5
C31
VDDI
VDDA12
E10
B2
C32
VSSI
VPP_B
D11
100n
VSSI
VDDI
VPP_A
C9
C38
VDDI
VSSI
A9
R19
VDDE_ESD
A13
VSSE_IOC
ADC10B_GNDA
ADC10B_VDDA33
H7
LPC_A1
H8
LPC_A2
J8
LPC_A3
J7
LPC_A4
J3
LPC_A5
J2
LPC_A6
H3
LPC_A7
H2
LPC_A8
H1
LPC_A9
G3
LPC_A10
H9
LPC_A11
G2
LPC_A15
G1
LPC_A14
G7
LPC_A13
G8
A0
A1
DQ0
DQ1
A2
DQ2
A3
DQ3
IC5
A4
DQ4
A5
DQ5
A6
DQ6
DRAM
A7
A8
DQ7
DQ8
A43E26161
A9
DQ9
A10
DQ10
A11
DQ11
A12
DQ12
BA0
DQ13
BA1
DQ14
DQ15
LPC_DQM0 E8
LPC_DQM1 F1
LPC_CLK
F2
LPC_CKE
F3
LDQM
CAS
UDQM
RAS1
CLK
CKE
+5V
LPC_MCI_DAT2
LPC_MCI_DAT3
LPC_MCI_CMD
4
LPC_MCI_CLK
WE
CS
A8
LPC_D0
VCC
LPC_MCI_DAT0
LPC_MCI_DAT1
LPC_MCI_CD
D+
GND
USB
J3
R9
GPA0
GPA3
4 PWM_DATA
I2C_SCL
D12
G4
L6
L11
E9
C3
C4
E4
F4
H4
K3
M3
M4
M6
M8
B12
D6
D8
D9
G11
L9
L13
A12
LPC_A1
SPI_MOSI
SPI_MISO
B8
LPC_D2
SYSCLK_O 9
10
SPI_SCK
C9
LPC_D3
GPIO14
11
12
GPIO11
C8
LPC_D4
13
14
D9
LPC_D5
D8
LPC_D6
E9
LPC_D7
E1
LPC_D8
D2
LPC_D9
D1
LPC_D10
C2
LPC_D11
C1
LPC_D12
B2
LPC_D13
B1
LPC_D14
A2
LPC_D15
F7
LPC_CAS
F8
LPC_RAS
F9
LPC_WE
G9
LPC_CS
D
D+
GND
47u
4
5
12
11
MINI-USB
REGIN
VBUS
VDD
RI
RST
D+
LPC_VBUS
LED5 270R
13
RTS
SUSPEND
CTS
3
R10
R14
GPIO18
LPC_DP
USB_ID
2
C10
R18
JP1
1M
1M
100n
10k
2
1
28
27
26 LPC_RXD
25 LPC_TXD
24
23
TP7
GND
3
Relay
BSS123
+5V
GND
1
270R
G6D-1A-ASI5VDC
LPC_DM
TXD
SUSPEND
MC78M05ABDT
Q4
270R
X1
K4
BAT54
DSR
RXD
EXP
11
DTR
CD21021
GND
D4
DCD
IC7
D-
+5V
1k
R24
1u
C24
+5V
LED1
R27
C28
+5V
J4
X2
+5V
+5VEXT
+3V3
+3V3
LED2
I2C_SDA
B9
GPA1
R22
K1
D
A11
C7
+3V3
GPA1
C21
C6
N9 LPC_DQM1
U1
DM3D-SF
DAT2
MNAND_RYBN2
R29
1
R25
3 GPIO14
GND
R23
100n
2 GPIO11
3.3V
R30
X4
X7
R20
10k
GPA3
RESET
22p
A3
LPC_A0
R17
R4
J5
B14
+3V3
R16
GND
10R
K14
B13
ADC10B-GPA3
R21
GPIO0
R15
22p
301k
AS1324
H3
LPC_CLK
P9
K13
ADC10B-GPA2
+3V3
150k
K12
RESET
+3V3
VOUT/
VFB
SW
10u
J11
C29
22p
B1
LPC_D9
LPC_MC1_CD B4
12MHz
S1
C1
LPC_D8
GPIO11
J12
UART_TXD
ADC10B-GPA0
A6
H10
GPIO20
MUART_CTS_N
LPC_MCI_CLK
H13
GPIO19
UART_RXD
LED1
C11
GPIO11
MI2STX_DATA0
GPIO2
B11
MGPIO5
+3V3
GPIO15
L14
GPIO2
I2SRX_BCK0
GPIO0
J10
GPIO1
LPC313XFET180
I2SRX_DATA0
IC2
4uH7
C3
C7
VIN
LED1
C8
K10
GPIO0
I2SRX_BCK1
LPC_D7
MLCD_DB_5
N8
J9
SPI_MISO
TP4
I2SRX_DATA1
10k
SYSCLK_O
D2
EBI_D_5
E7
A8
G13
SYSCLK_O
I2SRX_WS1
R7
J1
A7
SPI_SCK
J4
LPC_D6
MLCD_DB_4
A1
TP3
H12
D1
EBI_D_4
D3
P11
CLOCK_OUT
R2
LPC_D5
MLCD_DB_3
VDDE-IOC
N10
10k
BUF_TMS
CLK_256FS_O
I2C_SCL1
D14
+3V3
E2
MLCD_DB_2
EBI_D_3
VSSE-IOC
R1
D13
LPC_D4
EBI_D_2
C7
M10
F11
BUF_TCK
E1
VDDE-IOC
F13
SCAN_TDO
I2C_SDA1
TDO
F10
BUF_TRST_N
I2C_SCL0
TCK
E11
F1
LPC_D3
VSSE-IOC
F14
+3V3
IC6.A
I2C_SDA0
M14
LPC_D2
MLCD_DB_1
E3
G14
ARM_TDO
USB_VSSA_TERM
TDI
TMS
MLCD_DB_0
B3
E13
EBI_D_1
VDDE-IOC
E12
I2C_SCL
TCK
USB_VSSA_REF
USB_GNDA
R3
EN
22p
301k
GND
EBI_D_0
A7
I2C_SDA
TMS
TRST_N
K9
P10
F2
VDDE-IOC
D10
TDI
G2
LPC_D1
VDDE-IOC
C10
P13
TRST_N
USB_RREF
LPC_D0
VSSE-IOC
N1
RSTIN_N
RESET
VSSE-IOC
L3
H14
10k
K4
12k
1%
VOUT/
VFB
AS1324
L2
+1V2
USB_ID
FFAST_OUT
J5
R11
USB_DP
SW
C9
N11
JTAGSEL
B10
M1
USB_ID
USB_DM
R8
+1V2
4u7
VIN
IC1
10u
66k5
L1
M2
P1
P2
USB_VBUS
USB_VDDA33-DRV
LPC_DP
USB_VDDA33
N2
FFAST_IN
L2
LPC_DM
4uH7
C1
GND
2
LPC_VBUS
22p
301k
VSSE-IOC
100n
C12
IC3
D7
10u
C15
L1
EN
C3
C16
4u7
C8
+5V
C5
+1V8
VIN
A9
C14
R5
EN
10k
VDDE-IOC
220p
VSSE-IOC
1n
R12
+3V3
B7
10u
4u7
VDDE-IOC
C36
VSSE-IOC
C35
A3
C37
+3V3
IC8
X6
1
2
DC 7 - 12V
120026 - 11
Figure3. The circuit diagram is surprisingly straightforward for such a powerful board.
4
C20
47u
+5VEXT
MICROCONTROLLERS
a C compiler, linker and assembler (a

toolchain)
a text editor to write source code
an operating system kernel
various utility programs
a root file system for the operating
system
By 1990 all the important parts had been
assembled, with the exception of the operating system kernel. Richard Stallman knew
that it only made sense to start working on
the kernel when a stable text editor and
compiler were in place.
The beginnings of Linux

At around the same time a Finnish student
by the name of Linus Torvalds bought his
first x86 computer and wrote a simple terminal program as an exercise to understand
the computer better[9]. He installed Minix,
a paid-for Unix variant that had been developed by a professor from Amsterdam and
his team (and which is still in use today). As
he worked on his terminal program, Linus
Torvalds saw that it was becoming more
and more like an operating system in itself.
So as to allow compatibility with the widest possible range of existing software
it was clear that the system would have
to be POSIX compliant. POSIX defines a
standard for how a Unix operating system
should appear externally. Fortunately for us,
his local bookshop had the relevant POSIX
documentation: this was probably in the
form of a manual for one of the many other
Unix variants. The main thing was that Linus
Torvalds had the information about how the
system calls were named and with what
arguments they were used.
In 1992 the young developer made his
creation available on the Internet for free
download[10]. He needed a suitable
licence under which to release it, and it
so happened that he had recently heard
Richard Stallman speaking at his university. The GNU GPL (the open source licence
used by the GNU project) was ideal. And
then something happened which had not
been planned: the open source community
quickly realized that Linus Torvalds kernel
was the missing element in Richard Stallmans GNU project! It is worth noting that
Stallman had already started on a free GNU
kernel called Hurd, although this does
Start
History and
background of
GNU/Linux
Overview
of components
(SW and HW)
Bootloader creation /
kernel conversion
Hardware
description
Individual boot
image creation
Network access
USB peripherals
Hardware
commissioning
Development
platform setup
Linux kernel
(overview)
Application
development /
script languages
Demo project:
heating control
Extra options
for the
Elektor Linux Board
End
120026 - 12
Figure4. Road map of our multi-part introduction to embedded Linux.
Elektor Linux Board
PC
Text editor
Text editor
Compiler
Assembler
Linker
Bootloader
Kernel (as image)
Toolchain
RS232
serial console
Kernel (as source text)

File system (as source text)
USB
Shell (Console)
C library (libc)
User
application
File system (as image)
C library (libc)
120026 - 14
Figure5. For software development a PC (running Linux) is used

in conjunction with the target board.
5
MICROCONTROLLERS
The kernel
Figure6. Screenshot of the console in action.
nothing to detract from the importance of

Torvalds contribution.
Now, with the GNU project complemented
by the Linux kernel, a complete free and
open operating system was available for
the first time. Strictly speaking it is best to
refer to the operating system as GNU/Linux,
the Linux part referring to the kernel and
GNU to the rest of the operating system
supplied by the GNU project.
The big picture

After that brief historical digression it is
time to take a look at the overall picture of
what components make up our GNU/Linux
system (see Figure5). In essence little has
changed since the early days: the same
basic elements that were needed then are
needed for the Elektor Linux board today.
For this project we will use several of these
original Linux programs. Others we will
need to give a wider berth, and we will mention the reasons for this later on.
Text editor
Todays developers are accustomed to using
their own particular choice of text editor,
with syntax highlighting, code completion
and built-in API documentation. In order
to make small changes quickly to files on
the Elektor Linux board we need a text editor that can be used over the Linux console
(see below).
There are traditional editors such as vi

(or vim in its more user-friendly form)
and nano that fit the bill perfectly. Both
of these are present in the root file system
(see below) of the Elektor Linux board. Linux
developers often use the same text editor
on their desktop PC, so as to avoid confusion when switching between editors.
Another option is the widespread Emacs
editor, whose reputation some readers may
be familiar with. Emacs was developed by
Richard Stallman as part of the GNU project. It is popular with experienced developers because of the wide range of functions
it provides; however, beginners might be
better off with a more lightweight editor.
Compiler + linker + assembler =

tool chain
In order to run programs on a processor it is
necessary to convert it to the machine code
of the relevant target architecture. The GNU
tool chain includes all the software components needed to convert C into machine
code. It has been designed so that it is relatively straightforward to add a new instruction set, and so, for example, versions are
available for x86, AMD64, AVR, ARM, MIPS,
MSP430 and many other processors. The
Elektor Linux board uses an ARM-compatible microcontroller and so we use the corresponding ARM tool chain. More on this later,
when we come to install it.
The kernel lies at the heart of the operating system. It originates in the source code
written by Linus Torvalds, but since then
some ten thousand kernel developers have
worked on the code. However, Torvalds has
always had the final say on whether changes
and extensions are accepted into the kernel or rejected. Any developer not agreeing
with his decision is of course free to fork
his own version of the kernel, as the whole
thing is open source. To date, however,
there has been no significant forking of the
Linux kernel code. The development of the
software is organized using mailing lists,
and anyone is allowed to join these lists
and make suggestions. These suggestions
will be examined by others and discussed.
With the exception of just a few lines of
code, the kernel is written entirely inC, and
can be simply converted from C to machine
code using the GNU tool chain. We will
see how this is done at a later point in this
series.
File system
Under the Windows operating system it
is clear enough that a users files go in the
directory Documents and Settings, programs are installed in C:\Program Files,
and lower-level operating system files are
kept in the System32 directory under C:\
Windows. Like any other operating system,
Windows has its own structure for organizing its many program and data files. So
naturally we ask how things are arranged
in embedded GNU/Linux systems. Here
the origins do not lie with Linus Torvalds
or Richard Stallman; the common basis for
all Unix and Linux file systems was mostly
developed incrementally as part of POSIX
standardization. The so-called root file
system structure has been further developed by the well-known distributions such
as Debian, SUSE and the like. These distributions each offer the user a complete GNU/
Linux system with applications already
installed, a graphical user interface, and an
up-to-date kernel.
To use Linux on our board we will also need
to set up a root file system. For our situation a fully-featured desktop version of
Linux would be too unwieldy, and a cutdown version of the full system will usu-
MICROCONTROLLERS
Internet Links
[6] http://en.wikipedia.org/wiki/Open_source
[1] sauter@embedded-projects.net
[7] http://en.wikipedia.org/wiki/
Massachusetts_Institute_of_Technology
[2] www.gnublin.org (site in German only)
[8] www.gnu.org
[3] www.elektor.com/120026
[4] http://en.wikipedia.org/wiki/Unix
[5] http://en.wikipedia.org/wiki/Free_software
ally suffice, with a relatively small choice of

programs and libraries. There are speciallywritten programs that can be used to create
custom root file systems; alternatively, all
the mainstream distributions
offer ready-made versions for
ARM processors. More on this
topic later.
[9] 'Rebel Code: Linux and the Open Source Revolution', Glyn
Moody: ISBN 0738206709
[10] www.kernel.org
is loaded at run-time as required by application programs (it is dynamically linked).

This saves memory as a single copy of the
library can serve all running applications.
The standard C library

Applications provide the visible face of any computer or
similar product. The operating
system sits in the background,
driving the hardware, allocating memory, handling communications over the network
or other interfaces and much
else besides. Now, application
writers do not want to spend
their time forever rewriting
functions to read and write
files, manipulate strings and
so on. To the developers rescue comes the standard C
library, in its most popular
form known as libc. Slimmed-down versions of this library are available that are
suitable for embedded systems where computing power and storage are relatively limited compared to desktop PCs.
The standard C library provides the interface between the application and the
kernel. It also includes a number of commonly-wanted utility functions. The library
make a Linux system easier to operate. We

will look at the shell in greater depth later.
When Linux is booted on a desktop PC the
keyboard and screen provide the traditional
root console. (It is usually possible to switch to this console
from the graphical user interface
by pressing control-shift-F1.)
When administering machines
remotely it is common to use a
protocol such as SSH or, where
security is not a consideration,
TELNET, to access the root console over a network connection.
A third option is to access the
console over an RS-232 interface.
A PC with a serial port can be
used at the other end of this connection, running a terminal emulator program such as HyperTerminal or TeraTerm (under Windows) or picocom (under Linux).
What the future holds

The serial console and shell
The console, which can be compared with
the command prompt in Windows, can
be used for entering commands, triggering actions (possibly on a remote machine)
and displaying results. In this way it provides a user interface to the system. Usually
it is used in conjunction with a shell, which
provides many handy extra features that
In the next installment in this

series we will look at how the
hardware (Figure1) is arranged. We will
look closely at the power supply, the microcontroller, the SDRAM device and the various interfaces. On the software side, we will
examine the boot process: thanks to the
pre-installed demonstration software (Figure6) the board is ready for experimentation straight away.
(120026)
Elektor Products and Services

Elektor Linux board, ready built and tested: # 120026-91
All products and downloads are available via the article support
Free software download
page: www.elektor.com/120026
MICROCONTROLLERS
Embedded Linux
made Easy(2)
Hardware
Choosing a suitable microcontroller and
supporting ICs is an essential step at the
beginning of many a project. In this part of our
course we will examine the circuit diagram of
our board and look more closely at the most
important components. We will then boot it for
the first time and study what happens. We shall
see how easy Linux can be!
By Benedikt Sauter[1]
In the first part of this series we looked at
the history of the free GNU/Linux operating
system and its most important elements.
We now want to look at our hardware in
detail: the Elektor Linux board.
The main components

The circuit has deliberately been kept simple: we have included only the most important components. The idea is that any
reader should be able to understand the
system from end to end: from applying
power to launching complex applications.
Running the GNU/Linux operating system
requires the standard components of a
computer architecture: a processor, RAM
(working memory) and ROM (non-volatile
memory): see Figure1. How do these all
work together on our board? When power
is applied a mini-bootloader (roughly the
equivalent of the BIOS in a PC) is started,
which copies the kernel from ROM into
RAM. The kernel is then started: this in turn
also has access to the ROM, from which

it can copy any application into RAM as
needed. We will now look at these components in more detail.
The processor
We start with the processor. It is located
in the center of the board, in a 12mm-by12mm BGA package. The Linux kernel
was originally developed for the x86 architecture, which is rather a different beast
from that of a typical embedded processor. Because of the open way in which the
programmers work and the well-thoughtout structure of the software, however, it
is possible to port the kernel to a range of
different processors. Essential to porting
Linux to a new architecture is the availability of the GNU GCC toolchain[2], which
was briefly described in the first article in
this series. The processor must have a hardware timer and a 32-bit architecture. An
MMU (memory management unit) is not
absolutely necessary, but it does help the
operating system to allow different applications to run stably and independently of
one another. Each application is assigned

its own virtual memory space and does not
have access to the memory of other applications. The project uclinux.org[3] provided
patches (see the text box) to the kernel to
allow use with a processor lacking an MMU.
Recently, however, these patches have been
integrated into the mainline kernel. In any
case, we will take advantage of the MMU in
our LPC3131 processor and will therefore
not need to use these patches.
The LPC3131[4] processor by NXP uses an
ARM9 core (to be precise, an ARM926 running the ARMv5 instruction set). It runs
at 180MHz and has 192Kbytes of internal SRAM; an integrated DRAM controller
allows external memory to be attached. All
the usual microcontroller interfaces, such
as I2C, SPI and a UART, are included. There
are 21 GPIO pins, four analog inputs, an LCD
interface, an I2S audio interface and a highspeed USB (480Mbit/s) interface, which
open up a wide range of application possibilities from within the Linux operating
system. The Elektor Linux board is only double-sided, and so not all the signals can be
Elektor products and services

Elektor Linux board, ready built and tested: 120026-91
Free software download
All products and downloads are available via the web page for this
article: www.elektor.com/120146
EMBEDDED LINUX
Power supply
brought out: however, all of the important

ones are available.
The processor we have chosen is ideal for
an introduction to the world of Linux as it
includes only the absolutely essential facilities and peripherals, falling decidedly in the
low cost and low power categories. Other
ARM9-based microcontrollers might offer a
more comprehensive range of features, but
tend to be correspondingly harder to use.
Nevertheless, once the basics are understood, it is relatively easy to progress to
more complex devices.
USB
Processor
LPC3131
Serial
console
RAM
Nonvolatile
memory
ROM
Figure1. The main components of the Elektor Linux board.
Working memory
The processor itself includes just 192Kbytes
of RAM, which we will need to expand with
external memory to allow us to run the kernel, the other operating system components and applications. The internal RAM is
used only to run the bootloader program.
Once the bootloader has configured the
external memory appropriately (which
includes setting up the timing parameters
on the integrated memory controller and
initializing the memory contents), the internal RAM is only used for speed reasons, for
example as a cache for the operating system or for applications. The external memory takes the form of SDRAM (synchronous
dynamic memory): these are very low-cost
devices offering large storage capacities. A
quick glance at the LPC3131 datasheet[4]
suffices to identify find a suitable IC. We
also discover that the device supports a
16-bit external data bus and a maximum
address range of 128Mbytes. A special feature is support for so-called low-power
SDRAM devices, which are optimized for
current consumption. On our board we use
an 8Mbyte device; a 32Mbyte device can
be substituted if desired. Since the world of
RAMs is standardized by JEDEC[5], a suitable device can be obtained from a wide
choice of manufacturers. In the circuit we
have shown the AMIC A43E26161[6]: this
is a low-power device that needs a 1.8V
supply.
The hard drive

The hard drive of our board is a commonor-garden microSD card (Figure2), as used
these days in practically every digital camera and many mobile phones. The card
essentially consists of a NAND flash memory and a simple controller. Unlike NOR flash
memory, NAND flash is always addressed
by block and sector. Our standard microSD
card has a capacity of 1Gbyte, although
larger cards can of course be used. As well
as being readily available, microSD cards
have the advantage that no special programming equipment is needed for the
board: all programs and data files can simply be copied to the card using an ordinary
card reader connected to a PC.
for the LPC3131, 1.8V for the SDRAM, and

1.2V for the ARM9 core in the processor.
When power is applied the enable signals
of the regulators (pin1 in each case) are
immediately taken high and they immediately start to produce their output voltages.
Some of the more sophisticated ARM-based
processors have rather onerous power
sequencing requirements.
The circuit
We now turn to the circuit diagram (Figure3), starting with the power supply. One
possibility is to power the board using a
USB cable at connector X2. The same connection can be used to talk directly to the
serial console of the Linux system over USB,
the CP2102 (IC7) functioning as a USB-toserial converter.
If the system is being used without a console (for example if the UART interface is
being used for a different purpose) external power can be applied at connector X6.
This allows higher voltages to be applied, as
an MC7805ABDT linear regulator appears
between this source and the regulators for
the processor proper. We suggest using a
DC supply of between 7V and 12V. Jumper
J4 is used to select whether external power
or USB power is used.
The internal 5V rail is taken directly to the
inputs of switching regulators IC1 to IC3.
These have a maximum permissible input
voltage of just 6V. Resistors R4, R6 and R7
determine the output voltages of these
regulators. The voltages we need are 3.3V
Figure2. A microSD card

and an SD card adaptor.
With the board now powered up we can

turn our attention to the LPC3131 in the
circuit diagram. It is device IC6, split up in
the diagram into three parts labeled IC6.A
to IC6.C: splitting the pins of the device into
logical groups like this makes the diagram
easier to understand. Block IC6.A covers all
the important interfaces and I/Os of the
processor; block IC6.B includes the data and
address buses; and block IC6.C contains the
power supply pins.
9
EMBEDDED LINUX
+1V2
C6
C4
+3V3
+3V3
L3
10k
C14
C16
C15
C12
C13
10u
100n
47n
3n3
10u
R13
4uH7
R5
EN
R6
AS1324
M12
M11
N14
F12
E14
G10
TP1 TP2
LPC_RXD
P12
LPC_TXD
N12
N13
TP5
P14
TP6
B9
PWM_DATA
LPC313XFET180
J10
L14
GPIO2
I2SRX_BCK0
GPIO3
I2SRX_WS0
GPIO4
SPI_CS_OUTO
MGPIO6
SPI_SCK
MGPIO7
SPI_MISO
MGPIO8
SPI_CS_IN
MGPIO9
SPI_MOSI
MGPIO10
GPIO12
MI2STX_BCK0
GPIO13
MI2STX_WS0
GPIO14
MI2STX_CLK0
GPIO15
I2STX_DATA1
GPIO16
I2STX_BCK1
GPIO17
I2STX_WS1
GPIO18
B6
MUART_RTS_N
ADC10B-GPA1
PWM_DATA
A10
Q2
C30
10k
LPC_MCI_CMD
A5
LPC_MCI_DAT0
B5
LPC_MCI_DAT1
C5
LPC_MCI_DAT2
J14
GPIO14
J13
GPIO15
GPIO2
GPIO18
H11
GPIO19
SV1
GPA0
A14
GPA1
B13
C14
RESET
S3
C11
100n
10k
A1
LPC_D11
C2
LPC_D12
G3
LPC_D13
D3
LPC_D14
E3
LPC_D15
F3
LPC_DQM0
H1
LPC_WE
J2
J1
J3
K1
K2
E6
E7
D4
MLCD_DB_6
IC6.B
EBI_D_7
MLCD_DB_8
EBI_D_9
MLCD_DB_9
EBI_D_10
MLCD_DB_10
EBI_D_11
MLCD_DB_11
EBI_D_12
MLCD_DB_12
EBI_D_13
MLCD_DB_13
EBI_D_14
MLCD_DB_14
EBI_D_15
MLCD_DB_15
LPC313XFET180
EBI_DQM_0_NOE
EBI_A_0_ALE
EBI_A_1_CLE
EBI_NWE
EBI_NCAS_BLOUT_0
NAND_NCS_1
NAND_NCS_2
MLCD_RS
NAND_NCS_3
MLCD_RW_WR
MNAND_RYBN0
MLCD_E_RD
MNAND_RYBN1
MLCD_CSB
N6
LPC_A2
P6
LPC_A3
N7
LPC_A4
P7
LPC_A5
K6
LPC_A6
P5
LPC_A7
N5
LPC_A8
L5
LPC_A9
K7
LPC_A10
N4
LPC_A11
K5
LPC_A12
P4
LPC_A13
P3
LPC_A14
N3
LPC_A15
B3
LPC_A0
A2
LPC_A1
G1
LPC_CAS
H2
LPC_RAS
P8
DAT3
CMD
V+
CLK
GND
DAT0
DAT1
SW_A
SW_B
SD-CardSocket
3 GPIO14
10k 10k 10k 10k 10k 10k
L8
C18
10u
L7
C19
100n
L12
10n
C12
C6
+1V2
10u
301k
C33
10u
100n
F5
10n
G5
H5
+1V8
10u
M7
C25
100n
M9
10n
+3V3
D7
C23
K8
C22
10u
E8
C17
100n
G12
10n
L10
MNAND_RYBN2
MNAND_RYBN3
VSSA12
LPC313XFET180
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOB
VSSE_IOB
VDDE_IOB
VSSE_IOB
VDDE_IOB
VSSE_IOB
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VSSE_IOC
K11
+3V3
IC6.C
VDDE_IOC
D5
LPC_CKE
VSSI
VSSE_IOB
C13
LPC_CS
VDDI
VDDE_IOB
M5
C26
VSSI
VSSE_IOA
L4
C27
VSSI
VDDI
VDDA12
E5
C31
VDDI
VDDA12
E10
B2
C32
VSSI
VPP_B
D11
100n
VSSI
VDDI
VPP_A
C9
C38
+1V8
VDDI
VSSI
A9
R19
VDDE_ESD
A13
VSSE_IOC
ADC10B_GNDA
ADC10B_VDDA33
LPC_MCI_DAT3
LPC_MCI_CMD
4
LPC_MCI_CLK
LPC_A0
H7
LPC_A1
H8
LPC_A2
J8
LPC_A3
J7
LPC_A4
J3
LPC_A5
J2
LPC_A6
H3
LPC_A7
H2
LPC_A8
H1
LPC_A9
G3
LPC_A10
H9
LPC_A11
G2
LPC_A15
G1
LPC_A14
G7
LPC_A13
G8
A0
A1
A2
DQ0
DQ1
DQ2
A3
DQ3
IC5
A4
DQ4
A5
DQ5
A6
DQ6
DRAM
A7
A8
DQ7
DQ8
A43E26161
A9
DQ9
A10
DQ10
A11
DQ11
A12
DQ12
BA0
DQ13
BA1
DQ14
DQ15
LPC_DQM0 E8
LPC_DQM1 F1
LPC_CLK
F2
LPC_CKE
F3
LDQM
CAS
UDQM
RAS1
CLK
CKE
+5V
WE
CS
VCC
LPC_MCI_DAT0
LPC_MCI_DAT1
LPC_MCI_CD
D+
GND
USB
J3
R9
GPA0
GPA3
4 PWM_DATA
A8
LPC_D0
I2C_SCL
I2C_SDA
B9
LPC_A1
SPI_MOSI
SPI_MISO
B8
LPC_D2
SYSCLK_O 9
10
SPI_SCK
C9
LPC_D3
GPIO14
11
12
GPIO11
C8
LPC_D4
13
14
D9
LPC_D5
D8
LPC_D6
E9
LPC_D7
D12
G4
L6
L11
E9
C3
C4
E4
F4
H4
K3
M3
M4
M6
M8
B12
D6
D8
D9
G11
L9
L13
A12
E1
LPC_D8
D2
LPC_D9
D1
LPC_D10
C2
LPC_D11
C1
LPC_D12
B2
LPC_D13
B1
LPC_D14
A2
LPC_D15
F7
LPC_CAS
F8
LPC_RAS
F9
LPC_WE
G9
LPC_CS
+5V
D
D+
GND
47u
4
5
12
11
MINI-USB
REGIN
VBUS
VDD
RI
RST
D+
LPC_VBUS
LED5 270R
13
RTS
SUSPEND
CTS
GPIO18
LPC_DP
USB_ID
R10
R14
C10
R18
JP1
1M
1M
100n
2
1
28
27
26 LPC_RXD
25 LPC_TXD
24
23
TP7
GND
3
Relay
BSS123
MC78M05ABDT
IC8
X6
+5V
GND
10k
270R
Q4
LPC_DM
TXD
SUSPEND
G6D-1A-ASI5VDC
270R
X1
K4
BAT54
DSR
RXD
EXP
11
DTR
CD2102
GND
D4
DCD
IC7
D-
+5V
1k
R24
1u
+5V
C24
X2
+5V
LED1
R27
C28
J4
+3V3
LED2
+5VEXT
+3V3
GPA1
R22
K1
D
A11
C7
+3V3
LPC_MCI_DAT2
C21
N9 LPC_DQM1
U1
DM3D-SF
DAT2
C2
GND
H3
LPC_CLK
P9
MLCD_DB_7
EBI_D_8
R29
LPC_D10
GPA1
4 GPIO15
R25
2 GPIO11
+3V3
R23
X4
GND
R30
R20
10k
GPA3
10k
3.3V
R4
J5
B14
R17
R16
22p
301k
AS1324
10R
K14
+3V3
X7
R21
GPIO0
R15
VOUT/
VFB
SW
10u
150k
C7
VIN
IC2
4uH7
C3
K13
ADC10B-GPA3
+3V3
R7
K12
RESET
+3V3
301k
J11
ADC10B-GPA2
22p
A3
LPC_MC1_CD B4
J12
C29
22p
LPC_D9
GPIO11
12MHz
S1
B1
LPC_MCI_DAT3
H10
UART_TXD
ADC10B-GPA0
A6
A4
GPIO20
MUART_CTS_N
LPC_MCI_CLK
H13
GPIO19
UART_RXD
LED1
C11
GPIO11
MI2STX_DATA0
GPIO2
B11
MGPIO5
R26
GPIO15
L1
M2
GPIO1
+3V3
22p
R3
EN
LED1
M13
I2SRX_WS1
GPIO0
C1
LPC_D8
MLCD_DB_5
EBI_D_6
N8
J9
B7
GPIO0
K10
LPC_D7
EBI_D_5
E7
SPI_MOSI
I2SRX_BCK1
I2SRX_DATA0
J1
B8
I2SRX_DATA1
D2
D3
C8
SYSCLK_O
10k
SYSCLK_O
LPC_D6
MLCD_DB_4
VDDE-IOC
SPI_MISO
TP4
G13
D1
EBI_D_4
VSSE-IOC
A8
J4
LPC_D5
MLCD_DB_3
C7
A7
SPI_SCK
CLOCK_OUT
H12
E2
MLCD_DB_2
EBI_D_3
A1
TP3
I2C_SCL1
D14
R2
LPC_D4
EBI_D_2
VDDE-IOC
P11
CLK_256FS_O
+3V3
E1
VSSE-IOC
N10
10k
D13
F1
LPC_D3
MLCD_DB_1
E3
M10
R1
BUF_TMS
I2C_SDA1
TDO
F11
BUF_TCK
I2C_SCL0
E11
F10
SCAN_TDO
BUF_TRST_N
I2C_SDA0
TCK
LPC_D2
MLCD_DB_0
B3
F13
AS1324
2
EBI_D_1
VDDE-IOC
+3V3
IC6.A
USB_GNDA
VOUT/
VFB
L2
GND
EBI_D_0
VSSE-IOC
F14
ARM_TDO
USB_VSSA_TERM
M14
F2
D7
G14
TCK
USB_VSSA_REF
TDI
TMS
G2
LPC_D1
C3
E13
TMS
K9
P10
LPC_D0
A9
E12
I2C_SCL
TDI
TRST_N
A7
D10
I2C_SDA
TRST_N
USB_RREF
RESET
P13
VDDE-IOC
N1
C10
USB_ID
H14
VDDE-IOC
L3
RSTIN_N
VSSE-IOC
12k
1%
SW
10u
66k5
VSSE-IOC
K4
USB_DP
FFAST_OUT
J5
R11
USB_DM
C1
GND
IC1
C9
VIN
N11
JTAGSEL
B10
M1
4uH7
R8
+1V2
4u7
+1V2
USB_VDDA12-PLL
P1
P2
USB_ID
USB_VDDA33-DRV
N2
LPC_DP
USB_VDDA33
LPC_DM
USB_VBUS
FFAST_IN
L2
22p
301k
VOUT/
VFB
LPC_VBUS
L1
EN
IC3
SW
DNP
4u7
C8
+5V
C5
+1V8
VIN
VDDE-IOC
220p
VSSE-IOC
1n
R12
+3V3
B7
10u
4u7
VDDE-IOC
C36
VSSE-IOC
C35
A3
C37
+3V3
1
2
DC 7 - 12V
120146 - 13
Figure3. Circuit diagram of the Elektor Linux board.

10
C20
47u
+5VEXT
EMBEDDED LINUX
For example, it is possible to boot from the

SD card or over the USB-to-serial bridge at
X2 mentioned above. A further possibility is
to boot over the second USB interface at X1
(see below), for which a DFU (device firmware update) programmer is needed.
LED1 lights when power is present on the
board; also, for simple experiments or as a
status indicator we have LED2. Button S1
can be used as an input device: its state can
be polled on GPIO15. We have also provided
a relay to control external equipment via X1.
We will look in more detail at this possibility
later in the series.
The overall current consumption of the
board is around 85mA to 100mA, which
corresponds to a power consumption of
around half a watt.
Interfaces
Things really start to get interesting when
we use Linux to access directly the various
microcontroller-style interfaces provided by
the processor, including digital inputs and
outputs, PWM, I2C and SPI. The relevant
pins are brought out to 14-way header J5
and connector X4.
GPIO
The 3.3V-compatible inputs and outputs
GPIO11, GPIO14 and GPIO15 are available on screw terminals at X4. GPIO14 and
GPIO11 are simultaneously available on the
14-way header J5.
A/D channels
Three of the four channels are made available for simple analog measurements. The
3.3V supply is used as a reference voltage.
GPA0, GPA1 and GPA3 are available on J5,
with GPA1 also being available on a screw
terminal.
SPI
SPI peripherals can be controlled in exactly
the same way as I2C devices. The MOSI,
MISO and SCK signals are available on J5,
while the chip select signal OUT0 and (in
the case where the LPC3131 is operating as
an SPI slave) the CS_IN signal are available
on test points TP3 and TP4.
PWM
A PWM output is ideal for driving a servo
or for generating an analog voltage. The
LPC3131 has a hardware PWM output, and
the corresponding pin is brought out to J5.
UART
The UART protocol is a particularly convenient way to implement simple communications, especially between two microcontrollers. Unfortunately the processor has
only one UART, which in the normal configuration is used for the root console. If we
subsequently add a network interface (see
below) then it is possible to run the root
console over this interface as well, freeing
up the UART for other applications. The RX
and TX signals are available at test points
TP1 and TP2.
USB
The USB interface at K1 opens up a wide
range of expansion possibilities for the
Elektor Linux board. Not only do there
already exist Linux drivers for a wide range
of USB devices (including audio and video
interfaces, 3G modems, wireless LAN, wired
LAN and so on), but also many simple 8-bit
microcontrollers can these days be controlled over USB. A semi-autonomous controller or coprocessor of this kind makes an
ideal extension to the Linux system.
Network
It is also possible to implement a network
connection, either to a wired LAN or a wireless LAN, using USB connector K1. This
UART
6
DFU
6
J2:Boot
SD/MMC
J2:Boot
I2C
The LPC3131 can act as an I2C bus master or
bus slave. In our case the most likely option
is master: this gives us an easy way to control external devices, such as a PCA9555
I/O expander). The SDA and SCL signals are
available on J5.
J2:Boot
In the bottom left-hand corner of the circuit

diagram is U1, the SD card socket. Normally
this will hold an SD card from which the
Linux system firmware will be loaded. The
LPC3131 is in fact capable of booting from
a range of storage devices and interfaces.
The options available on the Elektor Linux
board can be chosen from using header SV1
(see Figure4).
6
1
Figure4. Bootloader jumper.
interface can be operated in host mode

or in device mode (USB OTG, or on-thego). In host mode any USB stick LAN or
WLAN adaptor can simply be plugged into
the socket. In device mode the Linux board
plays the role of a USB device, for example
behaving as a virtual USB network interface.
We will of course describe later how this all
works.
Das Boot
Before we boot the board for the first time
let us take a quick look at what happens
during the boot process. In order to see
what is happening on the board, we need
to connect it to a computer over USB and
use a serial terminal program. Under Windows suitable options are Tera Term and
HyperTerminal; if a Linux PC is available,
you can use picocom, microcom or a similar program.
Using a standard Ubuntu system, at the
Linux PC console type
sudo apt-get install picocom
and then
picocom -b 115200 /dev/ttyUSB0
to connect to the Elektor Linux board.
Under Windows things are (of course) different. The VCP driver for the USB-to-serial
converter has to be installed manually[7].
Using Tera Term[8] or HyperTerminal it is
then possible to select the newly-created
COM port. The settings are shown in the
screenshot in Figure5.
Once the correct interface is selected the
output from the bootloader and from the
kernel should be visible in the terminal program on the PC.
11
EMBEDDED LINUX
If the boot process is already complete, simply press the reset button (RST) to repeat
the process. Figure6 illustrates what happens during booting.
Figure5. Tera Term terminal program.
Boot loader
is copied from SD card
into SRAM
from LPC3131
Power
ON
KernelExtract
Figure7. The APEX bootloader.
Boot loader
initialises
SDRAM
Boot loader
copies kernel image
into SDRAM
RAM
Init
Bootloader
Optional
checksum
extraction
KernelBoot
Kernel
boots
Initialisation
of HW
Boot loader
invokes
kernel
Jump
Kernel
Kernel
ready
Mount
root file
system
Invoke
Kernel
ready
/sbin/init
Optional:
invoke
root console
A power-on reset interrupt is triggered.

The internal bootloader in the LPC3131
looks for the bootloader firmware and
copies it into internal RAM. Where the
bootloader looks depends on the setting
of the bootloader jumper: in our case we
arrange for it to look on the SD card.
The firmware that has been loaded into
the internal RAM is launched.
The firmware (the APEX bootloader)
initializes the external SDRAM and copies the kernel from the SD card into the
SDRAM (see Figure7).
The firmware calls the kernel.
The kernel unpacks itself and then automatically starts up (Figure8).
The kernel initializes the hardware
(including the UART for the root
console).
During the boot process the kernel
mounts the root file system (which is
stored on the SD card).
The kernel launches the first process, /
sbin/init.
The kernel starts the root console on the
UART interface.
Shell
Figure6. The boot process.
The system now waits at the login prompt

(Figure9) for input. You can log in as the
root user: simply type root and press the
Enter key.
You can now try some simple experiments
using the commands that we have listed in
Table1. For example, you can create a test
file and edit it. It is equally easy to create a
new directory. With a little practice using
the file system will become second nature.
As a very simple taste of what is possible,
we will show how to switch the red LED on
the board on and off. To do this we exploit
a fundamental principle of Unix operating
systems: everything is a file! Every device is
represented in the file system as a file, which
can be read from and written to. This even
applies to our LED!
First enter the following commands.
Figure8. Messages from the Linux kernel

during boot.
Figure9. The login prompt.

cd /sys/class/gpio
12
EMBEDDED LINUX
Source code terminology

Patch
Mainline
A patch is a file that can be used to make

changes to original source code with the
help of a suitable utility program. If, for
example, you make an extension to a program, you can use a utility to determine the
differences between your new version and
the original and generate a patch file to represent them.
Members of a development team can also
use patches to help ensure that they are all
working with the same version of the source
code. Patch files form the backbone of open
source development, where all large-scale
projects are worked on simultaneously by
many developers.
The development of large-scale open source

projects is organized in various ways. In general there is a single maintainer who looks
after the source code, applies patches from
other developers, and regularly releases
new versions of the software to users. In the
case of the Linux kernel there is the so-called
mainline, which is maintained by Linus Torvalds and his team.
Since there is an enormous number of
patches being offered to extend the kernel it
often takes some time before a new feature
will appear in the mainline. Before this point
it is possible to obtain patch files directly
from their developers (for example via their
echo 3 > export
home pages) and apply the patches to the

kernel yourself. The aim, however, is to get
everything into the mainline.
Maintainer
The maintainer is usually a single person
(often the founder of the project). He or she
looks after the master version of the source
code, applies patches, and regularly releases
new versions of the source code. In the case
of Linux the various subsystems such as
network, drivers, file system and so on each
have their own maintainer, who is responsible for the source code and who helps ensure its stability and availability.
easy as we can for readers by providing a

ready-made image for download, which can
be used in a virtual machine.
cd gpio3
(120146)
echo out > direction

These configure the relevant port pin as an
output. Then enter
echo 1 > value
[3] www.uclinux.org
[4] http://ics.nxp.com/products/lpc3000/
datasheet/lpc3130.lpc3131.pdf
[5] http://www.jedec.org
[6] www.amictechnology.com/pdf/
A43E26161.pdf
Internet Links
[7] www.silabs.com/products/mcu/Pages/
USBtoUARTBridgeVCPDrivers.aspx
[2] http://gcc.gnu.org
[8] http://ttssh2.sourceforge.jp
to switch the LED on, and

Table1: Important Linux commands
echo 0 > value

to switch it off again. See how simple Linux
can be?
Before we finish, we should explain how to
power the board down safely (like a PC). As
Table1 shows, the relevant command is
called halt. As soon as the system replies
with the message System halted.
power can be removed.

In the next article in this series we will
download some source code for the first
time and write a small program. A somewhat longer part of the course will cover the
installation of a development environment.
Here too, however, we will make things as
Command
Description
ps ax
Display all processes
free
Show memory use
date
Show current time and date
touch test.xt
Create empty file called test.txt
rm test.txt
Delete file test.txt
nano test.txt
Open file test.txt in an editor (use control-O to write the

file, control-X to leave the editor)
df
Show partitions
mkdir test
Create a directory called test
cd test
Descend into the directory called test
cd ..
Move one level up in the directory structure
rmdir test
Delete the directory test
cat /proc/cpuinfo
Display the contents of the file /proc/cpuinfo
halt
Bring Linux system to an orderly halt
13
MICROCONTROLLERS
Embedded Linux
Made Easy(3)
Software development
It takes the right software to bring a

microcontroller to life. Beyond the usual
firmware, in an embedded GNU/Linux system
we have to deal with building the components of the
operating system. In this article we show how it all works,
and even write our first program inC!
It is easiest to develop for an embedded Linux system with the help
shown in Figure10.
of a conventional Linux system, normally running on a PC. We will
An alternative (and potentially more
base our experiments on version 12.04 of the Ubuntu[2] distribuconvenient) approach is to run the operattion. What do we need to install such a system? Not a lot: a little free
ing system in a virtual machine. The author has prepared an image
space on the hard disk and, ideally, a network connection.
of a Linux computer set up for development especially for Elektor
The first thing to do is download the image of the installation CD
readers, and it can be downloaded from the Elektor website[3]. The
from the internet[2]. We can use either the 32-bit or the 64-bit
virtualization program VirtualBox is needed to run the image: it
desktop variants: if in doubt, select the 32-bit variant.
can be downloaded free of charge at[4]. When VirtualBox has been
Once the CD image is downloaded it has to be burned onto a CD
installed, the image is loaded by simply selecting File> Import
using a suitable program. It is important to burn the file to the disk
Appliance from the main menu; it can then be run immediately.
as an image rather than copying it as a simple file.
Now insert your newly-burned CD into the PC and boot from it
Toolchain on CD
(which may require some adjustments to your BIOS settings).
With the new operating system running the next step is to install
Ubuntu starts up with the splash screen shown in Figure1. To
the toolchain. If you are using the VirtualBox image this has all
make the system more convenient to use will we install it to the
already been done for you, and you can skip the next two sections.
hard disk, by selecting the second menu option (see Figure2). You
will now be guided step-by-step through the installation process.
The quickest way to do things in Linux is usually to use the console.
First choose your language (Figure3). We do not need to install
Simply open up a new terminal window on the PC by pressing Conany third-party software (Figure4). The
next window, shown in Figure5, lets you
choose to let Linux occupy the whole hard
disk (which would be suitable for a machine
that does not already have another operating system installed); alternatively, you can
install Linux to a second hard disk, or partition the main hard disk into two areas, one
area retaining the already-installed operating system and the other dedicated to the
new installation. In Figure6 you select the
drive or partition that will be used, and then
proceed as shown in Figure7 and Figure8.
We will explain more about the password
Figure1. Use down-arrow to select the
Figure2. Select Install Ubuntu
that you are asked to set (Figure9) later.
second menu item.
and press Enter.
If all goes well, you should reach the point
14
EMBEDDED LINUX MADE EASY
Figure3. Choosing your language.
Figure4. Preparing for installation.
Figure5. Choosing where the operating

system will be installed.
trol-Alt-T. In the terminal, switch to the directory /tmp

cd /tmp
and then download the ARM toolchain CD directly using the wget command thus:
wget ftp://ftp.denx.de/pub/eldk/5.0/iso/armv5te-qte-5.0.iso
This will download a CD image. The image can be opened directly using Linux: there is no
need actually to burn the file to a CD. However, the file does need to be mounted, which
makes it visible as a set of files to the operating system. First switch to the directory /
media:
Figure6. Selecting the hard disk.
cd /media
In theory you can mount the contents of the CD image wherever you like in the file system,
but there are certain conventions in the Linux world that make it easier for people to find
their way around a new system. We will look in more detail later at the standard arrangement of the file system.
We now want to create a new empty directory called eldk-iso, where we will subsequently
mount the CD image. Although this might seem odd to someone familiar with Windows,
we are not going to copy the files from the CD image to the new directory: instead, the new
directory just marks the place in the file system from which the contents of the CD are made
accessible. In Linux, everything is handled through files and directories.
Here is the command to create the new directory:
sudo mkdir eldk-iso
Figure7. Selecting the time zone.
The machine will prompt you for a password, as creating the directory requires you
Figure8. Selecting the keyboard layout.
Figure9. Entering a user name and

password.
Figure10. The installation process begins.
15
MICROCONTROLLERS
Permissions and privileges

A Linux system always has a user called
root. This user has the highest level of
privileges on the system: other users typically only have ordinary privilege levels.
Full access to system files, devices and so
on requires root privileges. One approach
is simply to execute all commands as the
user root but this is not advisable. One of
the reasons Linux is so secure is that the
restrictions on what ordinary users can do
prevent a lot of potential damage. Users are
normally only given permission to run the
programs they need, not to access system
files or other important information.
The Linux programmer can, however, grant

any application a higher level of privileges as
needed, and so there is no need to execute
all commands as the user root. We will
also create a new user account on our Linux
board for carrying out ordinary tasks and
running the programs we write.
If a user briefly requires root privileges,
for example to create a directory within a
system directory, then we can use the command sudo provided in most modern Linux
distributions (including the version of Ubun-
(briefly) to have root privileges: see the text box Permissions and
privileges. To make this happen, we have prefixed the normal command with sudo, which asks the user for the password that was
configured when the system was installed. If you are using the VirtualBox image, the password is elektor, entirely in lower-case.
tu we are using) as a prefix to the command

proper. This indicates that the command is
to be run as if by the root user.
You will be prompted for a password. If you
have installed the Linux system on the PC
yourself, you will have set up this password
as part of the installation process; if you are
using the VirtualBox image, the password is
elektor, entirely in lower-case.
This step is important, as the next thing we will do is unmount the

CD image. This will not work if you are currently in a directory within
the image: the operating system will refuse to execute the command and an error message will be printed.
sudo umount /media/eldk-iso
The CD image can now be mounted in the file system to allow us to

access its contents:
sudo mount -o loop /tmp/armv5te-qte-5.0.iso /media/
eldk-iso
From our current position in the file system we can change directory
into the CD image by typing:
cd eldk-iso
Installing the toolchain

In the directory you will find a small script that you can use to
install the toolchain. Again, you need root privileges to install new
programs:
The directory you created for the toolchain CD can now be deleted.
sudo rmdir eldk-iso/
When installation is complete the toolchain will be located in the
directory /opt/eldk-5.0/. So that we can access the programs in
the toolchain using the command line from whichever directory
you happen to be in, we have to add this directory to the PATH variable. This is a Linux environment variable which contains a list of
directories in which the system will automatically look for programs
to execute.
The best approach is to write a small script file (call it set.ch) which
you can run from the console before using the toolchain. Create a
new file using the editor:
gedit set.sh
sudo ./install.sh -s -i qte armv5te

and add the following lines to it:
The following message should appear:
#!/bin/bash
*** Installing ./targets/armv5te/eldk-eglibc-i686arm-toolchain-qte-5.0.tar.bz2
When installation is complete you can leave the CD directory:
P1=/opt/eldk-5.0/armv5te/sysroots/i686-oesdk-linux/
usr/bin/armv5te-linux-gnueabi/
P2=/opt/eldk-5.0/armv5te/sysroots/i686-oesdk-linux/
bin/armv5te-linux-gnueabi/
cd ..
16
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabiexport PATH=$P1:$P2:$PATH
Save it and leave the editor. Now we are back in the console. To
compile the program, type:
arm-linux-gnueabi-gcc -o hello hello.c
The last command here adds the path mentioned above to the PATH
variable.
Then write the new file to your start-up directory (called the home
directory). For the commands in the file to take effect, you have
to cause the shell (the Linux command line interpreter) to read
them in (or source them). One way to do this is with the following command:
. ./set.sh
Type this carefully: the line starts full stop, space, full stop!
If you would prefer not to have to type this command every time
you bring up a new console you can include it in the file .bashrc,
which is automatically executed whenever the shell starts up. The
file is located in your home directory, which you can switch to using
the command cd without any arguments. You can edit the file using
the command:
gedit .bashrc
To test whether the above process has been successful, we can copy
the file hello that the compiler has created to the Elektor Linux
boards SD card. Make sure the board is off and remove the card.
Insert it into the PCs card reader, and plug the reader into the PC.
Wait a few seconds for the machine to detect the card. Normally
Ubuntu will automatically pop up a window when this happens:
since we will be copying to the card using the console, we can close
this window.
Full-scale operating systems such as Ubuntu automatically mount
external storage devices when they are plugged in. We therefore
need to find where Ubuntu has decided to mount the SD card. It is
easiest to switch to the directory /media:
cd /media
and then type
ls
The compiler in action

The toolchain programs that we will use to build the Linux kernel and the bootloader all have names that begin with armv5te-.
For example, the GCC compiler is called armv5te-gcc. Typing the
command
armv5te-gcc --version
will give the version number of the compiler (note that there are
two dashes before version). If this command works, it means that
you have successfully set up the path to the toolchain programs.
To compile application programs for Linux we need to use the toolchain commands that start arm-linux-gnueabi- rather than armv5te-. So how do we compile a simple hello world program?
(for list) to display a list of files and directories within this directory.
If there is more than one subdirectory, you can type
cd directory-name
to switch to a given directory, look inside using ls, and then cd ..
to move back up one directory level into /media. The name of the
directory where the SD card is mounted will typically consist of a
long string of digits. The directory will contain the complete file
system of the Linux board, including files with names such as zImage and swapfile1.
If you get lost in the file system, you can always return to your home
directory using the command cd without any arguments. Another
handy command is pwd, which will tell you the path to your current directory.
First create a source file
Hello world!
gedit hello.c
To test the hello world program, switch to the directory where the
SD card is mounted and copy the file across:
with contents as follows:

#include <stdio.h>
cp ~/hello ./
int main(void)
{
printf(Hello world!\r\n);
return 0;
}
Then we have to unmount the directory manually so that the operating system is forced to finish writing all the data to the card.
cd
sudo umount /media/directory-name
17
MICROCONTROLLERS
First aid for a sick SD card

If a system that has been booted from an SD card is not powered
down properly, using the halt or poweroff commands, it is possible that the file system on the card will be corrupted. This typically
results in EXT2-fs errors:
Filesystem EXT2-fs (mmcblk0p1): error: ext2_lookup:

deleted inode referenced: 694962:
Fortunately we can usually rescue the file system using a Linux PC from the console.
First put the SD card into the card reader and use dmesg to determine what name it has been assigned. For example, if you see the following
[
[
[
[
[
1549.424156]
1549.425624]
1549.427527]
1549.427533]
1549.730223]
sd 7:0:0:2: [sdh] Assuming drive cache: write through

sdh: sdh1 sdh2
sd 7:0:0:2: [sdh] Assuming drive cache: write through
sd 7:0:0:2: [sdh] Attached SCSI removable disk
EXT2-fs (sdh1): warning: mounting unchecked fs, running e2fsck is recommended
it means that the first partition, which is the one we are interested in, has been given the name sdh1. This contains a file system in ext2 format, which it is possible to repair. We have to unmount the file system
umount /dev/sdh1
before we can use the tool e2fsck (or equivalently fsck.ext2) to attempt the repair:
sudo e2fsck /dev/sdh1

The result should be as shown in the screenshot. From time to time the program will ask if certain actions should be carried out: you should
normally answer y. The result should be an error-free SD card!
Here again directory-name should be replaced by the name of the

directory that the operating system chose when the SD card was
mounted.
We can now move the SD card back to the Linux board and start it
up. Connect to the board using a terminal emulator on the PC, as
described in the previous installment in this series[5].
The result should be that Hello World! appears in the terminal window (see Figure11).
If the system is booted from the SD card, it is important to shut the
system down in an orderly fashion when you have finished. For this
we need the command
halt
Now, on the board, we switch to the top-level directory in the file

system using the terminal emulator:
cd /
and run the program:
It is then necessary to wait until the message System halted

appears before it is safe to remove power: otherwise it is possible
that not all files will be updated properly on the SD card. This can in
turn result in EXT2-fs errors. It is normally possible to recover the
situation using a Linux PC: see the text box.
./hello
18
Bootloader and kernel

We shall now look at how we can build the two main components
of the operating system, the bootloader and the kernel.
The source code we need (290MB for the current version) is available from the Elektor website[3]. The simplest approach is to download the files using a browser: on a Linux machine the files will normally end up in the Downloads directory.
Figure11. Hello world running on the board.
When the download is complete, switch to the directory Downloads and find the file called 120026-11.zip. Move the file into
your home directory using the command
mv ~/Downloads/120026-11.zip ~/
To unpack the file, switch back to your home directory using cd and
enter the command
unzip 120026-11.zip
mv apex-1.6.8 work_1.6.8
cd work_1.6.8
In the source code tree we need to apply a couple of patches that are
required to make the bootloader work with the Elektor Linux board.
patch -p1 < ../apex-1.6.8_lpc313x.patch
patch -p1 < ../gnublin-apex-1.6.8.patch
Figure12 shows what you should see on the console.
Building the bootloader

The bootloader is a program which is copied from the SD card to the
internal SRAM of the LPC3131 on system reset (assuming the jumpers are set correctly: see [5]). The following sequence of commands
shows how we can compile the bootloader for ourselves and copy it
to the SD card, to allow us to boot from the card. Before starting we
need to install a couple of packages on the Ubuntu system:
sudo apt-get install patch libncurses5-dev
The build process for the bootloader is controlled by what is called

a configuration file. We have to copy the master version of this file
into our directory, with the new name .config. Note that here the
full stop before the word config is very important: it marks the file
as hidden to the operating system.
cp ../gnublin-apex-1.6.8.config .config
At this point, if you installed the toolchain manually and did not
arrange for the environment variables to be set in your .bashrc file,
you will need to set them by running the script . ~/set.sh .
Now switch to the source code directory

The build process can now be initiated:
cd
ElektorLinuxBoardDownload_20120509
make apex.bin
unpack the tar file that contains the bootloader

tar xvzf bootloader.tar.gz
then switch to the new bootloader directory
cd bootloader
and unpack the source code proper:
tar xvzf apex-1.6.8.tar.gz
Now comes an important step if we want to be able to distribute any
changes we make to the bootloader. We create a so-called working copy of the source code and make changes only on that copy.
Later it will be easy to create and publish a patch that represents
the changes we have made.
Normally at this point we would need to copy the bootloader firmware into flash memory on the microcontroller using a suitable programmer. Here, however, we can copy the firmware to the SD card
using ordinary Linux commands.
With the SD card once again in the PCs card reader, run the
command
dmesg
to see the messages output by the kernel running on the PC. The
results obtained on the authors PC are shown in Figure13. As you
can see, the SD card has been recognized as /dev/sdh and contains
two partitions, called /dev/sdh1 and /dev/sdh2. For safety it is
best to unmount these partitions, as we will be copying the bootloader across by accessing the blocks on the SD card directly rather
than via a file system:
19
MICROCONTROLLERS
sudo umount /dev/sdh1

sudo umount /dev/sdh2
The following command (where the sdh2 will need to be modified
to reflect the results from the dmesg command above) will copy the
file apex.bin to the SD card in such a way that the LPC3131 can find
it when booting:
sudo dd if=src/arch-arm/rom/apex.bin of=/dev/sdh2
bs=512
The command copies the bootloader code to the beginning of the
second partition of /dev/sdh using a block size of 512bytes. The
Linux operating system does not guarantee exactly when the new
blocks of data are actually written to the NAND storage on the SD
card. The command
dure is much the same as for the bootloader above, with the appropriate changes. Dont forget to unmount the partition!
A look at the possibilities

Now we are in the happy position of being able to rebuild the bootloader and kernel at will, we can look at the possibilities for making
modifications to them, in particular to the kernel. Of course, we only
have space here to look at this in general terms. You can take a first
look at the Linux kernel configuration by typing
make menuconfig
from the directory linux-2.6.33-lpc3131x. The result is shown in
Figure14. If, for example, you want to use a particular USB device
with the Linux board, you have to enable to corresponding driver
here.
sync
is therefore needed to force the operating system to ensure that all
pending blocks are written out and that the new bootloader code
is safely stored on the SD card. We can now try to boot the Linux
board from the SD card.
Restoring the boot image
Building the kernel

Building the kernel is a similar process to building the bootloader.
First we switch to the home directory using the command cd, and
then into the source code directory.
cd
You can navigate around the blue window using the arrow keys.
The Enter key opens and closes the menu. With a bit of hunting
around you will be able to find drivers for various devices you recognize. In the next article in this series we will go into this subject
in more detail.
ElektorLinuxBoardDownload_20120509
We unpack the kernel source code
Since we are now beginning to get down to the nitty-gritty of how

the Elektor Linux board works, it is a good idea to make an exact
copy of the SD card for backup purposes.
Put the card in the PCs card reader and then check, using dmesg,
what device name the operating system has chosen for it.
Again, for safety, unmount the partitions:
umount /dev/sdletter1
umount /dev/sdletter2
tar xvzf linux-2.6.33-lpc313x-gnublin-032012.tar.gz

switch to the kernel source directory
(where you should insert the appropriate character for letter, for
example giving /dev/sdb1 and /dev/sdb2 or /dev/sdh1 and /
dev/sdh2).
cd linux-2.6.33-lpc3131x
You can now take an exact copy of the cards contents:
and start the build process that will result in a bootable kernel.
make zImage
We also need to compile the loadable kernel modules. The is simply
done using the command:
sudo dd if=/dev/sdletter of=Image_SD_card_backup_

copy.img
This will take some time. You should now find a file in your current
directory whose size is exactly equal to the capacity of the SD card:
make modules
ls -lh
With everything built we need to copy the kernel and the modules
to the SD card. In our case the kernel zImage happens to be there
already, but it is worth practising the process for replacing the kernel. We need to copy the file arch/arm/boot/zImage in the kernel
source tree directly to the first partition on the SD card: the proce-
You now need to put another SD card, exactly the same size as the
original, in the PCs card reader. Again, find out the device name
using dmesg. The following command will copy the card image you
have just created onto the new card:
20
sudo dd if=Image_SD_card_backup_copy.img of=/dev/

sdletter
This will take even longer than reading the original card. Assuming
the command is successful you can now issue the sync command to
ensure all blocks are actually written out to the card, and then try
the new card in the Elektor Linux board. There is no need to unmount
the card as the file system on the card was never mounted in the
first place: we wrote blocks directly to the card.
The above process is fairly straightforward, but unfortunately it
does not work if the sizes of the two cards are not identical. Also,
we sometimes want to create a new card with different partitions
or with a different file system from those of the original card. These
cases are handled by a graphical installer, which we shall look at
briefly in the next article in this series.
Figure12. Messages that appear

when unpacking the software download.
Figure13. The messages from the kernel show

that the SD card has been assigned to /dev/sdh.

In this installment we have made good progress on the route to
understanding our embedded GNU/Linux system. We have a development environment in place, we can now build our own bootloader and kernel, and we have compiled and run a small program.
In the next article we will take a quick look at the structure of the
source code for Linux so that we can be in a position to write our
own driver for a particular piece of hardware. We will also see how
easy it is to write programs using scripting languages.
(120180)
Figure14. Configuring the Linux kernel.
Internet links
[1]sauter@embedded-projects.net
[4]http://www.virtualbox.org
[2]http://www.ubuntu.com
[5]http://www.elektor.com/120146
[3]http://www.elektor.com/120180
21
MICROCONTROLLERS
Embedded Linux
Made Easy(4)
A look at the kernel
GNU/Linux provides interfaces and applications

for devices that we are used to seeing on desktop
computers and servers. Much of this transfers to
the embedded domain, where Linux relieves the
programmer of a lot of work by handling networking,
USB, Bluetooth and more without the need to write
complex dedicated Cprograms. And as we shall see,
using a modern operating system brings many other
benefits too.
In the previous installments in the series we have looked at how the
tool chain, the kernel and bootloader, and a standard file system can
be got up and running. One aim of the series is to show developers
what is happening under the bonnet, for example in how devices
and processes are implemented. In this installment we will first look
at what advantages there are in using an operating system when
compared to driving hardware at the bare metal level.
What is the essence of an operating system? At its heart it consists
of a collection of all the software needed to run specially-written
applications in parallel with others. The distinction between normal firmware and operating-system-based firmware is, however,
somewhat blurred. It is common enough for normal firmware to
include a clean interface to the hardware layer to provide commonly-wanted functions, for example in memory management;
and often there will be a small scheduler to divide the processors
attention between different programs. Together these already form
the beginnings of what might be called an operating system.
A typical operating system

There are of course many books on the subject of operating systems[2]. Here we shall only take a broad overview of the main
components:
Device management
Process management
Memory management
File management
User and permissions management
In the embedded world device management is usually a particularly
important aspect. The operating system must present peripherals

and hardware to applications in such a way as to simplify their use
as far as possible. This is done using device drivers. The operating
system is also responsible for handling all the details behind allowing several programs to run simultaneously, all wanting access to
SD cards, network interfaces and so on.
In the simplest programming model, an application running under
an operating system is a single, independently executable process.
A process has its own virtual address space, ensuring that it cannot
disturb other processes. Processes are centrally managed via the
process table, and each has its own process control block[3] which
typically includes space for temporary storage of processor register
contents and other important variables:
Program counter
CPU registers
Stack pointer
Status of open files
Process state
Other status information
When we launch our hello world program the kernel loads the
application and creates a new process. A new process is always created on the basis of the current one, and inherits the user permissions associated with it. The command
ps -ejH
will display the current set of processes in the system in a tree structure. At the root of the tree is the first process launched by the ker-
22
nel, invariably called /sbin/init. Starting this process is one of the

first things the kernel does when booted.
As developers we are particularly interested in the following features of an operating system:
The interface for device drivers
The file system for programs and data
Launching and executing programs
Shared use of libraries by different programs
Access to input and output ports
Transferring working memory to non-volatile memory
Memory management for applications and processes
Process management
Let us start with device management.
Configuring the kernel

Which interfaces and peripheral blocks of the embedded processor
we need will depend on the application. The Linux kernel is designed
in a modular fashion, which results in the developer having very
fine control over its settings and in particular over what drivers and
mechanisms will be included in the kernel. It is also subsequently
possible to load other components dynamically. The best way to
see how this is done is to look directly in the kernel source code. So,
switch to the kernel source code tree:
cd ElektorLinuxBoardDownload_20120509
and invoke the kernel configuration menu:

make menuconfig
The main menu (Figure1) should immediately appear. If it fails to

appear, one possible cause is that the libraries for displaying console-style menus are missing. They can be installed on our Ubuntu
system by typing:
sudo apt-get install libncurses5-dev
From the main kernel configuration menu it is possible to enable or

disable any of its features and device drivers at will. For the beginner
it will not always be immediately obvious where within the menu
structure a particular option might be hiding, but with a bit of practice it soon becomes familiar.
An alternative to using the menu is to go straight to the configuration file .config in the kernel source directory (linux-2.6.33lpc3131x) and edit it by hand. (The full stop at the start of .config
indicates that it is normally a hidden file.) However, it is usually
more convenient to use the interactive menu. Before changing the
configuration it is a good idea to make a backup copy of the current
configuration file.
Figure1. Main kernel configuration menu.
cp .config config_backup
Newcomers to Linux often ask where good documentation can be

found. The best documentation for the kernel is in the kernel source
itself. It is also possible to click on help at any time in the menu to
find information on a particular item, or you can browse through
the Documentation directory (at the top level of the kernel source
tree) to look for information on a particular topic.
As Figure1 shows, the menu items are sorted into groups. At the
top are the general kernel settings, and then follow settings for the
device drivers and file systems, and finally items relating to cryptography and security.
General setup
The menu item General setup covers the basic characteristics of
the kernel, including, for example, whether there is any swap space,
how memory is managed and how internal communications are carried out. There are also settings relating to the kernel image itself,
optimizations for small systems, statistics, tools and much more
besides. The more you find out about the Linux kernel, the more
handy features you discover: there are only a few people who can
lay claim to understanding it completely!
Enable loadable module support
Another good feature of Linux is that the kernel can be extended,
while it is running, by simply adding extra modules. The kernel
configuration menu lets you decide whether a particular feature
or driver should be permanently built into the kernel code or compiled as a module: anM before a menu item means that the feature
will be compiled as a module, whereas an asterisk before an item
means that it will be built in permanently. If you want to be able
23
MICROCONTROLLERS
New version of the Elektor Linux board

Demand for the Elektor Linux board has been truly overwhelming!
Because of the large number of orders we have received the next
production batch has had to be made rather sooner than expected.
Unfortunately the DRAM chip in the BGA package has a lead time
to support a wide range of different devices, building all the drivers into the kernel can make it unwieldy: it is better to compile the
drivers as modules and load them manually or let the kernel load
them automatically.
Enable the block layer
The kernel distinguishes between two types of device: character
devices and block devices. A character device sends and receives
messages and other data one character at a time; a block device
always does so in complete blocks. Typical character devices include
consoles and UART interfaces; block devices include hard disks and
memory cards such as MMC and SD cards. If no block devices are
needed (as is possible for some embedded systems) some memory
space can be saved by disabling the block layer.
of some 20weeks, and so we decided to change the layout to accept a TSOP54 device. The new memory has the same capacity as
the old one but requires a supply voltage of 3.3V instead of 1.8V.
The upper picture shows the original version of the board with the
BGA memory chip, while the version in the middle picture has the
TSOP54 device fitted. Since the beginning of July we have been delivering version 1.1blue of the board, in which the now redundant
1.8V voltage regulator circuitry is removed. You can easily identify
the most recent version of the Elektor Linux board by its blue colour.
The corresponding circuit diagram is shown here.
System type
Some kernel features depend on the type of processor being used.
For example, it may be desirable to enable or disable caches or
memory management units. This menu item lets you specify (as
far as is possible) the processor type: if your particular processor is
not listed, you will need to find a patch or suitable board support
package (or write it yourself).
Bus support
Here it is possible to enable support for typical PC-type buses. In our
case only the PCMCIA option is available.
Kernel features
This item is very kernel-specific: you can specify what binary interface convention is to be presented to programs and other miscellaneous features, such as displaying processor load via the blink frequency of an attached LED.
Boot options
How the kernel is started up depends in the case of the Elektor Linux
board chiefly on the bootloader. The main interface between the
bootloader and the kernel is the so-called kernel command line.
This command allows the bootloader to pass various parameters to
the kernel that can subsequently be examined by it or by other programs. The menu item allows you to specify that a given different
command line should be used instead. Alternatively, it is possible to
compile the kernel so that it can be run directly from flash storage.
CPU Power Management
These days processors offer an ever wider range of features to support efficient power management. The kernel has to be properly
configured to allow applications to take full advantage of these
features.
Floating point emulation
This kernel configuration menu option allows you to configure it so
that it takes responsibility for floating-point calculations or so that
hardware support is used. At least one of these alternatives must be
selected to allow programs to be run.
24
+1V2
+3V3
C35
C36
10u
1n
220p
+3V3
4u7
R12
+3V3
+3V3
L3
10k
C14
C16
C15
C12
C13
10u
100n
47n
3n3
10u
R13
VOUT/
VFB
SW
GND
M11
N14
F12
E14
G10
TP1 TP2
LPC_RXD
P12
LPC_TXD
N12
N13
TP5
P14
TP6
PWM_DATA
B9
GPIO3
I2SRX_WS0
GPIO4
SPI_CS_OUTO
MGPIO6
SPI_SCK
MGPIO7
SPI_MISO
MGPIO8
SPI_CS_IN
MGPIO9
SPI_MOSI
MGPIO10
GPIO12
MI2STX_BCK0
GPIO13
MI2STX_WS0
GPIO14
MI2STX_CLK0
GPIO15
I2STX_DATA1
GPIO16
I2STX_BCK1
GPIO17
I2STX_WS1
GPIO18
MUART_RTS_N
ADC10B-GPA1
PWM_DATA
A10
Q2
C30
10k
LPC_MCI_CLK
A6
LPC_MCI_CMD
A5
LPC_MCI_DAT0
B5
LPC_MCI_DAT1
C5
LPC_MCI_DAT2
A4
LPC_MCI_DAT3
J14
GPIO14
J13
GPIO15
GPIO18
H11
GPIO19
GPA0
A14
GPA1
B13
C14
SV1
10k
RESET
S3
C11
E3
LPC_D15
F3
LPC_DQM0
H1
LPC_WE
J2
J1
J3
K1
K2
E6
E7
D4
MLCD_DB_11
EBI_D_12
MLCD_DB_12
EBI_D_13
MLCD_DB_13
EBI_D_14
MLCD_DB_14
EBI_D_15
MLCD_DB_15
LPC313XFET180
EBI_DQM_0_NOE
EBI_A_0_ALE
EBI_A_1_CLE
EBI_NWE
EBI_NCAS_BLOUT_0
NAND_NCS_1
NAND_NCS_2
MLCD_RS
NAND_NCS_3
MLCD_RW_WR
MNAND_RYBN0
N6
LPC_A2
P6
LPC_A3
N7
LPC_A4
P7
LPC_A5
K6
LPC_A6
P5
LPC_A7
N5
LPC_A8
L5
LPC_A9
K7
LPC_A10
N4
LPC_A11
K5
LPC_A12
P4
LPC_A13
P3
LPC_A14
N3
LPC_A15
B3
LPC_A0
A2
LPC_A1
G1
LPC_CAS
H2
LPC_RAS
P8
L8
DAT3
CMD
V+
CLK
GND
DAT0
DAT1
SW_A
SW_B
SD-CardSocket
10k 10k 10k 10k 10k 10k
10u
100n
10n
L7
L12
C12
10u
301k
10u
100n
10n
E5
F5
G5
H5
+3V3
L4
C26
C25
10u
100n
10n
M9
D7
LPC_CKE
10u
E8
C17
100n
G12
10n
L10
MNAND_RYBN2
MNAND_RYBN3
VSSA12
LPC313XFET180
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOA
VSSE_IOA
VDDE_IOB
VSSE_IOB
VDDE_IOB
VSSE_IOB
VDDE_IOB
VSSE_IOB
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VSSE_IOC
K11
+3V3
IC6.C
VDDE_IOC
D5
C22
VSSI
VSSE_IOB
C13
C23
VDDI
VDDE_IOB
M7
+3V3
VSSI
VSSE_IOA
M5
C27
VSSI
VDDI
VDDA12
B2
C31
VDDI
VDDA12
E10
C33
VSSI
VPP_B
D11
C32
VSSI
VDDI
VPP_A
C9
100n
+3V3
VDDI
VSSI
A9
C38
R19
VDDE_ESD
A13
VSSE_IOC
ADC10B_VDDA33
ADC10B_GNDA
LPC_MCI_DAT3
LPC_MCI_CMD
4
LPC_MCI_CLK
LPC_A0
23
LPC_A1
24
LPC_A2
25
LPC_A3
26
LPC_A4
29
LPC_A5
30
LPC_A6
31
LPC_A7
32
LPC_A8
33
LPC_A9
34
LPC_A10
22
LPC_A11
35
LPC_A12
36
LPC_A14
20
LPC_A13
21
A0
A1
DQ0
DQ1
A2
DQ2
A3
DQ3
IC5
A4
DQ4
A5
DQ5
A6
DQ6
DRAM
A7
A8
DQ7
DQ8
A43E26161
A9
DQ9
A10/AP
DQ10
A11
DQ11
NC
DQ12
BS0
DQ13
BS1
DQ14
DQ15
LPC_DQM0 15
LPC_DQM1 39
LPC_CLK
38
LPC_CKE
37
LDQM
CAS
UDQM
RAS1
CLK
WE
CKE
CS
+5V
VCC
LPC_MCI_DAT0
LPC_MCI_DAT1
LPC_MCI_CD
D+
GND
USB
J3
R9
GPA0
GPA3
4 PWM_DATA
LPC_D0
I2C_SCL
I2C_SDA
LPC_A1
SPI_MOSI
SPI_MISO
LPC_D2
SYSCLK_O 9
10
SPI_SCK
LPC_D3
GPIO14
11
12
GPIO11
LPC_D4
13
14
10
LPC_D5
11
LPC_D6
13
LPC_D7
42
LPC_D8
D12
G4
L6
L11
E9
C3
C4
E4
F4
H4
K3
M3
M4
M6
M8
B12
D6
D8
D9
G11
L9
L13
A12
44
LPC_D9
45
LPC_D10
47
LPC_D11
48
LPC_D12
50
LPC_D13
51
LPC_D14
53
LPC_D15
17
LPC_CAS
18
LPC_RAS
16
LPC_WE
19
LPC_CS
+5V
D
D+
GND
LPC_VBUS
47u
4
5
12
11
REGIN
VBUS
VDD
RI
RST
DD+
13
RTS
SUSPEND
CTS
GPIO18
LPC_DP
USB_ID
R10
R14
C10
R18
JP1
1M
1M
100n
10k
2
1
28
27
26 LPC_RXD
25 LPC_TXD
24
23
TP7
GND
3
Relay
BSS123
+5V
GND
1
270R
MC78M05ABDT
Q4
LPC_DM
TXD
SUSPEND
G6D-1A-ASI5VDC
270R
X1
K4
BAT54
DSR
RXD
EXP
11
DTR
CD2102
GND
D4
DCD
IC7
+5V
LED5 270R
R24
1u
MINI-USB
1k
LED1
R27
C28
C24
X2
+5V
+5V
J4
+3V3
LED2
+5VEXT
+3V3
GPA1
R22
K1
D
A11
C7
+3V3
LPC_MCI_DAT2
C19
LPC_CS
U1
DM3D-SF
DAT2
C18
+1V2
K8
MLCD_CSB
C21
C6
N9 LPC_DQM1
MLCD_E_RD
MNAND_RYBN1
R29
R25
1
R23
LPC_D14
GPA1
4 GPIO15
R30
3 GPIO14
+3V3
10k
100n
2 GPIO11
GND
R21
X4
3.3V
R20
10k
GPA3
R17
R16
D3
MLCD_DB_10
EBI_D_11
GPIO2
GPIO0
R15
C2
J5
B14
+3V3
X7
LPC_D13
EBI_D_10
H3
LPC_CLK
K13
ADC10B-GPA3
+3V3
AS1324
10R
K14
RESET
+3V3
R4
K12
ADC10B-GPA2
22p
G3
LPC_MC1_CD B4
C29
22p
LPC_D12
GPIO11
12MHz
S1
22p
301k
GND
J11
UART_TXD
ADC10B-GPA0
B6
J12
GPIO20
MUART_CTS_N
LED1
H10
GPIO19
UART_RXD
GPIO2
B11
H13
GPIO11
MI2STX_DATA0
L14
C11
MGPIO5
R26
GPIO15
L1
I2SRX_BCK0
+3V3
VOUT/
VFB
SW
10u
P9
49
M12
GPIO2
C2
MLCD_DB_9
43
M13
I2SRX_DATA0
J10
GPIO1
LPC313XFET180
A1
LPC_D11
EBI_D_9
VDDQ
B7
B8
GPIO0
LPC_D10
MLCD_DB_8
VDDQ
C8
SPI_MOSI
I2SRX_BCK1
GPIO0
K10
A3
N8
MLCD_DB_7
EBI_D_8
VSS
SPI_MISO
TP4
I2SRX_DATA1
LPC_D9
IC6.B
EBI_D_7
VSSQ
A8
G13
SYSCLK_O
I2SRX_WS1
C1
C7
VIN
IC2
4uH7
54
SPI_SCK
CLOCK_OUT
I2C_SCL1
10k
SYSCLK_O
B1
MLCD_DB_6
52
A7
J4
C1
LPC_D8
EBI_D_6
10k
TP3
H12
LPC_D7
MLCD_DB_5
27
P11
CLK_256FS_O
D2
MLCD_DB_4
EBI_D_5
14
N10
BUF_TMS
I2C_SDA1
R2
LPC_D6
EBI_D_4
VDD
M10
R1
I2C_SCL0
D14
+3V3
D1
VDD
F13
D13
LPC_D5
MLCD_DB_3
VSSQ
+3V3
F11
BUF_TCK
E2
MLCD_DB_2
EBI_D_3
VSS
F14
SCAN_TDO
BUF_TRST_N
I2C_SDA0
TDO
LPC_D4
EBI_D_2
41
G14
F10
E1
46
E13
E11
ARM_TDO
IC6.A
USB_GNDA
TCK
F1
LPC_D3
28
E12
I2C_SCL
USB_VSSA_TERM
M14
LPC_D2
MLCD_DB_1
I2C_SDA
TCK
USB_VSSA_REF
TDI
TMS
MLCD_DB_0
EBI_D_1
D10
TMS
TRST_N
K9
P10
EBI_D_0
VDD
C10
TDI
F2
VDDQ
N1
P13
TRST_N
USB_RREF
G2
LPC_D1
VDDQ
L3
USB_ID
LPC_D0
VSS
K4
12k
1%
RSTIN_N
RESET
VSSQ
J5
H14
VSSQ
M1
R11
USB_DP
22p
R3
EN
N11
JTAGSEL
12
USB_ID
USB_DM
66k5
L2
+1V2
USB_VDDA12-PLL
P2
FFAST_OUT
LPC_DP
USB_VBUS
B10
N2
USB_VDDA33-DRV
L2
FFAST_IN
LPC_VBUS
USB_VDDA33
P1
M2
LPC_DM
301k
R6
AS1324
DNP
C8
VIN
IC3
4uH7
R5
EN
+1V2
4u7
LED1
C37
+5V
C5
C4
IC8
X6
+5VEXT
1
2
DC 7 - 12V
C20
47u
120181 - 13
25
MICROCONTROLLERS
User space binary formats

Programs and applications are compiled using the tool chain (see
the previous installment in this series). Normally, for a Linux system, the tool chain will produce either a .elf file (executable and
linkable format, corresponding roughly to a .exe under Windows)
or an a.out file. The kernel reads these formats and launches the
compiled application appropriately.
A handy Linux command is file which lets you see what format a
given file has. Switch to the appropriate directory using cd and then
type file followed by the name of the file of interest. For example, in
the Linux directory there is a file called vmlinux. Typing
file vmlinux
produces the answer
vmlinux: ELF 32-bit LSB executable, ARM, version 1
(SYSV), statically linked, not stripped
The file is an executable file for ARM processors that is statically

linked.
Power management options
It is not just the processor that offers power management features:
many peripherals and other devices have the ability to go into a
sleep mode. The operating system can take a copy of important
data and send the peripheral to sleep. When the time comes to
wake the peripheral up again, the data are copied back from memory and its state is restored. The exact behavior of the kernel in
these situations can be configured here.
Networking support
Finally we come to one of the most interesting points for developers. Under networking support we can enable, disable and configure all the software stacks (protocol libraries) for the various communication interfaces, including Ethernet, TCP/IP, CAN, infrared,
amateur radio, Bluetooth and wireless.
Security options
Linux includes a range of different security features. The most familiar of these is the system of user and group permissions and the existence of a root user. Applications can be further protected using
techniques such as trusted platform modules and internal security
models.
Cryptographic API
This menu item covers cryptographic functions in the kernel.
Library routines
This menu item includes functions for calculating checksums alongside many other things.
If you want to save your new kernel configuration, use the last menu
item Save an alternate configuration file. After entering a name for
the new kernel configuration it will be stored locally in the kernel
source tree.
We described in the previous installment in this series[4] how to
go about compiling the kernel (make zImage) and copying it to an
SD card. If new modules are to be included in the kernel, they have
to be separately compiled and installed. Compile the modules by
typing:
make modules
and to copy them to the SD card, either give the path to the destination SD card directly in the following command, or install the
modules into /tmp and then copy the new directory that is created
there to the SD card, either as user root or using the sudo command. (It is not that root privileges are required for the copy operation itself, but rather that we must ensure that the files are copied
to the file system on the SD card in such a way that the kernel can
subsequently use them as the root user.)
make INSTALL_MOD_PATH=/tmp modules_install
Device Drivers
We are also especially interested in device drivers. This menu item
includes everything you might wish for, from the simplest I/O port
to the most up-to-the-minute high speed server bus. The kernel
source code (see download at[4]) includes drivers for a wide range
of USB, I2C and SPI devices which we now have at our disposal.
Now we switch the the /tmp directory and copy the directory lib
to the SD card:
File systems
File systems are important to us for two reasons. First, the operating system itself must reside in a file system (on the SD card), so
that the kernel can read the files it needs from it. And second, the
operating system has to use a file system to allow application files
and directories to be stored on a hard disk.
with the appropriate change to the long hex string.
Kernel hacking
This menu item is chiefly aimed at kernel developers.
cd /tmp
sudo cp -R lib /media/86b3be7-00f3-45e0-832elf48c2c3065e
Interfaces
Linux has its roots in the PC world. There we are faced with interfaces such as IDE, SATA, PCI, AGP and the like. In the embedded
world the focus is more on the traditional microcontroller interfaces
and, of course, USB.
To summarize, our board has the following interfaces:
26
Table1. Device files typically found in the /dev directory

Device type
File in /dev
Character or block device
IDE hard disk
/dev/hda, /dev/hdb, ...
Block
SCSI hard disk
/dev/sda, /dev/sdb, ...
Block
RS-232 interface
/dev/ttyS0, /dev/ttyS1, ...
Character
Printer
/dev/lp0, /dev/lp1
Character
Camera
/dev/video0, /dev/video1
Block
Mouse
/dev/input/mice
Character
RAM
/dev/ram
Block
USB (as host and device)

UART (in its current form as the system console, but can also be
used as an interface to external devices)
I2C (as master)
SPI (as master)
Also, the processor has other hardware functions such as:
GPIO
A/D converter
PWM output
As we proceed we will look more closely at these interfaces.
Device files
In order to allow applications to talk to devices, we need an interface to the device driver. The way that drivers are accessed varies
greatly from one operating system to another. Linux is based on
a UNIX file system, and under UNIX things are particularly simple:
each device is treated as a file. The idea is that no special tools are
required to drive a device; instead, we can just use small, simple
programs (from the console), operating on devices exactly as if they
were files. We showed an example of how this works in the case
of GPIO pins in the second installment of this series[5], where we
demonstrated how to flash an LED.
There are two important commands with which surprisingly much
can be achieved: cat and echo. The command cat displays the contents of a file; echo, conversely, lets us write any desired text to a
file. To put it more precisely, the output of echo can be redirected
to any desired file.
So, for example, if we want to write some data directly to a hard disk
(that is, not via a file system) or send data to a serial port, we can use
echo in commands of the form
echo Data for the hard disk > /dev/sda
or
to a hard disk or memory card, make sure you use one without any
important information stored on it!
Some device files correspond to block devices and some to character devices. A hard disk, for example, is always treated as a block
device, whereas an RS-232 interface is treated as a character device
like a normal terminal, receiving and processing characters one at a
time. Table1 gives a list of example device files that might be found
in a typical UNIX or Linux system.
Readers may be wondering exactly what mechanism is hiding
behind the commands echo and cat . How exactly does a driver
send or receive data? Now, since everything is a file, we can access
the device by simply reading from or writing to it as we would a
file. This means that each driver simply has to provide three functions: Read, Write and Ioctl (which allows the devices settings
to be changed). Read and Write are the standard functions for
reading and writing files, the process in the case of a device being
exactly analogous to that for a normal file. The first step is to open
the device or file and obtain a handle (a number which identifies
the opened device or file). The handle is then passed to subsequent
Read or Write operations on the device or file.
Kernel space and user space

Classical operating systems (in which category we include Linux) are
generally constructed with a clear separation between the memory area that is used by the kernel and the memory area available
for applications. An application is not permitted to access the kernels memory. This is another important fact for developers working close to the system level to bear in mind. In Linux, the memory
areas are called kernel space and user space. Usually in the case
of a device driver, all the software will be in kernel space. So how
does a user application program get its hands on the data received
over an interface?
The answer lies in the kernel functions such as copy_to_user[6],
which copies a block of data from kernel space into user space. So,
when an application reads a device file the driver must use this function to make the information available to the application.
Integrating a device driver
echo Hello there, world > /dev/ttyS0
But be careful: if you wish to experiment with writing data directly
We now know the basic principles of operation of a kernel device driver.

The question remains, however, of how the kernel knows to associate
a file such as /dev/ttyS0 with the correct driver for the serial port.
27
MICROCONTROLLERS
cat /proc/devices
The result is a list of device drivers, sorted into character devices and
block devices (Figure2).
Now we can look in the /dev directory using ls -l to display its
contents (Figure3). There will be a large number of files in the directory representing our various devices. Let us look at the information
provided alongside each device. At the beginning is the letter c
or b which indicates whether this is a character device or a block
device. Then there are the permissions as usual: we will look at these
in more detail in a later article in this series. Then the user who is
the owner of the file. Shortly after that there are two numbers
separated by a comma, and these are the major and minor device
numbers. In this example the major numbers are 1, 4, 5, 8, 89, 253
and254; the minor numbers are 0, 1, 2, 3, 9, 12, 24 and64.
If we access one of these device files from user space, the operating
system will be able to determine from these numbers and from the
entries in /proc/devices exactly which driver is needed.
It is easy to create device files using the tool mknod[7]. We will see
an example of this below.
Integrating a USB-to-serial converter

Figure2. List of available drivers.
To this end so-called major and minor device numbers are used.
These are unique identifying numbers that are defined in the kernel
documentation. The numbers are also present inside the drivers for
each type of device.
The following command can be used to display which drivers with
which major numbers are currently available:
Figure3. These files represent our devices.
Its now time to turn theory into practice. Let us drive a simple USBto-serial converter from our Linux board (from the USB end!): see
Figure4. The basic steps in the process are as follows.
Enable the driver in the kernel.
Compile the kernel.
Copy the new kernel to the SD card.
Check the driver is available in the new kernel.
Create a device file.
Test the device.
Figure4. A CP2102-based USB-to-serial converter

connected to the Elektor Linux board.
28
Enable the driver in the kernel

First switch to the Linux source tree:
cd ElektorLinuxBoardDownload_20120509/
cd linux-2.6.33-lpc313x/
. ./set.h
make menuconfig
Figure5. The 'Device drivers' menu item.
In the first step (Figure5) select the menu item Device drivers.
Then select USB support (Figure6). With the default configuration
there will be anM here instead of the* shown in the screenshot.
Use the space bar to cycle through the three options M(compile as
module), *(compile into kernel), or neither. We select* to avoid
the complexity of having to hunt down the module later. The next
menu item is USB serial converter support and here also we must
turn the M into a* (see Figure7 and Figure8). Pressing the Enter
key brings up a submenu to select the right driver (Figure9). Most
readers will probably want to use the FTDI devices or the Silicon
Labs CP210x controllers, and so we set both of these drivers to*.
To apply these changes, go repeatedly to Exit and then, on the last
page, confirm that you want to save a new configuration file.
Compiling the kernel
We can now set off the kernel compilation process.
make zImage
Typical resulting output is shown in Figure10.
Figure6. The 'USB support' menu item.
Copy the kernel to the SD card

Put the SD card from the board into an SD card reader and then
connect the reader to the PC. Now copy the kernel to the SD card
as follows
sudo cp arch/arm/boot/zImage /
media/386b3be7-00f3-45e0-832e-1f48c2c3065e/
with, as before, the appropriate change to the long hex string.

When the copy operation is complete unmount the file system
manually in order to ensure that all the blocks are safely written to
the SD card[4]:
umount /media/386b3be7-00f3-45e0-832e-1f48c2c3065e
Check that the driver is available

Now we can boot up the Elektor Linux board as usual. It is important to check that JP1 is fitted, so that we force the USB interface to
start up in host mode. We must also make sure that the device is
provided with power over the USB connector from the Linux board.
This is done by fitting J3 in position 3-2.
We can see the first differences during the boot process itself. The
Figure7. Selecting 'USB serial converter support'

to be built in to the kernel.
29
MICROCONTROLLERS
mknod /dev/ttyUSB0 c 188 0
Testing the device

If we now plug the USB-to-serial adaptor into the board we get the
following output.
usb 1-1: New USB device found, idVendor=10c4,
idProduct=ea60
Figure8. Selecting 'USB serial converter support' to be built

as a dynamically-loadable module.
usb 1-1: New USB device strings: Mfr=1, Product=2,

SerialNumber=3
usb 1-1: Product: CP2102 USB to UART Bridge
Controller
usb 1-1: Manufacturer: Silicon Labs
usb 1-1: SerialNumber: 0001
cp210x 1-1:1.0: cp210x converter detected
usb 1-1: reset full speed USB device using lpc-ehci
and address 2
usb 1-1: cp210x converter now attached to ttyUSB0
Figure9. Here we select the USB-to-serial adapter(s)

that will be supported.
two new drivers make their appearance as follows.

cp210x: v0.09:Silicon Labs CP210x RS232 serial
adaptor driver
USB Serial support registered for FTDI USB Serial
Device
Creating a device file

The command cat /proc/devices reveals a new entry 188ttyUSB. We create a device file with this major number as follows.
The last line shows that the device file has been correctly created,
and that the kernel has associated the newly-recognized device with
the right device file.
Our Linux operating system includes a small terminal emulator program called microcom. By adding a jumper to bridge the RXD and
TXD lines of the serial port on the USB-to-serial adaptor we can use
this to test the driver. Start up the terminal program using the following parameters.
microcom -s 9600 /dev/ttyUSB0
If you now type characters at the keyboard they will be sent to the
adaptor and then returned to the board. If the driver is working
properly these characters should then be echoed to the screen.
Break the connection between RXD and TXD on the USB-to-serial
adaptor and the characters should no longer be echoed, demonstrating that the device driver is working. Press control-X to close
microcom.
Internet Links
[2] http://en.wikipedia.org/wiki/
Operating_Systems:_Design_and_Implementation
[3] http://en.wikipedia.org/wiki/Process_control_block
[7] http://wiki.linuxquestions.org/wiki/Mknod
[6] www.gnugeneration.com/mirrors/kernel-api/r4299.html
30
Figure10. Output when compiling the (newly extended) kernel.

In the same way we can modify the kernel to use USB adaptors for
LAN and WLAN, USB sound cards and many other USB devices.
In the next installment in this series we will look at more devices
and interfaces and test them out with a few simple experiments.
(120181)
Advertisement
powered by Eurocircuits
s
B
C
P
r
o
t
k
e
l
E
w
e
n
5% Discount on
Benefit now: Elektor PCB Service offers a permanent

90-day launch discount on new Elektor PCBs!
Check www.elektor.com/pcb for an overview of all Elektor PCBs
31
MICROCONTROLLERS
Embedded Linux
Made Easy (5)
I/O, ADC, PWM, LAN & Web server
The Elektor Linux board is proving to be a big hit. The boards versatility makes it an ideal learning
tool and platform for Linux application development. In this installment we set about reading digital
and analog signals then we hook up a network adapter and build a small web server which generates
dynamic HTML pages. Using this we can read the status of remote LEDs amongst other things and
display the information in a browser.
By Benedikt Sauter [1]

Weve already spoken of boot loaders and Kernels and many readers have already taken their first steps with the file system and SD
cards (check out the text box SD card image). In this installment
we move onto the first real world task. Embedded Linux solutions
+3V3
GPA1
P1
are often found in applications such as process control and data collection. We start by showing how to input and output both analog
and digital values. Next we set up a network connection to allow
remote access of the board and remote control from a web page.
Digital I/O pins

In the second installment of this series we have already managed to
turn LED1 on and off. The LED is connected to the GPIO3 pin of the
processor. These GPIO-Pins can be configured as either input or output and also as an interrupt input. The procedure for initializing the
I/O pins should be familiar to the majority of Elektor readers by now:
activate the pins as GPIO;
initialize the data direction;
output a value or read in the signal level on the pin.
Under Embedded Linux we can talk to the GPIO-Pins via the device
driver from the console.
First we go to the communications folder with the GPIO driver:
Figure 1. Use a pot to test the A/D converters
cd /sys/class/gpio
Next we activate any pins connected to LEDs as GPIO (see circuit
diagram in [2]):
echo 3 > export
Now we must activate the pin connected to the pushbutton as a
GPIO:
echo 15 > export
Next configure the pins as either output or input:
cd gpio3
echo out > direction
Figure 2. The analog inputs are connected

via a connector block
cd ../gpio15
32
echo in > direction

Now we can control the LED (as already shown) using the following
command to turn the LED on and off:
cd ../gpio3
echo 1 > value
echo 0 > value
The pushbutton status is contained in a (virtual) file called value.
The value of which can be read using the cat command:
cd ../gpio15
cat value
Figure 3. Initialization of the A/D converters and

output of two values.
ADC_INPUT
Now you can send commands to control the relay on the board. It
is connected to GPIO18 and the pin can be configured as an output
in the same way as above.
Analog/Digital converter
The LPC3131 provides four analog inputs with up to 10-bit resolution. The range of measured values therefore lie between 0 and
1023 (or 0 to 0x3FF in Hexadecimal). The 3.3V supply is used as the
voltage reference and also powers the I/O bank.
Reading the converter output value is similar to reading a push button status. The A/D converter has its own driver which can only output the value from one channel at a time. Therefore it will first be
necessary to set up which channel is to be read.
For simplicity the A/D converter function can be tested with a simple pot or preset resistor to supply the variable analog voltage. The
circuit is shown in Figure1. The track ends are connected between
3.3V and ground while the wiper connects to pin GPA1 via the terminal blocks.
The setup should look roughly like Figure2. Now the A/D converter can be initialized and successive measurements taken (see
Figure3).
During testing it can be tedious to keep entering the same commands. The program watch automates this procedure. With an
input of:
10k
ANALOG_INPUT
D1
3V3
Figure 4. Protection for the A/D converter inputs.
Listing1: PWM.
#include <stdio.h>
#include <stdlib.h>
#ifndef abs
#define abs(x) ((x) < 0 ? -(x) : (x))
#endif
int pwm(int value) {
FILE* f = fopen(/dev/lpc313x_pwm, wb);
fputc(value & 0xff, f);
fputc((value >> 8) & 0xff, f);
fclose(f);
}
watch -n 1 cat /dev/lpc313x_adc

The tool calls the chosen command once per second. Use Ctrl-C to
stop the process.
Next to GPA1 on the Elektor Linux board can be found the ADC channels GPA0 and GPA3 on header J5 (GPA2 is not brought out).
To protect the A/D input (to some extent) from damage by over
voltage or over current connect a 10K resistor in series with the
input and also a 3.3 V zener diode down to ground (Figure4).
Generating PWM signals
int main() {
int value = 0;
int b;
while(1) {
b = abs(63 - 2*value);
pwm(b * b);
value = (value + 1) % 64;
usleep(1000);
}
}
Many applications such as servo controllers, switched-mode voltage

33
MICROCONTROLLERS
Figure 5. PWM output when a value of 1000 is used as a

comparison value.
Figure 6. PWM with 50% mark/space ratio.
generators and digital audio (and much more [3]) need a generator
of pulse width modulated signals. The Elektor Linux board outputs
PWM signals from header J5. For test purposes use an oscilloscope
to view the generated signals.
In PWM mode the controller increments a 12-bit counter on each
clock pulse. When the counter value reaches a predetermined
value it switches state of the PWM pin from high to low (when
the counter overflows it is reset and the bit goes high) The predetermined value can be any 12-bit value i.e. in the range from 0
to 4095. When the value of 0 is specified the PWM output will go
low immediately. A value of 2000 gives a square wave with a markspace ratio of around 50%.
In contrast to both the I/O and ADC drivers the PWM driver expects
a binary input value so it is not simple to use echo or cat because the
value supplied will be interpreted as a character (ASCII). We need
the assistance of a small help program.
We were able to quickly write this on board using C. We have
included a copy of this program (Listing1). In the Home folder,
where you will always find yourself after logging in, you will find
the file pwm.c. In the code it is necessary to change the name of
a device file.
First open the file using an editor on the board:
nano pwm.c
Navigate along the following line using the arrow keys
FILE* f = fopen(/dev/pwm, wb);
change the line to read:
FILE* f = fopen(/dev/lpc313x_pwm, wb);
Now save the edited version using Ctrl-o and end the editing session
with Ctrl-x. The code can be compiled on the PC or directly on the
Linux board which also contains its own compiler:
gcc -o pwm pwm.c
Once compiled (this takes a few moments) it can be directly
executed:
./pwm
The oscilloscope display shows how the mark/space ratio changes.
When a signal with a fixed mark/space ratio is required this can be
achieved for example with a small script written in the programming language Python. The file pwm.py can be found in the home
folder.
First it is necessary to start the Python interpreter:
python
34
SD card image
When experimenting which we like to encourage! you can
sometimes find yourself backed down a one-way street with no way
out. In this situation there may be no alternative but to take a fresh
version of the original SD card. For this reason we are offering the SD
card contents as an extra download. First download the image from
the Elektor web [8] (Download SD Card Image, 120180-12.zip).
When the download is complete, unpack the archived files:
unzip 120180-12.zip
This takes a while before the following message appears:
Archive: ../120180-12.zip inflating: Elektor_Linux_

Board - Build_New_SD_Card.txt inflating: gnublin.img
Now take the SD to be written to and plug it into the PC or card reader. The system will read the card but we are not interested in this, we
just need a 1:1 image of the downloaded file on the memory card.
For this it will be necessary to manually configure the card.
The best way is to plug the card in the reader and give the command
dmesg via the console to find out what the card has been mapped to.
The response to this command will be something like the following:
In the interpreter (already we are in interactive mode) we can load

the PWM module (a library of Python functions):
import pwm
Now it is possible to call the module functions. One of these functions allows direct input of the counter compare value:
pwm.pwm_raw(1000)
The signal on the oscilloscope should now look like Figure5.
[ 1069.427374] sdf: sdf1 sdf2 [ 1069.430857] sd

5:0:0:0: [sdf] No Caching mode page present [
1069.430863] sd 5:0:0:0: [sdf] Assuming drive cache:
write through [ 1069.430868] sd 5:0:0:0: [sdf] Attached
SCSI removable disk [ 1070.002620] EXT2-fs (sdf1):
warning: mounting unchecked fs, running e2fsck is
recommended
In the last line there is an indication of the device name that the kernel has given to the SD card (sdf1 in this case).
Now it is necessary to manually unmount all partitions by using
umount /dev/sdf1
replace sdf1 with the device name assigned to your card (exactly
as the name assigned to the first partition).
Now the downloaded image can be written to the SD card:
sudo dd if=gnublin.img of=/dev/sdf

sdf is the description of the whole card as a block device.
NB: The process of writing can take up to 10minutes.
are many different models on the market but they mostly use the
same or similar chipsets. The one we are using here is the D-Link
DUB-E100 [4].
In the last installment of this series we integrated the driver for the
USB/UART adapter in the kernel. As we have already shown in this
series the kernel can also load a device driver as a module during
run time. We will use this approach for the network adapter. The
file system already contains many different drivers.
In the case of D-Link adapters it is necessary to give the following
command:
Alternatively the mark-space ratio can be given as a percentage:

modprobe asix
pwm.pwm(50)
the waveform on the screen now looks like Figure6.
Now we should see an output as shown in Figure10.

There are three drivers in the file system:
Using the command

asix
pegasus
net1080
pwm.pwm(1)
pwm.pwm(99)
is interpreted as mark then space so produces 1 to 99% (Figure7
/ Figure8).
Use Ctrl-d to close the Python-Interpreter.
Be aware that at the start Python takes a little while to fully initialize
but once running it responds quite smoothly.
When a different adapter is used try loading different drivers one

after the other. To check if the correct one has been found we should
see this response to the input:
Network interfacing
A response of eth0 indicates the driver has been correctly loaded

and the network is ready to transfer data.
When all of the drivers fail it is possible to go to Device Drivers ->
Network device support -> USB Network Adapters and load the
drivers by hand. The drivers can either be compiled into the kernel
In the last installment of this series we have already shown how to

interface a USB/UART adapter. Now we install another USB adapter
to the Linux board which can connect to an Ethernet network. We
will be using an off-theshelf USB/LAN adapter (Figure9). There
ifconfig -a
35
MICROCONTROLLERS
Windows) from the console by issuing the command ping:

ping 192.168.0.7
When the program reports that no device responded
2 packets transmitted, 0 received, 100% packet loss, time
1006ms
Then this IP address is free to be used.
So we give this to the Linux board:
ifconfig eth0 192.168.0.7
Once this has been set up another ping attempt by the PC should
now elicit a positive response. (Figure11).
Optionally the DHCP server can be allowed to allocate addresses
automatically (Figure12).
Figure 9. A USB/LAN adapter gives the board a network interface.
(recommended for beginners, see [2]) or after the modules have

been converted, copied into the file system and then later loaded
into the kernel.
All modules can be converted using:
make modules
The new module can be installed on the card using:
To ensure the driver is automatically loaded at every start it is necessary to add its name to the /etc/modules file. All of the modules
in this file will be automatically loaded during Linux boot process.
The network IP address is stored in the file /etc/network/interfaces. This file already exists in our file system. Use an editor to
enter your in-house IP address after eth0.
Now each time the Elektor Linux card is started it will be ready to
communicate with your local network.
Web server
Now that a network connection is available we can start a small
web server to view our first demo page with a browser. In the home
folder of the users root is a small script which starts the well-known
web server lighttpd:
make modules_install INSTALL_MOD_PATH=/mnt

root@gnublin:~# ./lighttpd-init.sh
Instead of /mnt the SD card path should be used here
Syntax OK
Now that the network adapter has been recognized it can be given
a temporary IP address. It is worth hooking up a PC to the network
to check just which addresses have already been assigned before the
temporary IP address is chosen. This can be performed in Linux (or
root@gnublin:~#
Using the browser to visit the IP address mentioned above will show
Figure 10. Automatic recognition of the USB/LAN adapter.

36
the web site in Figure13.
Figure 11. A reply following a ping.
A web server typically generates static HTML web pages. When we

show the status of an LED in a browser for example, the web server
must output a dynamically assembled HTML page (depending on
the LED status). We require an interface between the web server
and an external program that is capable of detecting whether the
LED is on or off and can generate a corresponding web page.
The simplest link is called CGI. This Common Gateway Interface
is an interface which enables the web server to access almost any
program. One condition is that it is command-line orientated, and
can also be started (with any parameters) from the console. CGI
scripts also most commonly return an HTML page. As a CGI program
you can use a simple Linux shell script, a PHP or Python program or
even a C program.
Figure 12. The DHCP server automatically assigns the address.
Switching an LED from the browser

This simple application will show how it is possible to change the
state of an LED from a browser. We create a simple script file that
the shell (console) can directly execute. First it is necessary to setup
the CGI interface on the web server.
In the file /etc/lighttpd/modules.conf identify the entry
#include conf.d/cgi.conf
Using an editor (e.g. nano or vi) change it to:
include conf.d/cgi.conf
Next, in the file /etc/lighttpd/conf.d/cgi.conf it is necessary to edit
the entry
#alias.url += ( /cgi-bin => server_root + /cgi-bin )
Figure 13. Test page of the web server.
To
alias.url += ( /cgi-bin => var.server_root + /cgi-bin
)
Now the web server knows that the files in the /cgi-bin folder can
be treated as programs (and not as HTML pages to be sent to the
browser)
And add the line .sh

cgi.assign
Next for us to finally use a simple shell script as a CGI program it is

necessary to identify the region in the file
eruby,
cgi.assign
python )
=> /bin/sh
= ( .pl
.cgi
.rb
.sh
.erb
.py
= ( .pl
.cgi
.rb
.erb
=>
=>
=>
=>
/usr/bin/perl,
/usr/bin/perl,
/usr/bin/ruby,
/usr/bin/
eruby,
/usr/bin/perl,
/usr/bin/perl,
/usr/bin/ruby,
/bin/sh,
/usr/bin/
=> /usr/bin/
The next step is to create a directory for the CGI programs:

mkdir -p /srv/www/htdocs/cgi-bin
.py
python )
=>
=>
=>
=>
=>
=> /usr/bin/
And lastly to add the program in Listing2, after that the editor can
37
MICROCONTROLLERS
When the browser accesses the previously set up IP address, the

page shown in Figure14 is opened and the LED status displayed.
We have built a little control demonstration with the help of a mini
HTML form which in this case only contains a submit button. Pressing the button transfers the form control elements to our web
browser. In this case we use this mechanism to inform the web
server that it must call the CGI script /cgi-bin/example.sh. This
toggles LED1 on the board and builds the new web page with the
changed status message.
Figure 14. LED switching in the browser.
be started with the following command:
Coming up
In the next installment we will build a more complex HTML user
interface which will allow us to control more functions of the board.
It goes without saying that this will not be performed from a nice
clean user interface where you cant see whats happening under
the surface; our control requires a little more intelligence. This can
nano /srv/www/htdocs/cgi-bin/example.sh
The listing is included in the downloads for this part of the course
[5], so you can just copy these to save wear and tear on your
keyboard.
In order for the web server to control the LED it is necessary to set
the configuration and the data direction from the console:
echo 3 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio3/direction
From security reasons the web server never runs as user root but
we must temporarily allow access to allow the web server access to
control the LED:
chown
lighttpd:lighttpd /sys/class/gpio/gpio3/value
Now everyone in the system has access to the LED. This is not an
optimal solution but to selectively assign access rights is something
we will not go into for the time being. More information on this
topic can be found at [6].
Apart from this the web server must be granted appropriate privileges to store log files in a previously generated directory:
mkdir /var/log/lighttpd
chown -R lighttpd:lighttpd /var/log/lighttpd
Start the web server now

root@gnublin:~# /etc/init.d/lighttpd restart
Then you should get the message:
Syntax OK
Listing2: CGI script to generate a website.

#!/bin/sh
if [ "$REQUEST_METHOD == "POST ]
then
if [ cat /sys/class/gpio/gpio3/value == 1 ]
then
echo 0 > /sys/class/gpio/gpio3/value
else
echo 1 > /sys/class/gpio/gpio3/value
fi
fi
echo Content-Type: text/html; charset=utf-8
echo
echo <html>
echo <head>
echo
<title>Webserver CGI Port 3 (LED)</title>
echo </head>
echo <body>
echo <h1>Control-Panel CGI Port 3</h1>
if [ cat /sys/class/gpio/gpio3/value == 1 ]
then
echo Port: On
else
echo Port: Off
fi
echo <br><br>
echo <form action\/cgi-bin/example.sh \ method =
\POST\>
echo <input type=\submit\ value=\Click\>
echo </form>
echo </body>
echo </html>
38
be achieved by a small program running in the background.

For the edition after that and then for the final installment of this
series (the first edition of the year 2013) we have planned something special: The subjects we intend to cover will be entirely up to
you. Go to our special web site [7] and tell us what you would like
to see! A good deal of user talk on the project may also be found on
our forum [9].
(120182)
Internet Links
[3] http://en.wikipedia.org/wiki/Pulse-width_modulation
[4] http://shop.embedded-projects.net/gnublin
[6] http://en.gnublin.org/index.php/Permissions_GPIO
[7] www.elektor.com/linux-feedback
[9] www.elektor.com/forum/elektor-forums/fields-of-interest/microcontrollers-embedded.1543738.lynkx
Advertisement
Android Apps
BESTSELLER
programming step-by-step
When it comes to personalizing your smartphone you should not

feel limited to off the shelf applications because creating your own
apps and programming Android devices is easier than you think.
This book is an introduction to programming apps for Android
devices. The operation of the Android system is explained in a
step by step way, aiming to show how personal applications can
be programmed. A wide variety of applications is presented based
on a solid number of hands-on examples, covering anything from
simple math programs, reading sensors and GPS data, right up to
programming for advanced Internet applications. Besides writing
applications in the Java programming language, this book also
explains how apps can be programmed using Javascript or
PHP scripts.
244 pages ISBN 978-1-907920-15-8
34.95 39.95 US $56.40
10% OFF
fo
GR EEN a r
nd
G OLD Me
mbe r
Further information and ordering at www.elektor.com/android

39
Projects
Embedded Linux
Made Easy(6)
Networks and servers
Linuxs modular structure makes it the
By
Benedikt Sauter[1]
ideal basis for all sorts of projects in

measurement and control. A custom
control system can be written in virtually any programming language you
choose, with the user interface served
up as a web page to a PC, tablet or
smartphone. In this article we will connect the Elektor Linux board to a typical
home network and then show how to
write our own server application. We
finish with a look at the Lua scripting
language.
Figure1.
Overview of the system.
This series has already covered the most important aspects of Linux from the bootloader and
kernel to the installation of device drivers. However, we have not yet seen how everything can
be pulled together to construct a full-scale application, including for example the control logic
running in the background, a web interface for
configuration and operation, and a simple control
panel using a display and buttons.
Messaging between applications

Figure1 shows a typical scenario. In the middle
we have the Linux system running the custom
application and a web server to allow control
from a wide range of devices using a browser.
We can also add a display and a couple of buttons, the display being controlled using a separate
program. The main application program is just
an ordinary process, running in the background
among many others. Such a program is known in
the Linux world as a daemon or service. Once
a daemon has been started it continues to oper-
ate without further action on the part of the user.

There are various ways to implement the interface between the daemon and other programs:
such messaging between threads or processes is
called inter-process communication, or IPC. For
example, we can use pipes, FIFOs, shared memory, sockets, stdin and stdout (standard input
and standard output), files, databases or any
number of auxiliary programs. Which approach
we choose depends on several factors. Are the
programs written in the same language? Does the
software have to be portable to other operating
systems? What data rate is required?
One widely-used approach is the classical network
socket. Sockets have the significant advantage
that data and commands can be sent over a network if desired. It is very easy to send and receive
messages using sockets and suitable functions
and classes are available in a wide variety of different programming languages.
We have therefore chosen to use sockets as
the basis for communications between the pro-
40
Embedded Linux made easy

grams described in this article. Since the web is
also based on standard sockets, we will also see
along the way how to access data on the internet directly. So, as a first step, we will equip the
Linux board with an internet connection.
Connecting to the Internet

We assume that you already have a router providing a connection to the internet and acting as
a gateway for the other devices on your network.
You will also need to connect a USB-to-LAN adaptor to the USB interface on the board and make
sure that the driver for it is loaded[2].
To integrate a new device into a network it needs
to know its IP address and other parameters
such as the gateway and DNS server addresses.
This can be done manually or by using DHCP
(Dynamic Host Configuration Protocol). When
DHCP is used the router on the local network will
configure the Elektor Linux board automatically
(see Figure2). To test whether an IP address
has been successfully assigned using DHCP, you
can use the ping command to see whether you
can establish contact with (for example) the web
server at www.elektor.com (see Figure3).
If no DHCP server is available the network parameters have to be entered manually.
IP address
To set the boards IP address, enter the command
ifconfig eth0 <ipaddress>
with the placeholder <ipaddress> replaced by

an unused IP address on your network. To check
that this has been successful, you can try pinging your router using the command
ping <routeraddress>
with the placeholder <routeraddress> replaced

by the IP address of your router.
Gateway address
In order to send packets over the Internet, the
board has to know the address of the router
which provides the gateway for network traffic.
This is configured using the command
route add default gw <routeraddress>
with the placeholder <routeraddress> again

replaced by the IP address of the router. To test
Figure2.
Configuration of IP
addresses using DHCP.
Figure3.
Testing access to a server
using the ping command.
this step, you can try pinging any other computer

on the internet, for example by typing
ping 94.236.12.177
which will ping the Elektor web server. Assuming this is successful (that is, that no packets are
lost), we can proceed to the final step.
DNS server address

In order to navigate the internet using domain
names rather than IP addresses, each device
on the network needs access to a DNS server.
A DNS server can convert a string like www.
elektor.com into its corresponding IP address.
To configure a DNS server for the Elektor Linux
board to use, it is necessary to edit the file /
etc/resolv.conf (see Figure4). Run the editor
by typing
nano /etc/resolv.conf
and look for the nameserver entry in the file.

One option is to enter your routers address here,
as most routers these days provide DNS services.
Alternatively, if you do not have a local DNS
server, it is possible to use one on the internet.
One that is easy to remember and ideal for testing
is run by Google on the IP address 8.8.8.8. Save
the file using control-O and then type control-X
to leave the editor.
You should now find that you can reach any server
on the internet using the ping command followed by the name of the machine.
Writing your own server

Now that we have established a connection
41
Projects
command prompt so that you can execute other
programs or commands.
The console will show
[1]+
Stopped
./a.out
and if you now type

fg
Figure4.
Configuration of the DNS
server.
(where fg means foreground) the console will

become blocked again. Suspend the program
again using control-Z and then type
Figure5.
Downloading the file
server.c.
bg
which will set the server program running again,

but this time in the background.
between the board and the internet, we can
directly download some example source code
for a server. The command wget, which will be
familiar to users of Linux on PCs, lets us transfer
any file we like from the internet onto our board.
Figure5 shows the command being used to
download the server example code.
The server is written in the C programming language. For initial testing we will use the compiler
on the board; if you plan to develop the code to
any significant extent it is worth using the toolchain on the development PC.
Listing1 shows the source code for the program. The basic function of the server is to listen
on port 5000. If it receives a connection on this
port from another device, it will reply with the
current time. The program could be extended to
include a command interpreter so that different
replies can be given or different actions carried
out in response to different commands sent by
the client.
To test the server we first need to compile it:
gcc server.c
When the compiler has finished, we start the

server by typing:
./a.out
The program will now apparently become unresponsive to the console (apart from control-C,
which exits the program). However, this is not
quite true: you can type control-Z, which suspends the server program and returns you to the
As we mentioned above, the example server code

sends the current time to any client that connects
to it. We can try this out from the console using
the telnet program, which takes as its parameters the IP address of the server and its port:
root@gnublin:~/c# telnet 127.0.0.1 5000
Tue Sep 27 21:34:49 2011
Connection closed by foreign host
To bring the server program back to the foreground (for example in order to terminate it),
simply type
fg
at the console.
Of course, you can equally well access the server
from a web browser. The server could also be
modified so that instead of simply returning the
time it carries out some other action, such as
turning an LED on and off. We showed how this
can be done in the previous installment in the
series[2].
Remote access over the network
So far we have used picocom or similar terminal
program to provide a console over the boards
serial port. However, now that we have a network interface, we can run as many consoles as
we like over the network. This makes life much
easier, especially when developing applications.
42
Listing1: A simple server program.

#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
<sys/socket.h>
<netinet/in.h>
<arpa/inet.h>
<stdio.h>
<stdlib.h>
<unistd.h>
<errno.h>
<string.h>
<sys/types.h>
<time.h>
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(5000);
bind(listenfd, (struct sockaddr*)&serv_addr,
sizeof(serv_addr));
listen(listenfd, 10);
while(1)
{
connfd = accept(listenfd, (struct sockaddr*)
NULL, NULL);
int main(int argc, char *argv[])

{
int listenfd = 0, connfd = 0;
struct sockaddr_in serv_addr;
ticks = time(NULL);
snprintf(sendBuff, sizeof(sendBuff),
%.24s\r\n, ctime(&ticks));
write(connfd, sendBuff, strlen(sendBuff));
char sendBuff[1025];
time_t ticks;
listenfd = socket(AF_INET, SOCK_STREAM, 0);
memset(&serv_addr, 0, sizeof(serv_addr));
memset(sendBuff, 0, sizeof(sendBuff));
For example, we can be editing the source code

in one console while simultaneously running and
testing the program in another.
We use SSH (the secure shell) to make the
connection to the Elektor Linux board over the
network. This console automatically provides an
encrypted communication channel to the board,
which has the advantage that other devices on the
network cannot intercept the information being
sent to and from the board.
SSH from Linux

Under Linux ssh is one of the standard tools.
Type the following into the console on the host
computer:
ssh root@192.168.0.190
close(connfd);
sleep(1);
}
}
address of the board. Next click on Open and you

will be asked to verify that the remote devices
fingerprint (part of the SSH key for checking
the identity of the remote device). Click on Yes.
In response to the prompt login as enter root.
Listing2: A start-up script.

#!/bin/sh
if [ ! -d /var/log/lighttpd ]
then
mkdir /var/log/lighttpd
chown -R lighttpd:lighttpd /var/log/lighttpd
chmod 777 /var/log/lighttpd/
touch /var/log/lighttpd/error.log
fi
modprobe asix
udhcpc
with the IP address replaced by that of your Linux

board. When the connection has been established
with the board, type the word yes (see Figure6). Shortly the standard console will appear,
and you should feel at home!
SSH from Windows

Under Windows we can use the PuTTY program[3]. Figure7 shows the programs main
window, and again we have to enter the IP
echo 3 > /sys/class/gpio/export

echo "out" > /sys/class/gpio/gpio3/direction
chown lighttpd:lighttpd /sys/class/gpio/gpio3/value
chown lighttpd:lighttpd /dev/lpc313x_adc
echo 1 > /dev/lpc313x_adc
chmod 666 /var/log/lighttpd/error.log
/etc/init.d/lighttpd start
43
Projects
ing games programs. The Lua interpreter is just
120Kbyte in size but nevertheless implements
many of the most up-to-date constructs in programming. Accessing files (which in the Linux
world also means accessing devices and hardware
functions) is done using the commands io.open,
io.read, io.write and io.close. The author has written a Lua library for the Elektor Linux board providing easy access to the main hardware functions, including the GPIO and A/D converter.
Figure6.
Accessing the board using
SSH under Linux.
The advantage of using an interpreted language

over a compiled language like C to build a simple
control application is huge: you can easily edit
your programs directly on the board using its
built-in editor (nano or vi) and execute them
immediately.
Using our newly-configured internet connection
we can download the Lua example programs onto
the SD card as follows.
Figure7.
Accessing the board using
SSH under Windows.
When you press enter you will be logged in to

the system.
Using the Lua scripting language for

simple applications
The previous example used the C programming
language. C is very commonly used, fast and popular. However, on a Linux system there are many
other languages available besides C: each has
its advantages and disadvantages and is aimed
at different applications.
One very flexible, fast and easy-to-use language is Lua. The language is interpreted, and
has become best known for its use in scriptFigure8.
The "blink.lua" example
program.
Figure9.
The "adc_relay.lua" example
program.
mkdir lua
cd lua
wget http://www.gnublin.org/downloads/elektor.lua
wget http://www.gnublin.org/downloads/blink.lua
wget http://www.gnublin.org/downloads/button.lua
wget http://www.gnublin.org/downloads/adc_relay.lua
Figure8 shows the listing of a simple Lua program that flashes the LED. First the Elektor library
has to be loaded. The LED is initialised with a
call to initLED() and then switched on and off
in an infinite loop.
The program can be run from the console as
follows:
lua blink.lua
The program button.lua is a simple demonstration of how to control a relay using the IO15 button on the board. And Figure9 shows the code
of the example program adc_relay.lua, which
reads voltage values from the A/D converter in an
infinite loop. If the reading is above the threshold
of500 the relay contacts are closed; otherwise
they are opened. The program can be tested by
connecting a potentiometer to the analog input
as described in the previous installment in this
series[2].
There is plenty of information about Lua on the
internet[4] as well as some good books[5].
44

Starting the web server and other
programs automatically
Figure10.
Downloading the web server
start-up script.
It is rather inconvenient to have to restart a

server application (and perhaps also reconfigure
the hardware) manually each time the board is
rebooted. The solution to this is to include the
relevant commands in a start-up script. Listing2
shows a suitable script to start up the web server
application from the previous installments in this
series[2]. The file start.sh can be downloaded
from the internet (see Figure10).
In order to have this script run automatically
when the Linux system is booted, we can for
example add an entry in the file /etc/rcS.d/
S55bootmisc.sh (the directory /etc/rcS.d is
where the system start-up scripts are kept). First
open the file using an editor.
Figure11.
Accessing the board from an
iPhone.
nano /etc/rcS.d/S55bootmisc.sh
touching the HTML button.

At the end of the file you will see the following
entries.
/bin/mkdir /var/run/sshd
/usr/sbin/sshd
After these add the line

/home/root/start.sh
and then save the file by pressing control-O and

exit the editor with control-X. To make sure that
the file start.sh can be found it must be placed
in the directory /root. The file must also be
made executable by setting its x flag as follows.
chmod +x /home/root/start.sh
From now on whenever the board is booted it
will automatically establish a network connection
and start up the web server.
Access from a smartphone or tablet

In the previous installment in the series we
showed how to access a demonstration web
application from a browser running on a PC. Of
course, such an application can equally well be
accessed from a smartphone or tablet, as long
as the network on which the Elektor Linux board
sits includes a WLAN access point to which the
mobile device can connect. Figure11 shows the
HTML control interface running on an iPhone. The
LED on the board can be turned on and off by
At this point it is useful to note that the Gnublin

project community wiki[6] covers a very wide
range of hardware and software topics. It includes
guides to transmitting and receiving data over
the I2C, SPI and UART interfaces (including moving data to and from user space) and much more
besides.
We have invited readers to propose a topic for
the next installment in this series: at the time of
going to press our poll was still open. We have
been eagerly awaiting your suggestions! We can
also announce that we are working on an expansion board that increases the range of interfaces
available: more on that also in the next issue.
(120578)
Internet Links
[2] http://www.elektor.com/120182
[3] http://www.putty.org
[4] http://www.lua.org
[5] http://www.lua.org/pil
[6] http://wiki.gnublin.org
45
Projects
Embedded Linux
Made Easy(7)
by
Benedikt Sauter[1]
I2C, serial ports and RS485

In the previous installment in this series we called on our readers to tell us
what they would like to see in this final part. Many thanks to the well over one
hundred readers who responded to the call! By popular demand, therefore, we
will look more closely at how a real application is developed. The I2C and serial
interfaces, which are often needed in real-world projects, provide the other main
focus of this article.
3D Model of the Elektor

Linux board created using
the EagleUp tool [14].
Open source softwares lifeblood is open development in the community. Individual project websites therefore form a source of updates, patches
and extensions, and they often also provide useful
hints and tips and even user forums.
The Elektor Linux board is based on the Gnublin
project[2], which was launched in 2009 by the
author in association with the Augsburg University
of Applied Sciences, Germany, as a platform for
embedded Linux development. Since then several
variations on the board have been produced, as
well as compatible extension circuits to drive
stepper motors and interface to the CAN bus.
And, of course, the software has been extended

in many different ways, including updates to the
kernel and to the toolchain, including the C/C++
compiler. Lets install these first!
Updates
In the third part of this series[3] we installed
a C/C++ compiler on the PC to avoid having to
compile programs directly on the Elektor Linux
board. We can now update to the most recent
version of this compiler, along with the other
components in the toolchain.
The easiest way to do this is to open a terminal
46
embedded Linux
window on the Ubuntu Linux machine using the

control-alt-T key combination. Type the following command into the console:
wget http://gnublin.org/downloads/eldkeglibc-i686-arm-toolchain-qte-5.2.1.tar.
bz2
When the archive has finished downloading, we

can unpack it on top of the local file system:
sudo tar xjf eldk-eglibc-i686-armtoolchain-qte-5.2.1.tar.bz2 -C /
Before we can use the new compiler we have

to write a small script to automatically set the
environment variables to point to the new installations directories. Create a file called set.sh in
the directory /opt/eldk-5.2.1:
sudo gedit /opt/eldk-5.2.1/set.sh
and, if you wish, the development environment itself.

Since devices appear just like files within the
Linux directory hierarchy, it is natural to want
to have the remote storage devices appear in
the directory structure of the development computer just like any other directory or subdirectory. Under Linux there are (of course) many
options open to achieve this, including NFS, FTP
and Samba.
In the previous installment of this series[4] we
looked at remote maintenance of the Linux board
using SSH. SSH is a client-server system that
allows access to a console on the board over a
network connection. SSH is similar to Telnet, but
provides a higher level of security by encrypting the connection between server and client. It
also provides a mechanism for transferring files
between the server and the client, using (on the
client side) a program called scp.
Figure1 shows how the new directories are

added to the PATH environment variable. Save
the script file you have created and run it from
the console as follows (watch the period-spaceforward slash syntax at the start):
. /opt/eldk-5.2.1/set.sh
From now on this command must be re-entered

every time you want to compile a program for
the Elektor Linux board on the development PC.
The compiler in the new toolchain can be tested
using the following command:
If the Linux board has the IP address

192.168.0.190, then we can copy a file directly
from the development PC into the Linux boards
file system using the following command:
Figure1.
Environment variables for
the new toolchain.
scp test.c root@192.168.0.190:/root

arm-linux-gnueabi-gcc -v
C/C++ development environment

Many readers asked about the possibility of developing C/C++ code for the board using a userfriendly integrated development environment
(IDE) such as Eclipse. We will therefore briefly
look now at an easy way to develop C/C++ programs on the development machine and then
test them immediately on the board.
You will need the following:
console access to the Linux board (over its
serial port or over the network);
a network file system (to allow access to
files from the development PC);
To copy an entire directory, use a command such

as:
scp -r myproject root@192.168.0.190:/root
The first argument to the command is the file or

directory to be copied. If a whole directory is to
be copied, it must be preceded by the -r option,
which causes a recursive copy of all files and
directories found under the specified directory.
The second argument consists of the user name,
followed by an @ character and the IP address,
and then a colon and the destination path on the
Linux board for the copy operation.
This gives us a convenient way to copy compiled
47
Projects
code to the board whenever we wish. However,
we can make things even easier!
The slickest approach is to install the Linux program sshfs. This is done by typing the following
command on the development PC:
root identity on the development machine. The

simplest way to do this is to start a new console
with root privileges:
sudo apt-get install sshfs
In this console you will be free to examine, create and delete any file you choose.
Now, in order to write programs for the board
on the development PC, we simply need to put
the project directory in the mounted file system.
You can then use Eclipse or other environment
as normal: see[5] for more information.
It is preferable to create a dedicated user on the
Elektor Linux board before commencing a new
project. This can be done as follows:
The tool allows us to access the entire file system

of the Linux board live from the development PC,
completely avoiding the need to copy files across
to the SD card by hand. All that is needed (as
indeed for SSH and scp) is of course a working
network connection.
We first have to create a so-called mount point
within the development PCs file system. This is
the point in the file system where the files that
are actually on the remote system will appear.
The mount point is normally an empty directory,
which we can create either using the mkdir
command at the console or using a graphical
file manager.
First switch to your home directory:
cd ~
and then create the mount point:

mkdir elektor-linux-board
The next command will make the whole file system of the Linux board available on the development PC:
sshfs root@192.168.0.190:/
elektor-linux-board
When the command is entered you will be

prompted one last time for the password. When
this has been entered successfully, you will be
able to navigate around the remote file system
using commands like cd and ls as usual. However, as you wander around you may occasionally
be greeted by the message Permission denied.
This is because the system programs on the Elektor Linux board are owned by the user root
and are not readable by ordinary users; as far as
the remote file system is concerned your identity
(or uid) is that which you have on the development machine. In order to be able to roam freely
around the remote file system you must adopt the
sudo /bin/bash
adduser elektor
You can then mount this users home directory

in the development PCs file system:
sshfs elektor@192.168.0.190:/home/elektor
elektor-linux-board
If you are the only user on both the development PC and the board, in each case your uid will
be1000. This means that you will not encounter
any problems with file permissions between the
two machines. In any case, as a fall-back, it is
always possible to run programs as the root user.
Kernel update
The kernel provides the interface between applications and hardware. If you want to use additional or new hardware, it will sometimes be necessary to download a new version of the kernel
and compile it manually.
The Gnublin projects kernel archive is the first
port of call for Elektor Linux board users. The
kernel has been extended since the first article
in this series was published, adding support for
CAN, SPI and I2C devices.
The source code is kept centrally in a version control system, which provides a place where developers can easily make changes themselves and
track changes made by others. The git version
control software is used to manage the archive. To
access a git repository the git package is needed:
on the development machine type the following:
sudo apt-get install git-core
48
embedded Linux
You can now clone the archive from the repository into any directory you choose:
git clone http://code.google.com/p/
gnublin-develop-kernel/
This operation may take some time. When the

downloading has finished and the prompt returns,
you are ready to build the most recent stable
kernel for the board. Change to the directory for
version 2.6.33 of the kernel:
I2C tools
The I2C bus has been popular in the microcontroller world for decades. Compatible devices
available range from analog-to-digital converters and I/O expanders to temperature sensors. To
drive the I2C bus from Linux we first have to activate the right driver in the kernel configuration:
Device Drivers I2C support I2C
Hardware Bus support I2C bus support
for Philips PNX targets
make elektor_defconfig
If you wish to make manual changes to the kernel configuration, you can do this as before with:
make menuconfig
Finally you can build the kernel (not forgetting

to run set.sh first):
Measuring voltages more accurately

In the fifth installment of this series[15] we showed how to
measure external voltages using the analog-to-digital converter in
the microcontroller. Naturally many readers tried this out, and the
unanimous response was that the 3.3V supply voltage on the board,
which is used as a reference by the converter, is not stable enough
to obtain accurate readings. There is a simple solution to this,
generating a more stable voltage by adding a 10F and a 100nF
capacitor in parallel to ground at one end of R19: see Figure18
and Figure19. This should give a noticeable improvement in the
accuracy of the conversions.
LPC_CAS
LPC_RAS
make zImage
C27
C26
C25
10u
100n
10n
+3V3
D5
D7
LPC_DQM1
sudo cp arch/arm/boot/zImage /media/
M9
C13
LPC_CS
Assuming the kernel builds without errors, it

can now be copied onto the Linux boards SD
card using an SD card reader connected to the
development machine. In the following command substitute the appropriate string for
SD_CARD_LABEL:
M7
C23
LPC_CKE
C22
10u
C17
100n
10n
E8
G12
L10
K11
+3V3
R19
10R
A13
C9
C6
100n
10u
VDDE_IOB
VSSE_IOB
VDDE_IOB
VSSE_IOB
VSSE_IOB
VDDE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VDDE_IOC
VSSE_IOC
VSSE_IOC
VDDE_ESD
ADC10B_VDDA33
J5
GPA0
GPA3
4 PWM_DATA
GPA1
VSSE_IOC
ADC10B_GNDA
LED1
(Alternatively, if you are feeling brave, you can

try out the experimental version 3.3.0.) In the
directory create a suitable default configuration:
LED2
SD_CARD_LABEL/
Compile the modules using the command
make modules
and then install them in a temporary directory:

make modules_install INSTALL_MOD_PATH=/
tmp
You can now copy the modules you have built

from the temporary directory onto the SD card:
sudo cp -r /tmp/lib /media/SD_CARD_LABEL/
The driver is already included in the standard

configuration.
Tools are available for Linux to carry out simple I2C bus tests. These have to be downloaded
from the internet, unpacked and then written
onto the SD card.
First download the I2C tools to the development
PC
wget http://ftp.de.debian.org/debian/
pool/main/i/i2c-tools/i2c-tools_3.0.2-5_
armel.deb
49
Projects
As before[6] we create the nodes in the file
system corresponding to the devices using the
mknod command. To be on the safe side, find
out the correct major number using:
+3V3
R3
C2
C1
100n
2u2
R4
cat /proc/devices
JP2
2k2
2k2
24
SV1
VDD
GPA0
GPA1
+3V3
I/O0.0
I/O0.1
GPA3
4 PWM_DATA
I2C_SCL
I2C_SDA
23
SPI_MOSI
SPI_MISO
22
SYSCLOCK_0
10 SPI_SCK
GPIO14
11
12 GPIO11
+3V3
13
14 GND
I/O0.2
SDA
I/O0.3
SCL
I/O0.4
I/O0.5
I/O0.6
I/O0.7
I/O0.0 2
I/O0.1 3
I/O0.2 4
I/O0.3 5
I/O0.4 6
I/O0.5 7
10
I/O0.6 8
11
I/O0.7 9
PCA9555D
+3V3
I/O1.0
I/O1.1
INT
I/O1.2
21
2
3
I/O1.3
A0
I/O1.4
A1
I/O1.5
A2
I/O1.6
VSS
I/O1.7
and check that the relevant entry reads 89. If

the value is different, the following commands
will need to be amended suitably:
mknod /dev/i2c-0 c 89 0
mknod /dev/i2c-1 c 89 1
I/O1.0 10
IC1
I/O1.1 11
13
JP6
14
15
I/O1.2 1
16
I/O1.3 2
17
I/O1.4 3
18
I/O1.5 4
19
I/O1.6 5
20
I/O1.7 6
12
+3V3
JP1 JP3
A0 7
A1 8
A2 9
INT 10
Address
Jumper
GND 11
R15
10k
Figure2.
Circuit for the PCA9555 port
expander.
120518 - 11
With the device nodes created and the software

installed, we can connect our first I2C device and
try to talk to it. Simple tests can be carried out
using a PCA9555 port expander chip, connected
as shown in Figure2 to the 14-pin expansion
header on the Linux board.
For the tests the device will need a 3.3V power
supply, which can be obtained from the expansion header. Jumpers can be fitted to inputs A0
to A2 of the port expander, allowing each to be
taken to 3.3V or to GND. The levels on these
pins determine the address of the device.
Having connected the chip to the SDA and SCL
signals on the Elektor Linux board, you can use
the tool i2cdetect to scan all the addresses on
the bus:
and then convert it to a standard archive:
i2cdetect 1
alien -t i2c-tools_3.0.2-5_armel.deb
The result is shown in Figure3. The address

0x6e is assigned to the LPC3131s interface itself
for when it is used as an I2C slave. Since all the
address selection pins of the PCA9555 are taken
high in our circuit, it responds to address 0x27.
We can continue to test the function of the I2C
bus by wiring three LEDs to port0 of the chip
(see Figure4). The command i2cset can be
used to send short I2C bus messages using the
command line. For example, to define all the port
expanders I/O pins as outputs, type
This will create a file in your current directory

with the name i2c-tools-3.0.2.tgz. Using the SD
card reader, copy this file onto the card:
cp i2c-tools-3.0.2.tgz /media/
SD_CARD_LABEL/
After rebooting the Linux board the converted

package archive has to be unpacked, and the I2C
device nodes need to be created. These actions
only have to be done once.
i2cset 1 0x27 0x06 0x00
First, then, we unpack the Linux I2C tools:
and then to set the outputs high type
cd /
i2cset 1 0x27 0x02 0xff
tar xvzf i2c-tools-3.0.2.tgz
and the result should be that the LEDs light.

Now that we have checked from the command
50
embedded Linux
line that we can issue simple I2C commands, we

would like to move on to controlling the bus from
a program written inC.
I2C in C
The LPC3131 has two physically separate I2C
interfaces, of which only the second is made
available on the 14-pin expansion header on
the board.
The device files created above corresponding to
these interfaces are /dev/i2c-0 and /dev/i2c1. Accessing the hardware is done in the usual
way: open the device file and write to it or read
from it as needed.
Listing1 shows a short Cprogram that will light
our LEDs. The program can be compiled on the
development PC with the command
arm-linux-gnueabi-gcc -o i2ctest
i2ctest.c
and then the compiled code can be copied to the

Linux board, either via the SD card or using the
sshfs or scp tools. Alternatively, the program
can be compiled directly on the Linux board using
its built-in Ccompiler gcc.
It is best to copy the compiled program into the /
usr/bin directory so that it can be run from anywhere on the system without having to specify
a path explicitly:
cp i2ctest /usr/bin
The program can then be run on the board, giving

the device file for the I2C bus as its parameter:
buffer[0] = 0x06;
buffer[1] = 0x00;
The commands to turn the LEDs on and off are

enclosed in an infinite loop, with a 100ms pause
between each call.
Figure3.
Output of the i2cdetect
command.
Other devices on the I2C bus can be communicated with in the same way. Cexperts may want
to take a look at the libi2c library[7], which
provides a very flexible way of accessing the bus.
But under the hood this library also just uses the
same ioctl(), read() and write() functions.
Controlling serial ports from the

command line
In the fourth part of this series[6] we installed
a USB-to-RS232 converter. There are various
ways in which serial interfaces can be integrated
into a Linux system. For example, the microcontrollers built-in serial ports are usually accessed
as /dev/ttyS0, /dev/ttyS1 and so on, with the
default console, where system messages and
the initial login prompt appear, usually being /
i2ctest /dev/i2c-1
The LEDs on the expansion circuit should blink

on and off.
In the first part of the source code in Listing1
you can see how the open() function is used to
obtain a handle for the device file. The ioctl()
function, which is used to send configuration
information to the device driver, is then used
to set the address of the desired target device.
Once the address is set, the write() function is
then used to send a simple message over the
I2C bus to the device. The byte sequence to set
the port expanders pins to outputs is the same
as we used above:
Figure4.
Testing the circuit with
three LEDs.
51
Projects
Listing1: Driving an I2C port expander
#include
#include
#include
#include
//prepare communication
if (ioctl(fd, I2C_SLAVE, slave_address) < 0) {
printf(ioctl I2C_SLAVE error);
return -1;
}
<stdio.h>
<fcntl.h>
<linux/i2c.h>
<linux/i2c-dev.h>
write(fd, buffer, 2);
//Slave Address
#define ADDR 0x27
int main (int argc, char **argv)
{
int fd;
char filename[32];
char buffer[128];
int n, err;
if (argc == 0) {
printf(usage: %s <device>\n, argv[0]);
exit(1);
}
sprintf(filename, argv[1]);
printf(device = %s\n, filename);
int slave_address = ADDR;
if ((fd = open(filename, O_RDWR)) < 0) {
printf(i2c open error);
return -1;
}
printf(i2c device = %d\n, fd);
//Port-0 GPIO as Output

buffer[0] = 0x06;
buffer[1] = 0x00;
n = 0;
while (1)
{
buffer[0] = 0x02; /* command byte: write
output regs */
buffer[1] = 0x00; /* port1 data */
usleep(100000);
buffer[0] = 0x02; /* command byte: write
output regs */
buffer[1] = 0xff; /* port1 data */
printf(%d\n, n++);
usleep(100000);
}
}
dev/ttyS0. USB-to-serial interfaces appear as

/dev/ttyUSB0, /dev/ttyUSB1 and so on. Nevertheless, whatever type of serial interface we
use, the interface through which it is accessed
is always the same.
The way Linux treats devices as files gives us a
certain amount of platform independence: for
example, we can develop and simulate an application that uses a serial port on the development
PC, addressing the USB-to-serial converter as
/dev/ttyUSB0 just as we would on the Linux
board. Then it is an easy job to transfer the software from the PC to the Linux board by crosscompiling it and then running it supplied with the
correct parameters.
ing driver has already been loaded:
If a device file is missing it can be created using

mknod as before, assuming that the correspond-
However, we would like to be able to drive the

port without using a ready-made program. Send-
mknod /dev/usb/ttyUSB0 c 188 0

In the fourth part of this series we used microcom, a simple terminal emulator program for
communicating over serial ports. The desired
baud rate and device are given as parameters
to the command. When the program has been
started any received characters are displayed
immediately on the screen, and any characters
entered on the keyboard are transmitted on the
serial port.
52
embedded Linux
ing and receiving data is not complicated: we can

simply use normal commands to write to and
read from the device file /dev/ttyUSB0. However, setting the baud rate of the port requires
using a special technique.
Under Linux the command we need is called stty.
For example, to set the port speed to 38400baud,
the following command must be issued:
stty -F /dev/ttyUSB0 38400
We can now send a simple string of characters

like this:
for this program. The first part of the program

sets up the basic configuration using the data
structure struct termios options. The function
tcgetattr() first writes the current configuration into the data structure so that it can subsequently be modified. The data rate is set using
the functions cfsetispeed() (for the input data
rate) and cfsetospeed() (for the output data
rate). At this point it is also possible to modify
the number of data bits, start bits and stop bits.
Finally the new configuration is put into action
by passing it to the driver using the function
tcsetattr().
echo Hello world > /dev/ttyUSB0
Sending and receiving data works in the same

way as with any other standard device. Using the
and receive characters like this:
function write() (in conjunction with a handle

previously obtained from a call to open()) you
can send data, and using read() you can receive
data. In the example here the connected device
is expecting a command six bytes in length: as
you can see the variable buffer[0] is set to
zero: this value is not so convenient to generate
from the keyboard.
cat < /dev/ttyUSB0
You may want to experiment a little with these

commands, which are more than adequate for
the manual testing of communications with simple protocols that only involve printable ASCII
characters. However, if non-printable characters
are involved things get more complicated, and
a short Cprogram will be an easier way to go.
Controlling serial ports

from a Cprogram
It is a relatively small step to move to using a
Cprogram to control a serial port. As we saw
above when driving the port from the command
line we must first configure the interface, the
most important configuration parameter being
the baud rate. In the download accompanying
this article[8] is a Cprogram (called Listing2)
that shows how things are done.
The examples from[9] were used as the model
Author Benedikt Sauter

in an Elektor interview.
There were lots of cameras
in action on the Farnell/
element14 stand at
electronica 2012. You can
watch the video at[13].
The program expects a reply from the connected

device, also six bytes in length. Reception is done
in a loop which assembles the six characters as
they are read in. The program waits at the function (a blocking call) for each character to arrive.
This is not the ideal solution, as it limits the data
rate to 19200baud. The microcontroller may be
fast and have little to do in the loop except wait
idly for the next character, but nevertheless we
soon run out of precious processor time.
The usual solution to this problem is to use an
interrupt. When a data byte is available the processor is notified and the character is fetched
from the receive buffer. Under an operating sys-
53
Projects
Figure5.
RS485 connection to the
ElektorBus.
Figure6.
Elektor Linux board enclosure.
Figure7.
The expansion board that we will be describing in the
next edition.
tem like Linux this can result in a program that

makes efficient use of resources. If no data bytes
are available, the receiving program is free to
get on with something else or allow itself to be
descheduled; when characters arrive the program
is woken up to process the data.
The third program in the download directory[8]
uses interrupts in this way. It is essentially the
same as the example above, but includes a new
function signal_handler_IO() which is called
only when data bytes have been received.
the sixteen bytes that are to be sent. To control

relay1 on the ElektorBus board, send the following commands:
170,0, 0,5,0,10, 96,1,0,0, 0,0,0,0, 0,0
(relay on)
170,0, 0,5,0,10, 96,0,0,0, 0,0,0,0, 0,0
(relay off)
For relay2 the sequences are:

170,0, 0,5,0,10, 0,0,96,1, 0,0,0,0, 0,0
RS485 and the ElektorBus
(relay on)
Now that we have worked out how to drive a

serial port, we should also be able to send and
receive data over an RS485 interface. It should
just be a matter of replacing the USB-to-RS232
converter on our boards USB port with a USBto-RS485 converter. A suitable converter can be
ordered from Elektor (order code 110258-91)[8].
This device is based around an FTDI chip, which
already has a suitable driver in the kernel that
simply needs to be activated, as described in the
fourth installment of this series.
170,0, 0,5,0,10, 0,0,96,0, 0,0,0,0, 0,0
The remote device on the RS485 bus for this

experiment is an ElektorBus relay module[8]
[10], which includes two relays (Figure5). Listing2 needs to be modified slightly to implement
the ElektorBus protocol, for example to change
the transmission speed to 9600baud and the
variable LENGTH to16. Before sending a message the array Buffer must be populated with
(relay off)
More about the ElektorBus can be found at[11].

If you are looking for a suitable enclosure for
the Elektor Linux board (Figure6), the internet is your friend[12]. At the link you will find
a design that can be printed using a 3D printer.
The enclosure is designed not to require any
screws for assembly: the lid and the base simply snap together.
This is the last installment in our embedded Linux
course, but it is certainly not the end of the project. A new board (Figure7) is in the works to
extend the Elektor Linux board with many handy
functions:
54
display (two rows of sixteen characters);

three buttons to provide a user interface or
menu control;
sixteen extra digital inputs and outputs;
a real-time clock with battery supply;
a buzzer to provide acoustic indications;
a prototyping area for additional circuitry.
Internet links
[1]sauter@embedded-projects.net
[2]www.gnublin.org
[3]www.elektor-magazine.com/120180
[5]http://en.gnublin.org/index.php/Eclipse
If you want to learn more about this extension

board, please go to
(120518)
www.elektor.com/120596-91.
[7]http://opensource.katalix.com/libi2c/
[9]www.tldp.org/HOWTO/Serial-Programming-HOWTO/
[11]www.elektor-magazine.com/elektorbus
[12]www.thingiverse.com/thing:29314
[13]www.element14.com/community/community/events/electronica
[14]http://eagleup.wordpress.com/
Advertisement
Take out a FREE

membership to
Elektor.POST
The latest on electronics and
information technology
Videos, hints, tips, offers and more
Exclusive bi-weekly project for
GREEN and GOLD members only
Elektor behind the scenes
In your email inbox each Friday
Register today at www.elektor.com/newsletter

55

Embeded Linux

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Embeded Linux

Hochgeladen von

Copyright:

Verfügbare Formate

www.elektor-magazine.

Personal Download for Fernando Faria Corra | copyright Elektor

Today Linux can be found running on all sorts of

includes everything necessary for a modern

The origins of GNU and Linux

Personal Download for Fernando Faria Corra | copyright Elektor

Features of the Elektor Linux board

Elektor Linux Board

For USB hardware

For load switching

and drivers would be needed he wrote,

two-layer board using readily-available components

I/O and A/D

Figure2. The printed circuit board is available from Elektor ready-populated.

Personal Download for Fernando Faria Corra | copyright Elektor

10k 10k 10k 10k 10k 10k

Personal Download for Fernando Faria Corra | copyright Elektor

a C compiler, linker and assembler (a

The beginnings of Linux

Figure4. Road map of our multi-part introduction to embedded Linux.

Elektor Linux Board

Kernel (as source text)

File system (as image)

Figure5. For software development a PC (running Linux) is used

Personal Download for Fernando Faria Corra | copyright Elektor

Figure6. Screenshot of the console in action.

nothing to detract from the importance of

The big picture

There are traditional editors such as vi

Compiler + linker + assembler =

Personal Download for Fernando Faria Corra | copyright Elektor

[2] www.gnublin.org (site in German only)

ally suffice, with a relatively small choice of

is loaded at run-time as required by application programs (it is dynamically linked).

The standard C library

make a Linux system easier to operate. We

What the future holds

In the next installment in this

Elektor Products and Services

Free software download

Personal Download for Fernando Faria Corra | copyright Elektor

The main components

also has access to the ROM, from which

one another. Each application is assigned

Elektor products and services

Personal Download for Fernando Faria Corra | copyright Elektor

brought out: however, all of the important

Figure1. The main components of the Elektor Linux board.

The hard drive

for the LPC3131, 1.8V for the SDRAM, and

Figure2. A microSD card

With the board now powered up we can

Personal Download for Fernando Faria Corra | copyright Elektor

10k 10k 10k 10k 10k 10k

Figure3. Circuit diagram of the Elektor Linux board.

Personal Download for Fernando Faria Corra | copyright Elektor

For example, it is possible to boot from the

In the bottom left-hand corner of the circuit

Figure4. Bootloader jumper.

interface can be operated in host mode

Personal Download for Fernando Faria Corra | copyright Elektor

Figure5. Tera Term terminal program.

Figure7. The APEX bootloader.

A power-on reset interrupt is triggered.