La lecture en ligne est gratuite
Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres
Télécharger Lire

Tutorial CubeOS

14 pages
CubeOS - the tutorialHolger Kenn, VUB AI Labpublic draft version 0.1this document covers CubeOS version 0.4.10 and nPDL version 0.0.41Chapter 1IntroductionOperating systems for embedded systems are different from their counterparts for desktops orservers in many ways. First of all, the embedded system usually does not have the resourcesto run editors, compilers, linkers and so on. Therefore, program development uses a differentcomputer, often called the host system. The embedded system which is supposed to run theprogram 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 programdevelopment (Editors, make etc.) with one important exception: It uses a cross-compiler togenerate target code. In the case of CubeOS , this is the Gnu C Compiler configured for them68k-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 codeto the target and executing it there. This program is usually called monitor. A monitor alsohas other functions like inspecting memory or testing hardware. CubeMon is the ofthe RoboCube and uses communicate with the monitor over a serial interface and a ...
Voir plus Voir moins

Vous aimerez aussi

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 execute all these steps, but this has several drawbacks. First, a batch file could
handle only one input file at a time and so a bigger program split into several modules would
require a complicated batch file. Second, writing a batch file that automatically handles error
output of the different compile stages is complicated. And third, a batch file would always
recompile all input files, even if they didn’t change. How to avoid all these problems by using
a Makefile is described in the next chapter.
6Chapter 3
To make or not to make
Themake program is a tool that takes a rules file as input and decides if certain files have to
be recompiled to fulfill these rules. Make reads these rules from a file calledMakefile.
A Makefile rule has the following format:
file.y: file.x
command -o file.y file.x
The first line contains the dependency information: file.y is dependent of file.x, if file.x has a
modification date that is newer than the one of file.y, file.x has to be remade. The second line
defines the command that is used to update file.y
Notice that the first character of the second line has to be a TAB character. Make uses this char-
acter to distinguish the dependency information in the first line from the command information
in the second line.
By startingmake file.y, make would check for the modification dates. If file.y is older than
file.x,make would then executecommand -o file.y file.x and file.y would eventu-
ally be updated.
The dependency line can also occur without the command line:
all: file.y
This means that the file all depends of the file file.tw. The all file is a special file that is
never created. It’s the file that make tries to create when it’s started without any argument. This
opens the possibility to just start make without any arguments to compile the program, and
some Unix editors have exactly this feature as an internal command.
Although the features described here would fulfill all our requirements, make still more fea-
tures. It is possible to declare variables in a makefile:
CFLAGS= -gcoff
INCLUDES= -Idirectory
HEADERS= file.h
CFLAGS+= $(INCLUDES)
file.o: file.c $(HEADERS)
m68k-coff-gcc $(CFLAGS) -o file.o file.c
7This makefile presents some common uses of variables in makefiles. The first four lines define
variables, the fourth line also uses the value of an already defined variable to define another
one. The semantics of the += assignment is string concatenation, so the content of the line
after the+= is appended to the original value to form the new value. The value of a variable is
used by using$(VARIABLENAME). This expression can be used in all parts of the makefile
including variable definitions, dependency information and commands.
Make can also use generic rules for converting files:
CC=m68k-coff-gcc
CFLAGS=
all: file.o
.c.o:
$(CC) $(CFLAGS) -c $< -o $@
The dependency information .c.o defines the dependency of all .o files from their corresponding
.c files.$> is the expanded name of the input file,$@ is the expanded name of the output file.
This makefile, when called, would createfile.o fromfile.c if necessary.
Makefiles can also include other makefiles. Much like the#include preprocessor statement
in C, a line include otherfile would replace the line by the content of otherfile
while processing the makefile.
Figure 3.1 presents a makefile for CubeOS user programs which uses all these features of Make.
8BASETYPE=RC99BASE
PREFIX=/projects/cube/src
TOOLS=/projects/robot/tools
include $(PREFIX)/make.in
HEADERS = icontrol.h sincos.h sai_motor.h basics.h communic.h \
potarea.h strategies.h
INCLUDES = -I$(PREFIX)/basic -I$(PREFIX)/hardware -I$(PREFIX)/drivers += -I$(PREFIX)/drivers/tpu -I$(PREFIX)/drivers/i2c
INCLUDES +=ivers/fastbin
CFLAGS+= $(INCLUDES) -I. -O2 -DUSE_$(BASETYPE)
SFLAGS+= -gcoff
AFLAGS= -I$(PREFIX)/basic -I$(PREFIX)/hardware
OBJ-crt0=$(PREFIX)basic/crt0.o
OBJ-INIT=init.o icontrol.o sincos.o icontrolWrapper.o readcmd.o \
communic.o potarea.o strategies.o
LINKSCRIPT=$(PREFIX)/cubeos.ld_lib
LIB=$(PREFIX)/libcubeos.a
all: init.abs init.tw
.c.o:
$(CC) $(CFLAGS) -c $< -o $@
.S.o:
$(CC) $(SFLAGS) -c $< -o $@
.coff.d:
$(OBJDUMP) -d $< >$@
init.coff: $(LIB) $(OJB-crt0) $(OBJ-INIT) $(LINKSCRIPT)
$(LD) $(LD_OPT) -nfp -Map $*.map -L$(PREFIX) -o $@ $(OBJ-INIT) \
-T$(LINKSCRIPT)
.coff.abs:
$(OBJCOPY) -O srec $< $@
.abs.tw:
$(TOOLS)/s2tw $< $@
clean:
-rm *.o *.coff *.abs *.bin *.d *.map *.tw
Figure 3.1: The Makefile for CubeOS User Programs
9Chapter 4
Usefull programs
Now that we can write and run programs, how can we do something useful on the RoboCube?
Of course, we could use the serial console for input and output and then run arbitrary programs
on the RoboCube. A lot of embedded systems are used in exactly this way for doing protocol
conversions for industry applications. But the RoboCube is about robotics, so we have to deal
with other i/o than the serial port.
The Robocube has several inputs and outputs. These are connected in various ways, so let’s
first put in some methodology.
In it’s basic configuration, the RoboCube has four different types of i/o ports.
1. Binary i/o
2. Analog inputs
3. Analog outputs
4. TPU channels
Let’s first start with the binary i/o. Each of the cube’s binary i/o chip has eight i/o pins. Writing
th internal register of the chip forces the output pins to voltage levels corresponding to the
logical values of the eight bits in the port register. Reading the internal register puts the pins
into input mode and copies the electrical state of the pins into the register. The register
is then read by the CPU.
Analog inputs and outputs use dedicated pins. When the CPU reads an analog input, the i/o
chip converts the voltage on its corresponding input pin into an eight-bit digital value. When
the CPU writes an analog output, the i/o chip converts the eight-bit-value into an output voltage
on the corresponding output pin.
The TPU channel is an example for an intelligent i/o device. The electrical interface of a TPU
channel is similar to the one of a binary i/o pin. However, the logical interface is much more
complicated. A tpu channel can be used to measure time, to generate pulses, to count events
and several other things.
The i/o ports are connected to the tpu via different busses. The TPU channels are directly
mapped into the RoboCube’s main memory, so they can be accessed by simple reads and writes.
10

Un pour Un
Permettre à tous d'accéder à la lecture
Pour chaque accès à la bibliothèque, YouScribe donne un accès à une personne dans le besoin