Embedded Robotics (Thomas Braunl, 2 ed, 2006)

Compiler for C and C++

Hello World Before discussing the commands (shell-scripts) for compiling a C or C++ source program, let us have a look at the standard “hello world” program in Program A.1. The standard “hello world” program runs on the EyeCon in the same way as on an ordinary PC (note that ANSI C requires main to be of type int). Library routine printf is used to write to the controller’s LCD, and in the same way, getchar can be used to read key presses from the controller’s menu keys.

Program A.1: “Hello World” program in C

1#include <stdio.h>

2int main ()

3{ printf("Hello !\n");

4return 0;

5}

Program A.2 shows a slightly adapted version, using RoBIOS-specific commands that can be used in lieu of standard Unix libc-commands for printing to the LCD and reading the menu keys. Note the inclusion of eyebot.h in line 1, which allows the application program to use all RoBIOS library routines listed in Appendix B.5.

Program A.2: Extended C program

1#include "eyebot.h"

2int main ()

3{ LCDPrintf("Hello !\n");

4LCDPrintf("key %d pressed\n", KEYGet());

5return 0;

6}

Assuming one of these programs is stored under the filename hello.c, we can now compile the program and generate a downloadable binary:

>gcc68 hello.c -o hello.hex

This will compile the C (or C++) source file, print any error messages, and

– in case of an error-free source program – generate the downloadable output file hello.hex. This file can now be downloaded (see also Section A.5) with

363

A Programming Tools

the following command from the host PC to the EyeCon controller via a serial cable or a wireless link:

>dl hello.hex

On the controller, the program can now be executed by pressing “RUN” or stored in ROM.

Optionally, it is possible to compress the generated hex-file to the binary hx-format by using the utility srec2bin as shown in the command below. This reduces the file size and therefore shortens the time required for transmitting the file to the controller.

>srec2bin hello.hex hello.hx

The gcc GNU C/C++ compiler has a large number of options, which all are available with the script gcc68 as well. For details see [GNU 2006]. For compilation of larger program systems with many source files, the Makefile utility should be used. See [Stallman, McGrath 2002] for details. Note that if the output clause is omitted if during compilation (see below), then the default C output filename a.out is assumed:

>gcc68 hello.c

A.3 Assembler

Since the same GNU cross-compiler that handles C/C++ can also translate Motorola 68000 assembly programs, we do not need an additional tool or an additional shell-script. Let us first look at an assembly version of the “hello world” program (Program A.3).

Program A.3: Assembly demo program

We include eyebot.i as the assembly equivalent of eyebot.h in C. All program code is placed in assembly section text (line 2) and the only label visible to the outside is main, which specifies the program start (equivalent to main in C).

The main program starts by putting all required parameters on the stack (LCDPutString only has one: the start address of the string). Then the

364

Assembler

Program A.4: Calling assembly from C

1#include "eyebot.h"

2int fct(int); /* define ASM function prototype */

4int main (void)

5{ int x=1,y=0;

6y = fct(x);

7LCDPrintf("%d\n", y);

8return 0;

9 }

The more common way of calling an assembly function from C is even more flexible. Parameters can be passed on the stack, in memory, or in registers. Program A.4 shows an example, passing parameters over the stack.

From the C program (top of Program A.4) the function call does not look any different from calling a C function. All parameters of a function are implicitly passed via the stack (here: variable x). The assembly function (bot-

365

A Programming Tools

tom of Program A.4) can then copy all its parameters to local variables or registers (here: register D0).

Note that an assembly routine called from a C function can freely use data registers D0, D1 and address registers A0, A1. Using any additional registers requires storing their original contents on the stack at the beginning of the routine and restoring their contents at the end of the routine.

After finishing all calculations, the function result (here: x+1) is stored in register D0, which is the standard register for returning a function result to the calling C routine. Compiling the two source files (assuming filenames main.c and fct.s) into one binary output file (demo.hex) can be done in a single command:

>gcc68 main.c fct.s -o demo.hex

A.4 Debugging

The debugging system BD32 (Figure A.1) is a free program for DOS (also running under Windows) utilizing the M68332 controller’s built-in “background debugger module” (BDM). This means it is a true hardware debugger that can stop the CPU, display memory and register contents, disassemble code, upload programs, modify memory, set breakpoints, single-step, and so on. Currently, BD32 is only available for DOS and only supports debugging at assembly level. However, it may be possible to integrate BDM with a Unix source-level debugger for C, such as gdb.

