Challenge a Process Program with T-Engine


There is something amazing with the recent progress in electronic devices. Without mentioning cell-phones, in fields such digital home appliances and automotive devices, high-level products equipped with various types of sensors and storage, and network functions are rapidly expanding their share.

Against this sort of background, a great wave of change is visiting itself even in the world of embedded software. In a questionnaire survey targeted at embedded technicians, in contrast to the fact that the percentage of software with a size exceeding 4 megabytes was less than 10 percent at the stage of 1998, in 2006, this percentage had become as much as 27 percent [Note 1]. The system scale on the one hand is becoming enormous. In spite of this, in the development period, greater shrinkage is being sought. How to efficiently develop software that exceeds megabyte size is an issue that many software technicians are now at this moment confronting. One solution to this is software development based on a process base programming model.

Figure 1. Task base program

What Is a Process?

Almost all the embedded software that runs on the conventional ITRON and T-Kernel has been designed and implemented with a task base programming model. This is something in which we realize the functions of the overall system while finely dividing each function of the software into execution units called tasks, and carrying out communications and synchronization among the various tasks. Its adaptability to small- and medium-scale systems is high, and it has generally been used in conventional embedded software for such things as equipment control and home appliances (Fig. 1). However, with the highly functional systems of recent years, there are also ones in which the number of tasks reaches several tens to several hundreds, and thus designing this type of software as a simple task base program is very difficult. For that reason, the process base programming model, in which adding to the conventional model we import the concept of the "process" that groups together tasks for each function and realizes system functions by means of synchronization and communications among processes, is attracting attention (Fig. 2).

Figure 2. Process base program

The Merits of a Process

The following two points can be given as the characteristics of a process base program.

(1) Memory Protection of Process Units

Processes respectively possess independent memory spaces, and thus they cannot access memory regions of other processes or the operating system. Accordingly, even if one process runs away due to a flaw, there will be no instance of it destroying a memory region outside of the process that ran away (Fig. 3).

Figure 3. Characteristic (1) memory protection of process units

(2) Dynamic Process Creation and Deletion

In accordance with need, it is possible to dynamically create processes from execution files stored in the file system. In addition, it is also possible to delete processes that have become unnecessary. (Fig. 4).

Figure 4. Characteristic (2) Dynamic process creation and deletion

By means of dynamic process creation and deletion, we can reduce the required amount of memory in the system, because the need to expand the software in its entirety once onto memory disappears. In addition, in cases where we must also carry out updating, such as in countermeasures for flaws and function addition, we can cope just by changing the execution file of the corresponding process, without modifying the overall software.

By means of these characteristics, it comes about that we can carry out the design and development of complex software not just with execution units (tasks), but with function units (processes).

Moreover, with large-scale systems, development normally moves forward in parallel on the basis of multiple groups. In this type of case also, it becomes possible to drastically reduce the labor in the final combination work by means of the respective groups creating programs as processes (Fig. 5).

Figure 5. Development carried out in parallel by multiple groups

T-Kernel Standard Extension

The mechanism for running on top of T-Engine process programs that possess these kinds of merits is T-Kernel Standard Extension (TKSE). TKSE is one extension program of T-Kernel (T-Kernel Extension), and it adds to T-Kernel the various functions that become necessary in a process program. Moreover, virtual memory is also supported as a standard feature, and it is made up into a specification that assumes that it will be widely used as a large-scale software development platform.

In that case, let's now actually obtain TKSE and take a look at the procedures up to making it run on top of T-Engine.

(1) Preparation of the Hardware

First, prepare the necessary hardware.

There are six models of T-Engine on which TKSE is supported as a standard feature. As SH-line, ARM-line, and MIPS-line T-Engines all exist, it would probably be best to select one close to a CPU we normally often use. In this article, we use the T-Engine/SH7727.

In order to build a program, a PC on which we have installed a T-Engine development kit (GNU development environment) attached to the T-Engine is necessary. We would like you to install the T-Engine development kit in a PC prepared with the same environment as Linux, with something like Linux or Cygwin.

This is necessary in order to store the execution file of the program that has been built and make it run on top of T-Engine. Because obtaining the ATA PC card itself is difficult at present, we can substitute by means of a compact flash card and a card adapter.

(2) Obtaining the Software

Next, we will obtain the necessary software from the home page of the T-Engine Forum (Fig. 6 [TN1]).

Figure 6. T-Engine Forum home page

