The stub file is used to specify the control, notify, ready and connect methods
specified in the previous sections. In addition to these 4 methods, the stub.cfg also
specifies member functions that receive messages.
A Sample stub.cfg file has been included below:
ObjectName : SampleClass
NumOfOSubject : 1
NumOfOObserver : 2
Service : "SampleClass.Func1.Data1.S",Control(),Ready()
Service : "SampleClass.Func2.Data2.O",Connect(),Notify1()
Service : "SampleClass.Func3.Data2.O",Control(),Notify2()
Extra : WakeUpOnLan()
Extra : UpdateBatteryStatus()
A Breakdown of the format gives:
ObjectName
Name of the core class
NumOfOSubject
Number of Subjects. Minimum of 1 subject is necessary. If there are no subjects
needed you have to register a dummy subject.
NumOfOObserver
Number of Observers. Minimum of 1 observer is necessary. If there are no
observers needed you have to register a dummy observer.
Service:
This describes the various types if messages that is passed between the subject
and its observers. The general format of a service is given here:
¡§(ObjectName).(Subname).(Data Name).(Service Type)¡¨,memb_func1(), memb_func2( )
Subname
This is a unique name for every service.
Data Name
The data-type used in the communication
Service Type
S (for subject) or O (for Observer)
Below is the flow of building objects and creating an executable file.
.ocf
A file with an ¡§.ocf¡¨ extension is used to specify the configuration of the object.
An .ocf file must have the following format.
object OBJECT_NAME STACK_SIZE HEAP_SIZE SCHED_PRIORITY CACHE TLB MODE
Example:
____________________________________________________________________
object helloWorld 3072 16384 128 cache tlb user
____________________________________________________________________
You can specify the following parameters:
# OBJECT_NAME
The name of the object.
# STACK_SIZE
The size of the stack, in bytes, for the object. The stack is not extended at
runtime. If an object uses more stack space than the specified size (by declaring
large amounts of automatic variables, doing deeply nested function calls, etc.),
the result is undefined.
# HEAP_SIZE
If an object runs out of heap space, the heap is extended by this amount (in
bytes). A heap is an area for allocating memory requested by the malloc() or
new operator.
Because extending the heap is a costly operation, specifying a HEAP_SIZE
value that is too small slows down the object by forcing frequent heap resizing.
# SCHED_PRIORITY
The scheduling priority of the object, represented as an eight-bit unsigned
integer. The upper four bits specify the scheduling class; an object with a lower
class never runs while an object with a higher class is running. The
recommended scheduling class for an ordinary application is 8 (128 in
scheduling priority) or lower. The lower four bits control the ratio of execution
time between objects within the same scheduling class. The higher the value,
the more time the object gets.
# CACHE
Specify ¡§cache¡¨ or ¡§nocache¡¨. If ¡§nocache¡¨ is specified, cache memory in the
processor is disabled while executing the object. Specifying ¡§cache¡¨ is
normally recommended.
# TLB
Specify ¡§tlb¡¨ or ¡§notlb¡¨. If ¡§tlb¡¨ is specified, the memory area for the object is
allocated in the virtual address space. Otherwise, the memory area is allocated
in the physical address space (KSEG0 or 1). This value is ignored when a
¡§nomemprot¡¨ configuration is used. Specifying ¡§tlb¡¨ is recommended. You
must specify ¡§tlb¡¨ if you specify ¡§user¡¨ for MODE.
# MODE
Specify ¡§kernel¡¨ or ¡§user¡¨. If ¡§user¡¨ is specified, the processor's execution
mode is set to user mode when the object is executed. Otherwise, the object is
executed in kernel mode. This value is ignored when a ¡§nomemprot¡¨
configuration is used. An object always runs in kernel mode in ¡§nomemprot¡¨
configuration.
StubGenerator
The ¡§Stubgen2¡¨ command reads stub.cfg and generates intermediate files to connect
the methods of an object with the member functions of a core class.
def.h is one file that is generated by Stubgen2. The following is the sample code of
def.h.
____________________________________________________________________
const int sbjFunc1 = 0;
const int obsFunc2 = 0;
____________________________________________________________________
¡§sbj¡¨ or ¡§obs¡¨ is added in the head of a subname described in stub.cfg.
The following is the definition of SampleClass.h.
____________________________________________________________________
OSubject* subject[numOfSubject];
OObserver* observer[numOfObserver];
____________________________________________________________________
sbjFunc1 and obsFunc2 are the indexes of the arrays to specify a subject and an
observer (Examples: subject[sbjFunc1]; observer[obsFunc2]).
Use the following command for compiling and assembling. The command is
common to both the C++ source files(.cc) and the assembly language source files
(.s).
/usr/local/OPEN_R_SDK/bin/mipsel-linux-gcc -c [other options] FILE
This creates an object file named XXX.o, where XXX is the base name of FILE. Be
sure to specify the -c option; without -c, gcc attempts to link files to form an
executable, and it fails. gcc for the OPEN-R SDK cannot perform linking. You
should use the mkbin command instead.
You can specify directories for header files using the -I option if necessary. For
example, you can include the OPEN-R header files using the following options.
-I/usr/local/OPEN_R_SDK/OPEN_R/include/R4000
-I/usr/local/OPEN_R_SDK/OPEN_R/include
Use the following command for linking object files.
/usr/local/OPEN_R_SDK/OPEN_R/bin/mkbin -o XXX.bin XXX.ocf
[other options] AAA.o BBB.o CCC.o ...
This links the object files AAA.o, BBB.o, CCC.o ... and creates an executable file
XXX.bin. A file with `.ocf' extension is used to specify the configuration of the
object.
Other options for mkbin, except listed below, are passed to the linker that is called
by mkbin. Refer to the manual of GNU ld for the options that can be passed to the
linker. In addtion to the options which are specified by the command line, mkbin
also passes the options for linking the default libraries to the linker. You can see
what option is passed to the linker by running mkbin with the -v flag.
mkbin creates several intermediate files that are not removed automatically. Their
names are listed in the description of the ¡Vo flags below. Do not use the same name
for your own file or it will be overwritten.
Below is a list of options processed by mkbin itself.
-o PATH
Specifies the path of the generated executable file. The default value is a.bin.
PATH is also used to determine the names of intermediate files, as follows:
1. Remove trailing .bin, if it exists.
2. Append one of the following strings to the result
of 1.
.snap.cc, .snap.o, .nosnap.elf, .snap.elf, .rel.elf
-m FILE
This specifies the FILE to be treated as an .ocf file regardless of its suffix.
-p PATH
This specifies the directory where the SDK is installed. The default value is
/usr/local/OPEN_R_SDK.
--nodefaultlib
This inhibits linking of the default libraries.
--nocrt
This inhibits linking of the startup routines. In case this option is not
specified, the following file is automatically linked.
crtbegin.o
crtend.o
--novm
This specifies that the generated executable file is used with
`nomemprot' configuration. The effect is the same as
specifying `notlb' for TLB and `kernel' for MODE in .ocf file.
-v
This prints verbose messages.