Figure A.1: Background debugger

366

Debugging

Whenever the debugger is used, the EyeCon controller has to be connected to the parallel port of a Windows-PC using a BDM-cable. The actual debugging hardware interface is included on the EyeCon controller, so the BDMcable contains no active components. The main uses for the BD32 debugger are:

•Debugging an assembly program.

•Rewriting a corrupted flash-ROM.

Debugging When debugging an assembly program, the program first has to be loaded in memory using the button sequence Usr/Ld on the controller. Then, the BD32 debugger is started and the CPU execution is halted with the command

STOP.

The user program is now located at the hex address $20000 and can be viewed with the disassemble debugger command:

dasm $20000

To go through a program step by step, use the following commands:

367

A Programming Tools

flash 11000000 rob52f.hex 0

Delete RoBIOS in flash-ROM, overwrite with new version (bit string 11111111 can be used instead, to delete all sectors in the flash-ROM, including user programs). This process takes a few minutes.

flash 00000000 hdt-std.hex $1c000

Without deleting any flash-ROM sectors, write the HDT file at offset $1c000.

The parameters of the flash command are:

•Deletion of individual sectors:

Each flash-ROM has eight sectors; specifying a “1” means delete, specifying a “0” means keep.

•Filename of hex-file to be written to flash-ROM.

•Address-offset:

RoBIOS starts at address 0 in the ROM, the HDT starts at $1c000.

Note that because of the flash-ROM sector structure, only complete sectors can be deleted and overwritten. In the case of a corrupted RoBIOS, both RoBIOS and HDT need to be restored. In the case of a corrupted HDT and intact RoBIOS, the HDT can be restored by flashing it to the to the first user program slot at offset $20000. During restart, RoBIOS will detect the updated HDT and re-flash it as part of the operating system ROM sector:

flash 00100000 hdt-std.hex $20000

After rewriting the flash-ROM, the EyeCon needs to be reset of switched off and on again. It will then start with the normal greeting screen.

A.5 Download and Upload

Download For downloading a program, the EyeCon controller needs to be connected to a host PC via a standard serial cable (nine-pin RS232). Data transmission is possible at a number of different baud rates with default value 115,200 Baud. Executable programs can be transmitted as ASCII “.hex” files following the Motorola S-record format, or faster as compressed binary “.hx” files. The RoBIOS system tool srec2bin transforms hex-files to hx-files and vice versa.

To start a user program download from the host PC to the EyeCon, the data transfer has to be initialized on both sides:

•On the EyeCon:

Press Usr / Ld

(The LCD screen will indicate that the controller is ready to receive data. Download progress is indicated graphically and in the number of bytes transmitted.)

368

References

•On the host PC:

Use the command dl for download:

>dl userprog.hx

Upload Besides downloading executable programs, it is also possible to transfer data under program control either from the PC to the EyeCon or from the EyeCon to the PC. For uploading a block of data to the PC, the shell-script ul can be used instead of dl. A number of more elaborate example programs are available on the web to illustrate this procedure, for example for uploading images or measurement data [Bräunl 2006].

Turn-key system A turn-key system can be created if the uploaded program name is either startup.hex or startup.hx (for compressed programs). The program has to be stored under this name in one of the three ROM slots. At start-up, RoBIOS will then bypass the standard monitor program and directly execute the user program. If the user program terminates, the RoBIOS monitor program will become active.

In case of a user program error like an endless loop, it would seem impossible to return to the monitor program in order to undo the turn-key setting and delete the user program, unless resorting to the background debugger. In order to solve this problem, it is possible to hold down one of the user buttons during start-up. In this case, the turn-key system will be temporarily deactivated and the regular RoBIOS monitor program will start.

A.6 References

BRÄUNL, T., EyeBot Online Documentation,

http://robotics.ee.uwa.edu.au/eyebot/, 2006

GNU. GNU Compiler, http://www.delorie.com/gnu/docs/, 2006

HARMAN, T. The Motorola MC68332 Microcontroller - Product Design, Assembly Language Programming, and Interfacing, Prentice Hall, Englewood Cliffs NJ, 1991

STALLMAN, R., MCGRATH, R. Make: A Program for Directed Compilation, GNU Press, Free Software Foundation, Cambridge MA, 2002

369

B.1 Monitor Program

On power-up of the EyeCon controller, RoBIOS is booted and automatically starts a small monitor program which presents a welcome screen on the LCD and plays a small tune. This monitor program is the control interface for RoBIOS. The user can navigate via the four keys through numerous information and settings pages that are displayed on the LCD. In particular, the monitor program allows the user to change all basic settings of RoBIOS, test every single system component, receive and run user programs, and load or store them in flash-ROM.