When downloading the software, user registration becomes necessary. When you agree with the license called T-License and register your user information, an ID and password will be sent to you, so use this to obtain the various software.

Not just software, but various specifications also can be obtained via the home page of the T-Engine Forum.

Those who would like to know the specification for device drivers, should also obtain

for future use. Each specification can be freely downloaded without user registration.

(3) Expanding the Archive

When the hardware and software preparations have been completed, first expand the software archive.

We expand T-Kernel and TKSE on a PC in which we have installed the T-Engine development kit. Place the T-Kernel and TKSE archives that you downloaded into the directory you'd like to expand them into, and then expand with the tar command. Below, the archive name "X.YY.ZZ" shows the version.

> tar xfz tkernel.X.YY.ZZ.tar.gz
> tar xfz tkernel_se_X.YY.ZZ.tar.gz
> ls
tkernel_source
tkernel_se_source

Next, we overwrite on T-Kernel the TKSE source code.

> cp -r tkernel_se_source/* tkernel_ source

It doesn't matter whether you erase the TKSE directory from after the overwrite.

> rm -r tkernel_se_source

At this time, set the directory in which you expanded T-Kernel in the shell environment variable $BD. In a case where you have expanded T-Kernel into /home/user/, it becomes $BD=/home/user/tkernel_source.

In order to make it so that you can use a FAT or CD-ROM file system with TKSE, we embed the extended file system. On this occasion, we will explain the method for embedding FAT, but the embedding procedures are the same also in the case of a CD-ROM.

First, we expand the FAT extended file system attached to TKSE.

> tar xfz extfs_fatfs_X.YY.ZZ.tar.gz
> ls
extfs_fatfs

Next, we copy the extfs_fatfs/seio/ file into the SEIO source directory of TKSE.

> cp -r extfs_fatfs/seio/* $BD/tkse/ extension/seio/src/extfs/

We copy the extfs_fatfs/include/ file in the same manner.

> cp -r extfs_fatfs/include/* $BD/tkse/ include/sys/

After copying, because the expanded directory extfs_fatfs becomes unnecessary, it doesn't matter if you delete it.

> rm -r extfs_fatfs

In order to make the extended file system that we copied valid, we change the TKSE source code. The portion in bold below is the code that we add.

$BD/tkse/extension/seio/src/extfs/fsinfo.c

EXPORT FS_ENT
fs_def_tbl[] = {
    { SF_STDFS, (FP)sf_attach, size of(FS) },
    { SF_FATFS, (FP)fat_attach, size of(FATFS) },
          { 0, NULL, 0 }
};

$BD/tkse/extension/seio/src/extfs/fsdefine.h

/* Include a header file for file system extension. */
#include <sys/fatfs.h>
#include "ext_fatfs.h"

$BD/tkse/extension/seio/build/Makefile.common

SRC += main.c fileio.c inode.c uroot.c ustdio.c stdfs.c \
            ltf_id.c ltf_lib.c unitotc.c \
            fsconnect.c fsinfo.c \
            ext_fatfs.c

Last, we expand the TKSE sample driver archive.

> tar xfz tkse_sample_drv_X.YY.ZZ. tar.gz
> ls
tkse_drv

We copy the expanded directory into TKSE.

