Tutorial CubeOS

Informations

• Publié par: Mefer
• Nombre de lectures: 27
• Langue: English

Extrait

CubeOS - the tutorial
Holger Kenn, VUB AI Lab
public draft version 0.1
this document covers CubeOS version 0.4.10 and nPDL version 0.0.4
1Chapter 1
Introduction
Operating systems for embedded systems are different from their counterparts for desktops or
servers in many ways. First of all, the embedded system usually does not have the resources
to run editors, compilers, linkers and so on. Therefore, program development uses a different
computer, often called the host system. The embedded system which is supposed to run the
program is then called the target For CubeOS , the target system is the RoboCube,
the host system is a UNIX computer. The host system uses it’s standard means of program
development (Editors, make etc.) with one important exception: It uses a cross-compiler to
generate target code. In the case of CubeOS , this is the Gnu C Compiler configured for the
m68k-coff target. “m68k denotes the cpu architecture, in this case the Motorola 68xxx family,
“coff is the binary output format of the compiler, the common object file format.
Unlike in a desktop computer, there is no permanent copy of the operating system in the tar-
get. The target only has a small program that enables the user to download compiled code
to the target and executing it there. This program is usually called monitor. A monitor also
has other functions like inspecting memory or testing hardware. CubeMon is the of
the RoboCube and uses communicate with the monitor over a serial interface and a terminal
program.
What’s the function of an embedded operating system? An embedded system is lacking all
the features that are commonly associated with a operating system. There is no screen with a
graphical user interface, there is no mouse, keyboard or other input devices. There are even no
disk drives or floppy’s which would imply a “Disk Operating System. And, of course, there are
no 3D accelerators, multimedia adapters, DVD-Drives and all the nifty features that no modern
desktop computer could lack.
Instead, embedded systems often have a high number of input and output devices that don’t
look too familiar. In robotics, they’re called “sensors and “actuators. A sensor is a device that
tells the system something about the state of the world, an actuator is a device that changes
this state. Sensors are i.e. touch sensors, light sensors, temperature sensors, acceleration sen-
sors, rotary pulse encoders, microphones or even video cameras. Actuators are motors, lights,
robot arms, paint shops or factory assembly lines. The one function of the embedded operating
system is to provide easy access to these devices to the programmer.
Applications for embedded systems are often in systems where the timed execution of programs
2is important. In the motor control system of a modern car engine, a lot of sensory data has to
be processed to obtain optimal fuel efficiency, respecting environmental legislation, providing
driving comfort and respecting the specifications of the motor to ensure continued operation.
On the other hand, the actuators have to be controlled with very high time precision. An op-
erating system that ensures these timing constraints is called a Real-time Operating System
(RTOS). Hard real-time systems ensure that no deadline is missed (and usually this fact can be
proven mathematically). Soft real-time systems can occasionally miss a deadline. Most com-
mercially available systems are soft real-time. CubeOS can control tasks that are either soft- or
hard-real-time or have no timing constraints at all.
Another important domain for embedded systems is communication. I.e. in a modern car, the
different devices are no longer connected with dedicated wires but with a bus system. When
the driver turns the lever for turning on the headlights, a special data packet is sent from an
embedded system in the dashboard to another embedded systems in the trunk and in the front
of the car. There, the power of the headlights and position lights is turned on. If the driver
pushes the accelerator, the same system sends a data packet to the engine controller to increase
power and so on. All these transactions involve a high number of embedded systems that have to
agree upon a common communication protocol while maintaining their own real-time deadlines
and not hindering the real-time deadlines of other systems. I.e. the anti-lock-brake system’s
communication has to succeed even if the driver switches on the air condition at the same time.
3Chapter 2
Hello world
As in most other computer systems, the C language standard code example looks like this:
#include <stdio.h>
int main()
{
printf("Hello World!\n");
}
so, nothing special here. Let’s assume now that this file is stored on the host system’s disk in a
file calledhello.c. To compilehello.c, one has to invoke the cross-compiler:
arti12:˜student>m68k-coff-gcc -mcpu32 -msoft-float -c hello.c
The -mcpu32 tells the compiler the exact processor variant, -msoft-float tells it that the target
CPU does not contain a floating-point unit, so all floating point calculations have to be done by
using replacement code instead of floating point assembler instructions.
The compiler did not give an error message, so we assume that everything went well. Now we
’ve obtained a file called hello.o containing 68000 Assembler instructions. This file cannot be
downloaded into the RoboCube since there are still things missing, namely the C library and
the operating system.
Next is the linking stage. In this stage the object file hello.o is linked with the precompiled C
library and the operating system’s core to an executable file:
arti12:˜student>m68k-coff-ld -nfp -L/projects/cube/src
-o hello.coff hello.o -Tcubeos.ld
This command line needs some explanation. The program called is the linker for the cube’s ar-
chitecture, m68k-coff-ld. -nfp tells the linker, that the architecture has no floating point cpu, so
it uses a version of the libraries that emulate floating point computations. -L/projects/cube/src
tells the linker where it can find additional object files, in this case where the operating system
4for t target is located. -o hello.coff tells the linker to store it’s output in the file hello.coff. Now
the command line lists all the object files to be linked together with the libraries, is this case
only one, hello.o. last is the -Tcubeos.ld command. This instructs the linker to read the linker
command file cubeos.ld. Cubeos.ld contains information about the RoboCube and CubeOS ,
so the linker knows about the memory map of the target and the need for additional libraries
including CubeOS itself.
After executing the command, hello.coff contains the necessary parts of CubeOS , the necessary
parts of the c library, some special startup code (crt0.o) and our code as in hello.c.
However, hello.coff still contains all the debugging information, like the names of the symbols
etc. To get rid of these, another tool is used to convert hello.coff into a simpler format.
arti12:˜student>m68k-coff-objcopy -O srec hello.coff hello.abs
hello.abs could already be downloaded into the target, but it’s format is not well suited for this. is in the so called S-Record format. It is an ordinary text file containing hexadecimal
numbers. Each of the lines in the s-record file contains the address of a memory location and
some data to be written into this memory location. This format is very good for portability and
debugging, but wastes about three times as much memory as necessary. Therefore, the file can
be converted into a pure binary format (with some control information), thereby reducing the
file size significantly.
arti12:˜student>s2tw hello.abs hello.tw
Now we have the appropriate file in the right format, how do we execute the file?
Now, the first thing is to start using the Robocube’s monitor program. The monitor is controlled
via the serial port of a PC with a simple terminal program. The monitor uses the serial settings
57600Bits/second, 8 Data-bits, No parity, One stop-bit, short 57600/8N1. CubeMon does not
use any handshaking, so the handshaking has to be turned off.
To activate the monitor, connect the RoboCube to the serial port of the PC and an appropriate
power supply, start the terminal program and configure it to the appropriate settings and press
enter. CubeMon responds with a prompt:
CubeMon V1.0a
256k free
cubemon>
Cubemon has some online help that is displayed by typinghelp. To download a file, cubemon
has to be set into download mode by using the load command. After that, the terminal software
of the PC has to send the executable file. After the download, cubemon returns to it’s prompt.
With the dump command we could verify if the program has been written into the appropriate
memory location, but we just want to run the program so we simply invoke the boot command.
CubeOS is invoked first, then our program starts running.
cubemon>boot
Jumping into kernel...
Hello World!
cubemon>
5To conclude, here are the steps to compile and run a CubeOS program file:
1. m68k-coff-gcc -mcpu32 -msoft-float -c file.c
2. m68k-coff-ld -nfp -L/projects/cube/src -o file.coff file.o -Tcubeos.ld
3. m68k-coff-objcopy -O srec file.coff file.abs
4. s2tw file.abs file.tw
5. download file with load command
6. boot
Typing all these commands each time to compile a program takes a lot of time. One could use
a batch file to exec