Following the welcome screen, the monitor program displays the RoBIOS status screen with information on operating system version and controller hardware version, user-assigned system name, network ID, supported camera type, selected CPU frequency, RAM and ROM size with usage, and finally the current battery charge status (see Figure B.1).

All monitor pages (and most user programs) use seven text lines for displaying information. The eighth or bottom display line is reserved for menus that define the current functionality of the four user keys (soft keys). The pages that can be reached by pressing buttons from the main status page will be discussed in the following.

B.1.1 Information Section

The information screen displays the names of people that have contributed to the EyeBot project. On the last page a timer is perpetually reporting the elapsed time since the last reset of the controller board.

371371

B RoBIOS Operating System

>RoBIOS 6.5 M5<

----------------

SocBot 03 Cam:f 35MHz 512K ROM 896Kf 1024K ROM

Battery-Status

<I> Hrd Usr Demo

Figure B.1: RoBIOS status page and user keys

By pressing the REG-labelled key, a mask is displayed that shows the serial number of the controller and allows the user to enter a special keyword to unlock the wireless communication library of RoBIOS (see Chapter 6). This key will be saved in the flash-ROM so that it has to be entered only once for a controller, even if RoBIOS is being updated.

B.1.2 Hardware Settings

The hardware screens allow the user to monitor, modify, and test most of the on-board and off-board sensors, actuators, and interfaces. The first page displays the user-assigned HDT version number and a choice for three more submenus.

The setup menu (Set) offers two sections that firstly (Ser) deal with the settings of the serial port for program downloads and secondly (Rmt) with settings of the remote control feature. All changes that are made in those two pages are valid only as long as the controller is supplied with power. The default values for the power-up situation can be set in the HDT as described in Section B.3.

For download, the interface port, baud rate, and transfer protocol can be selected. There are three different transfer protocols available that all just differ in the handling of the RTS and CTS handshake lines of the serial port:

•NONE Completely disregard handshaking.

•RTS/CTS Full support for hardware handshaking.

•IrDA No handshaking but the handshake lines are used to

select different baud rates on an infrared module.

For wireless communication, the interface port and the baud rate can be selected in the same manner. In addition, specific parameters for the remote control protocol can be set. These are the network unique id-number between 0 and 255, the image quality, and the protocol. The protocol modes (to be set in the HDT file) are:

•RADIO_BLUETOOTH Communication via a serial Bluetooth module.

•RADIO_WLAN Communication via a serial WLAN module.

372

Monitor Program

•RADIO_METRIX Communication via a serial transceiver module.

The image quality modes are:

•Reduced Images are sent in reduced resolution and color depth.

The second sub-menu (HDT) of the hardware settings page displays a list of all devices found in the HDT that can be tested by RoBIOS. For each device type, the number of registered instances and their associated names are shown. Currently nine different device types can be tested:

•Motor

The corresponding test function directly drives the selected motor with user-selectable speed and direction. Internally it uses the MOTORDrive function to perform the task.

•Encoder

The encoder test is an extension of the motor test. In the same manner the speed of the motor linked to the encoder is set. In addition, the currently counted encoder ticks and the derived speed in ticks per second are displayed by internally calling the QUADRead function.

•vZ Interface

This test is somewhat more “high level” since it utilizes the vZ interface for differential drives, which is based upon the motor and encoder drivers. Wheel distance and encoder IDs are shown, as stored in the HDT. By pressing the Tst-labelled key, vZ commands to drive a straight line of 40cm, turn 180° on the spot, come back in a straight line, and turn 180° again are issued.

•Servo

In analogy to the motor test, an angular value between 0 and 255 can be entered to cause an attached servo to take the corresponding position by using the SERVOSet function.

•PSD

The currently measured distance value from the selected PSD is displayed graphically in a fast scrolling fashion. In addition, the numeric values of raw and calibrated sensor data (through a lookup table in the HDT) are shown by using functions PSDGetRaw and PSDGet.

•IR

The current binary state of the selected sensor is permanently sampled by calling IRRead and printed on the LCD. With this test, any binary sensor that is connected to an HDT-assigned TPU channel and entered in the HDT can be monitored.

•Bumper

The precise transition detection driver is utilized here. Upon detection of a signal edge (predefined in the HDT) on the selected TPU channel

373