Embedded Control Systems for Intelligent Mechanics - Assignments

We start using the following simple C program:

1:  #include <stdlib.h>
2:  #include <stdio.h>
3:  
4:  int main(int argc, char **argv)
5:  {
6:          int a = 4711;
7:          printf("hello world: %d\n", a);
8:          return(EXIT_SUCCESS);
9:  }

We start by explaining the program. The first two lines 1 and 2 make available some standard program functions which have been defined in different files. Line 4 defines the main function, which is called when the program is started. The code between the parentheses are two arguments which contain the values which were given when the program was started on the command line. The statement in line 6 create a variable a and assigns the value 4711 to it. In line 7 the printf function os called (which is defined in the stdio.h library we included in line 2). Finally in line 8 the program returns from the main function and thereby end the execution. It reports that everything went OK by returning EXIT_SUCCESS (which is defined in stdlib.h)

Store the program in a file (hello_world.c). It can then be compiled with the following command:

$ gcc hello_world.c -o hello_world

Running it produces the intended output.

$ ./hello_world
hello world: 4711

Questions:

• Note the ./ before the file. What happens if it is omitted? Why?
• What do the file(1) and the the ldd(1) command report when run on the compiled program?
• What is the size of the binary?

Next we extend the program with a loop:

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv)
{
        int i;

        for(i=0; i<10; i++) {
                printf("hello world: %d\n", i);
        }
        return(EXIT_SUCCESS);
}

Now instead of running the gcc command again we write a Makefile. Take a very quick look at the make(1) manpage to get an idea what this tool does.

The Makefile for our hello_world.c program will contain the following in a file called Makefile:

1:  hello_world: hello_world.c
2:          gcc hello_world.c -o hello_world

Important: line 2 begins with a tab!

The meaning of this file is the following: in order to build the target hello_world (the target is the name before the ':') the command in the second line needs to be executed. The file hello_world.c after the : in the first line is a prerequisite, which means that the target hello_world depends on this file. Effectively this allows the make program to examine when the prerequisite last changed and to invoke the compilation only when it is necessary.

Now the program can be simply compiled by executing:

$ make
gcc hello_world.c -o hello_world

which compiles the program. Running make again