> cp -r tkse_drv/* $BD

As the expanded directory becomes unnecessary, it doesn't matter if you delete it.

> rm -r tkse_drv

We add into the T-Kernel build file the library the same driver will use (libstr).

$BD/kernel/usermain_tkse/Makefile.common

# additional libraries
LDUSRLIBS += -ldrvif -lconsolesvc -lcardmgrsvc -lstr

With this, the job of archive expansion is ended.

(4) Building the Software

When the expansion is finished, we at last carry out the building of TKSE.

First, we build from the T-Kernel library.

> cd $BD/lib/build/std_sh7727
> make

Because it builds by collecting together various types of libraries, it will come to take its time for a while until the processing finishes.

We build the TKSE library in the same manner. Here also, it will take its time for a while until it is finished.

> cd $BD/tkse/lib/build/std_sh7727
> make

Before we build the main body of the sample driver, we build an interface library that the driver will use.

> cd $BD/lib/libdrvif/build/std_sh7727
> make
> make install

In order to install the library we have built in the prescribed location, after executing make, there is the need to do make install.

After installation of the library, we carry out building of the sample driver. What we will build are four things: a PCMCIA card manager, a console driver, a clock driver, and a system disk driver. For things that run as subsystems, before executing make, it is necessary to automatically create the interface source code with make source, so caution therefore is required.

Building of the PCMCIA card manager:

> cd $BD/drv/std_sh7727/cardmgr/build
> make source
> make
> make install

Building of the console driver:

> cd $BD/drv/std_sh7727/console/build
> make source
> make
> make install

Building of the clock driver:

> cd $BD/drv/std_sh7727/clk/build
> make
> make install

Building of the system disk driver:

> cd $BD/drv/std_sh7727/sysdsk/build
> make
> make install

Building TKSE

If the preparations up to here have concluded, you can build the main body of TKSE.

> cd $BD/tkse/build/std_sh7727
> make

When you succeed in building, the T-Kernel execution file is created as kernel_rom.mot.

Finally, we build the ROM information that carries out TKSE configuration. On this occasion, because we are only making a simple application run, there is no need to change the configuration.

> cd $BD/config/tkse/build/std_sh7727
> make

If rominfo.mot is created, then the building is a success.

We write the TKSE that we built into the T-Engine flash memory via the serial. By carrying out this work, it will come about that TKSE will start up immediately when we turn on the T-Engine power supply.

First, we connect the PC and T-Engine with the serial cable attached to the development kit, and then we start up the terminal software compatible with the serial connection. After the serial connection, when we start up T-Engine while pressing the NMI switch, we output he prompt below and change into T-Monitor mode.

TM>

Here, we execute the flash write-in command FLLO.

TM> FLLO
Copy Flash ROM Image to RAM Area
> Load S-Format Data of Flash ROM

When this display appears, we transmit in ASCII data transfer [with XON-XOFF flow control] kernel_rom.mot from the terminal software. When we succeed in file transmission and flash write-in, we return to the T-Monitor prompt.

In the same manner, we carry out the write-in of rominfo.mot also.

By the above, the preparation of TKSE is finished. After resetting the T-Engine, if a display of the following type appears, the preparation of TKSE will become finished.

T-Kernel Version 1.02.02
T-Kernel / Standard Extension Sample Shell
ConsoleIO - OK
ClockDrv - OK
CardMgr - OK
SysDiskDrv - OK
disk name ?

Let's Try Running a Process Program with TKSE

Once the preparation of the execution environment is ready, let us without delay try creating a process program. On this occasion, we will create a simple application, one in which we only write text data into a file.

(1) Preparation of the Data

For TKSE application building, we create a directory in which we have attached a program name to $BD/appl, and then carry it out below that. On this occasion, we shall make the program name "filewrite."

First, we create a directory in the manner below. Below filewrite is the directory we create.

$BD/
    appl/
        filewrite/
          src/
          build/
            std_sh7727/

Here, we call the "src" below filewrite the source directory, and "build" the build directory.

(2) Creation of the Build Environment

Directly below the build directory, we create the type-common build file Makefile.common, and the type-dependent build file Makefile in build/std_sh7727. Their respective contents are listed in the attachments to this article.

By changing Makefile.common, you can carry out modification of the program name, and make changes and additions to the source files and the libraries you link to.

(3) Creating the Source File

Directly below the source directory, we create the program source file main.c. These contents also are listed in the attachments to this article. Concerning the system calls that are used inside the program, we would like you to refer to the TKSE specification, because we will not explain them on this occasion.

(4) Building the Program

When the build environment and the preparation of the source file are ready, we move to the build directory build/std_sh7727 and execute make.

> cd $BD/appl/filewrite/build/std_ sh7727
> make

When you succeed at building, the execution file filewrite is created in the current directory.

(5) Let's Try Running It

We copy the the execution file filewrite onto an ATA PC card formatted in FAT format. When we insert this card into T-Engine, turn on the power supply, and specify "pca0" for the disk name, the card will be connected as the file system. We would then like you to try confirming that the execution file exists via the ls command.

T-Kernel Version 1.02.02
T-Kernel / Standard Extension Sample Shell
ConsoleIO - OK
ClockDrv - OK
CardMgr - OK
SysDiskDrv - OK
disk name ? pca0
FATFS OK
>>> ls
filewrite
>>>

When you input the name of the execution file in this state, that file is executed as a process program. After execution, let's try confirming the file list once again with the ls command.

>>> filewrite
>>> ls
filewrite
writeout.txt
>>>

If a file called writeout.txt is created, then it is successful. Let's try checking the contents of the card with a PC, and confirm that the text data are properly written into the file.

____________________

Above, we gave an introduction of TKSE, from obtaining it and the method for building it, up to the creation and execution of a simple process program. From the next installment and in later installments, we plan to take up at irregular intervals process program techniques, such as the creation of child processes and communication between process.

Attachments

We list in the attachments the source code main.c (List 1), the build file Makefile (List 2), and Makefile.common (List 3) of the application that we created on this occasion.

List 1 main.c
/*
* filewrite
* TKSE sample application
*/
/*
* main.c
* program main routine
*/
/* When using TKSE include extension.h at the beginning. */
#include <extension/extension.h>
/* You include when doing file control with SEIO. */
#include <extension/seio.h>
#include <seio/sys/stat.h>
/* Other header file */
#include <string.h>

/* File path (SYS is the default connection name) */
#define FILE_PATH (const char *)"/SYS/writeout.txt"
/* Character string to be written into the file */
const char write_data[] = "Welcome to T-Engine!";

/* Main function of the process */
EXPORT INT
main(W ac, TC *av[])
{
        INT fd; /* File identifier */
        /* Create file and open in write-in mode */
        fd = tkse_creat(FILE_PATH, S_IRWXU);
        /* Write the character string into the file */
        tkse_write(fd, write_data, strlen(write_data));
        /* Close the file */
        tkse_close(fd);
        /* Terminate the process */
        return 0;
}

List 2 Makefile
# filewrite
# TKSE sample application
# Makefile (Type [model] dependent parts)
# Type of T-Engine
MACHINE = sh7727
TETYPE = std
# Specification of default rules
include $(BD)/appl/etc/makerules
# Source file of type dependencies
SRC =
# Calling up Makefile of common parts
include ../Makefile.common

List 3 Makefile.common
#       filewrite
#       TKSE sample application
#       Makefile.common (Common parts)
DEPS = Dependencies
DEPENDENCIES_OUTPUT := $(DEPS)
# ----- Normally change only this range ----------------------------
### Program name ###
TARGET = filewrite
### Relative path of source directory ###
S = ../../src
### When adding the path of the source file, we add it to VPATH. ###
VPATH := $(S)/sysdepend/$(TETYPE)_$(MACHINE) $(S)
### When adding the path of the ehader file, we add it to HEADER. ###
HEADER += $(S)/sysdepend/$(TETYPE)_$(MACHINE) $(S)
### Specification of the source file ###
SRC += main.c
### When adding the compile option, we add it to CFLAGS. ###
CFLAGS += $(CFLAGS_WARNING) -DPROCESS_BASE -Wall
### When adding libraries to link to, we add them to LOADLIBES. ###
LOADLIBES += -Wl,-\( -ltm -ltkse -lg -ltcstr -Wl,-\)
# -------------------------------------------------------
OBJ = $(addsuffix .o, $(basename $(SRC)))

.PHONY: all clean
ALL = $(TARGET) $(TARGET:%=%.map)
all: $(ALL)
$(TARGET): $(OBJ)
→        $(LINK.o) $(LDOBJS) $^ $(LOADLIBES) $(LDLIBS) $(OUTPUT_OPTION)
$(OBJ):
clean:
→        $(RM) $(OBJ) $(ALL) $(DEPS)
# Source file dependencies relationships
ifdef DEPENDENCIES_OUTPUT
$(DEPS): ; touch $(DEPS)
else
$(DEPS): $(SRC) ; $(MAKEDEPS) $@ $?
endif
include $(DEPS)

____________________

[Note 1] FY 2006 Questionnaire Survey Report Concerning Trends in Real Time OS Use in Embedded Systems, TRON Association (2007)

FY2006 Questionnaire Survey Report Concerning Trends in the Use of Real-Time OSs in Embedded Systems (in Japanese)

[Translator's Note 1] Fig. 6 was copied from the T-Engine Forum's Web site on September 1, 2008, because the original figure was in Japanese. As the reader can see, the present contents of the page in question are different from those mentioned in the article.


The above article on process programming with T-Engine appeared on pages 46-52 in Vol. 111 of TRONWARE. It was translated and loaded onto this Web page with the permission of Personal Media Corporation.

Copyright © 2008 Personal Media Corporation

Copyright © 2008 Sakamura Laboratory, University Museum, University of Tokyo