$ make
make: `hello_world' is up to date.

is not recompiled because make detects that the hello_world program is up to date because none of its dependencies (the hello_world.c file in our case) have changed.

The first step is to retrieve (also called "to check out" a local copy of the remote repository. With git this is done with the clone command:

$ mkdir src/
$ cd src/
$ git clone http://git.mech.kuleuven.be/~u0062335/traffic_control.git
Cloning into traffic_control...

remote: Counting objects: 97, done.
remote: Compressing objects: 100% (94/94), done.
remote: Total 97 (delta 56), reused 0 (delta 0)
Receiving objects: 100% (97/97), 17.52 KiB, done.
Resolving deltas: 100% (56/56), done.

After this you have a local copy of the source code of the virtual traffic light in the traffic_control directory. Change to it and examine the history.

$ cd traffic_control
$ git log

This shows the history of the repository starting from latest changes at the top. Pressing q will exit the pager. The gitk program provides a fancier, graphical overview of the history. Simply run it in the traffic_control directory.

Next step is to make some changes. Edit any of the files, e.g. the README. A summary of the current changes can be obtained with the git status command:

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#modified:   README
#
no changes added to commit (use "git add" and/or "git commit -a")
$

This shows that the README file has been modified.

A more detailed description of the changes with respect to the base version is shown by using the git diff command:

$ git diff

The output has the following meaning: Lines starting with a minus have been removed while lines with a plus have been added. Assuming we are content with the changes made we now want to permanently store them in the repository. This is called commiting the change. Don't worry about commiting a nonsense change, we can check out a fresh copy later.

The following command will store all local changes (the -a flag). You will be asked to enter a message describing the change. It is important to choose good commit messages for you and others to be able to understand later what was the purpose of the change. (Side note: the editor program opened is defined (among others) by the EDITOR environment variable, so you might want to set it to your preferred editor export EDITOR=vi beforehand)

$ git commit -a

Now you should be able to see your change using git log or gitk.

• git is not considered to be intuitive to the newcomer. Especially the staging area, for instance explained here, can be confusing.
• git does not replace making backups: as a git directory is self contained, removing the checked out directory erases all history.
• Find out how to create a new git repository starting from some existing files. This does not have to be source code, git can be useful for tracking changes to any text documents.

For more information consult the exhaustive git documentation.

In the last session we compiled a program to be executable on our local computer (commonly called host system) which probably contains an AMD or Intel CPU. However our target embedded system, the BeagleBoard, contains a ARM CPU which is quite different. Therefore any program which must run on the Beagle Board needs to be compiled specifically for this architecture.

In general there are two possible ways to do this:

1. By compiling a program on the beagle board itself. This is called native compilation.
2. By compiling the program on the host system, but with a compiler which generates executable programs for a different CPU. Because of this asymmetry this process is called cross compilation

The following figure shows the two approaches:

Depending on the situation both approaches are usefull. Generally the cross development approach has the advantage that the development can take place on the host system opposed to the restricted embedded target. We will explore both approaches.

A cross compilation environment is already installed on the lab PCs under opt/eldk-4.2. You can check that it is available in your PATH by writing arm- in a terminal window and hitting tab twice:

$ arm-linux-gnueabi-
arm-linux-gnueabi-addr2line  arm-linux-gnueabi-elfedit    arm-linux-gnueabi-gcov-4.4   arm-linux-gnueabi-ranlib
arm-linux-gnueabi-ar         arm-linux-gnueabi-g++        arm-linux-gnueabi-gprof      arm-linux-gnueabi-readelf
arm-linux-gnueabi-as         arm-linux-gnueabi-g++-4.4    arm-linux-gnueabi-ld         arm-linux-gnueabi-size
arm-linux-gnueabi-c++filt    arm-linux-gnueabi-gcc        arm-linux-gnueabi-nm         arm-linux-gnueabi-strings
arm-linux-gnueabi-cpp        arm-linux-gnueabi-gcc-4.4    arm-linux-gnueabi-objcopy    arm-linux-gnueabi-strip
arm-linux-gnueabi-cpp-4.4    arm-linux-gnueabi-gcov       arm-linux-gnueabi-objdump
$ arm-linux-gnueabi-

This shows the various tools which form the cross development toolchain. They resemble the tools which are available on the host platform but use the prefix arm-linux-. As we will see this allows to quickly switch between cross and host development.

In order to cross compile our hello world program, all we need to do is to extend our Makefile. The original version looks like this:

hello_world: hello_world.c
        gcc hello_world.c -o hello_world

We extend it like this.

CC=$(CROSS_COMPILE)gcc

hello_world: hello_world.c
        ${CC} -g hello_world.c -o hello_world

Important: remember that the space before ${CC} is one tab!

The first line sets the variable CC to the value of the CROSS_COMPILE environment variable plus the string gcc. The result is then used as the compiler command. This way, if we don't set the CROSS_COMPILE environment variable the compiler used will be the standard gcc, so the program will be compiled for the host system as before. But if we set CROSS_COMPILE to the value arm-linux- then the cross compiler will be used so the program can run on the embedded board.

$ make CROSS_COMPILE=arm-linux-gnueabi-
arm-linux-gcc -Wall -g hello_world.c -o hello_world

Some questions:

• What happens if we run the program?
• What does the file command report when run the executable?

For testing a program we need to transfer it to the embedded system and the run it there. For doing this we will use the two tools scp and ssh. The first allows to securely copy files across a network. The second allows to access a remote system by means of a command line interface.

First let's connect with ssh to the beagle board (ip address is 192.168.10.65). The first time you might get a message about the RSA fingerprint, which you should verify to be sure that you are connecting to the right embedded board (and not to a fake system a malicious user has setup)

If the fingerprint is ab:6d:2a:ef:15:24:68:40:c7:ad:7a:4e:55:26:67:19 everything is ok and you can accept the key by typing yes. Next you will be promted for the password, which is ecs.

pma-robot-youbot /home/mk $ ssh ecs@192.168.10.65
The authenticity of host '192.168.10.65 (192.168.10.65)' can't be established.
RSA key fingerprint is ab:6d:2a:ef:15:24:68:40:c7:ad:7a:4e:55:26:67:19.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.10.65' (RSA) to the list of known hosts.
ecs@192.168.10.65's password:
Linux beagle1 2.6.37-x2 #1 SMP PREEMPT Wed Feb 2 20:59:40 UTC 2011 armv7l GNU/Linux
Ubuntu 10.10

Welcome to Ubuntu!
 * Documentation:  https://help.ubuntu.com/

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

ecs@beagle1:~$

Now we are remotely connected to the beagle board with the familar command line interface. We can verify this is an ARM Processor based Linux with the uname command:

ecs@beagle1:~$ uname -a
Linux beagle1 2.6.37-x2 #1 SMP PREEMPT Wed Feb 2 20:59:40 UTC 2011 armv7l GNU/Linux

Next step is to create a folder with your s-number to which your program can be copied. Because everybody is logged in using the same username care needs to be taken to not interfere with each other.

ecs@beagle1:~$ mkdir s0202242
ecs@beagle1:~$

Next we switch to a terminal of the host system and copy our the cross compiled program using the scp tool to the newly created directory on the beagle board:

$ scp hello_world ecs@192.168.10.65:/home/ecs/s0202242/  # replace this with your s-number!
ecs@192.168.10.65's password:
hello_world                                                                          100% 6258     6.1KB/s   00:00
$

Next change to the directory and check the file was really copied there…

ecs@beagle1:~$ cd s0202242
ecs@beagle1:~/s0202242$ ls
hello_world

… and run it:

ecs@beagle1:~/s0202242$ ./hello_world
hello world: 4711
ecs@beagle1:~/s0202242$

Congratulations! You just successfully ran a program which was cross compiled for an embedded system.