z Active X, Microsoft, MS-DOS, Visual Basic, Visual C++, Windows and Windows NT are either registered trademarks or trademarks of
Microsoft Corporation in the United States and other countries.
z IBM and AT are registered trademarks of International Business Machines Corporation.
z Intel and Pentium are registered trademarks of Intel Corporation.
z Adobe, Acrobat, and Acrobat Reader are trademarks of Adobe Systems Incorporated.
z TRON is an abbreviation of "The Real-time Operating system Nucleus."
z ITRON is an abbreviation of "Industrial TRON."
z μITRON is an abbreviation of "Micro Industrial TRON."
z TRON, ITRON, and μITRON do not refer to any specific product or products.
z All other brand and product names are trademarks, registered trademarks or service marks of their respective holders.
z Renesas Technology Corporation and Renesas Solutions Corporation put the maximum effort into making semiconductor products
better and more reliable, but there is always the possibility that trouble may occur with them. Trouble with semiconductors may lead to
personal injury, fire or property damage. Remember to give due consideration to safety when making your circuit designs, with appropriate measures such as (i) placement of substitutive, auxiliary circuits, (ii) use of nonflammable material or (iii) prevention against any
malfunction or mishap.
Keep safety first in your circuit designs!
z These materials are intended as a reference to assist our customers in the selection of the Renesas Technology product best suited
to the customer's application; they do not convey any license under any intellectual property rights, or any other rights, belonging to
Renesas Technology Corporation, Renesas Solutions Corporation or a third party.
z Renesas Technology Corporation and Renesas Solutions Corporation assume no responsibility for any damage, or infringement of
any third-party's rights, originating in the use of any product data, diagrams, charts, programs, algorithms, or circuit application examples contained in these materials.
z All information contained in these materials, including product data, diagrams, charts, programs and algorithms represents information
on products at the time of publication of these materials, and are subject to change by Renesas Technology Corporation and Renesas Solutions Corporation without notice due to product improvements or other reasons. It is therefore recommended that customers
contact Renesas Technology Corporation, Renesas Solutions Corporation or an authorized Renesas Technology product distributor
for the latest product information before purchasing a product listed herein. The information described here may contain technical inaccuracies or typographical errors. Renesas Technology Corporation and Renesas Solutions Corporation assume no responsibility
for any damage, liability, or other loss rising from these inaccuracies or errors. Please also pay attention to information published by
Renesas Technology Corporation and Renesas Solutions Corporation by various means, including the Renesas home page
(http://www.renesas.com).
z When using any or all of the information contained in these materials, including product data, diagrams, charts, programs, and algo-
rithms, please be sure to evaluate all information as a total system before making a final decision on the applicability of the information and products. Renesas Technology Corporation and Renesas Solutions Corporation assume no responsibility for any damage,
liability or other loss resulting from the information contained herein.
z Renesas Technology semiconductors are not designed or manufactured for use in a device or system that is used under circum-
stances in which human life is potentially at stake. Please contact Renesas Technology Corporation, Renesas Solutions Corporation
or an authorized Renesas Technology product distributor when considering the use of a product contained herein for any specific purposes, such as apparatus or systems for transportation, vehicular, medical, aerospace, nuclear, or undersea repeater use.
z The prior written approval of Renesas Technology Corporation and Renesas Solutions Corporation is necessary to reprint or repro-
duce in whole or in part these materials.
z If these products or technologies are subject to the Japanese export control restrictions, they must be exported under a license from
the Japanese government and cannot be imported into a country other than the approved destination. Any diversion or reexport contrary to the export control laws and regulations of Japan and/or the country of destination is prohibited.
z Please contact Renesas Technology Corporation or Renesas Solutions Corporation for further details on these materials or the prod-
ucts contained therein.
Notes regarding these materials
For inquiries about the contents of this document or product, fill in the text file the installer generates in the following
directory and email to your local distributor.
The M3T-MR100/4(abbreviated as MR100) is a real-time operating system1 for the R32C/100 series microcomputers. The
MR100 conforms to the μITRON Specification.
This manual describes the procedures and precautions to observe when you use the MR100 for programming purposes. For
the detailed information on individual service call procedures, refer to the MR100 Reference Manual.
Requirements for MR100 Use
Whe
n creating programs based on the MR100, it is necessary to purchase the following product of Renesas.
• C-compiler package for R32C/100 series microcomputers (abbreviated as NC100)
Document List
The following sets of documents are supplied with the MR100.
• Release Note
Presents a software overview and describes the corrections to the Users Manual and Reference Manual.
• Users Manual (PDF file)
Describes the procedures and precautions to observe when using the MR100 for programming purposes.
Right of Software Use
e right of software use conforms to the software license agreement. You can use the MR100 for your product develop-
Th
ment purposes only, and are not allowed to use it for the other purposes. You should also note that this manual does not
guarantee or permit the exercise of the right of software use.
2
1
Hereinafter abbreviated "real-time OS"
2
μITRON4.0 Specification is the open real-time kernel specification upon which the TRON association decided
The specification document of μITRON4.0 specification can come to hand from a TRON association homepage
(http://www.assoc.tron.org/).
The copyright of μITRON4.0 specification belongs to the TRON association.
i
Contents
Requirements for MR100 Use ......................................................................................................................................i
Right of Software Use...................................................................................................................................................i
List of Figures ................................................................................................................................................. viii
List of Tables ..................................................................................................................................................... xi
2. General Information ...............................................................................................................................- 3 -
2.1Objective of MR100 Development...................................................................................................... - 3 -
2.2Relationship between TRON Specification and MR100................................................................... - 5 -
2.3MR100 Features .................................................................................................................................- 6 -
3. Introduction to Kernel ............................................................................................................................- 7 -
3.1Concept of Real-time OS .................................................................................................................... - 7 -
3.1.1Why Real-time OS is Necessary .................................................................................................- 7 -
3.1.2Operating Principles of Kernel ................................................................................................. - 10 -
7.4.1Section used by the MR100..................................................................................................... - 225 -
8. Using Configurator ................................................................................................................................. 227
Direction of computation .........................................................................................................................................228
[( System Definition Procedure )]............................................................................................................................229
[( System Clock Definition Procedure )]..................................................................................................................231
[( Definition respective maximum numbers of items )]..........................................................................................232
[( Short data queue definition )]..............................................................................................................................239
Table 8.3 List of vector number and vector address ........................................................................ 248
Table 9.1 Functions in the Sample Program.................................................................................... 260
Table 10.1 Stack Sizes Used by Service Calls Issued from Tasks (in bytes) .................................. 272
Table 10.2 Stack Sizes Used by Service Calls Issued from Handlers (in bytes) ............................ 273
Table 10.3 Stack Sizes Used by Service Calls Issued from Tasks and Handlers (in bytes) ..........273
Table 11.1 Interrupt Number Assignment....................................................................................- 275 -
xi
xii
1. User’s Manual Organization
The MR100 User’s Manual consists of nine chapters and thee appendix.
• 2 General Information
Outlines the objective of MR100 development and the function and position of the MR100.
• 3 Introduction to Kernel
Explains about the ideas involved in MR100 operations and defines some relevant terms.
• 4 Kernel
Outlines the applications program development procedure for the MR100 .
• 5 Service call reffernce
Details MR100 service call API
• 6 Applications Development Procedure Overview
Details the applications program development procedure for the MR100.
• 7 Detailed Applications
Presents useful information and precautions concerning applications program development with MR100.
• 8 Using Configurator
Describes the method for writing a configuration file and the method for using the configurator in detail.
• 9 Sample Program Description
Describes the MR100 sample applications program which is included in the product in the form of a source file.
• 10 Stack Size Calculation Method
Describes the calculation method of the task stack size and the system stack size.
• 11 Note
Presents useful information and precautions concerning applications program development with MR100.
• 12 Appendix
Data type and assembly language interface.
- 1 -
2. General Information
2.1 Objective of MR100 Development
In line with recent rapid technological advances in microcomputers, the functions of microcomputer-based products have
become complicated. In addition, the microcomputer program size has increased. Further, as product development competition has been intensified, manufacturers are compelled to develop their microcomputer-based products within a short period
of time.
In other words, engineers engaged in microcomputer software development are now required to develop larger-size programs within a shorter period of time. To meet such stringent requirements, it is necessary to take the following considerations into account.
1. To enhance software recyclability to decrease the volume of software to be developed.
One way to provide for software recyclability is to divide software into a number of functional modules wherever
possible. This may be accomplished by accumulating a number of general-purpose subroutines and other program
segments and using them for program development. In this method, however, it is difficult to reuse programs that
are dependent on time or timing. In reality, the greater part of application programs are dependent on time or ti ming. Therefore, the above recycling method is applicable to only a limited number of programs.
2. To promote team programming so that a number of engineers are engaged in the development
of one software package
There are various problems with team programming. One major problem is that debugging can be initiated only
when all the software program segments created individually by team members are ready for debugging. It is essential that communication be properly maintained among the team members.
3. To enhance software production efficiency so as to increase the volume of possible software
development per engineer.
One way to achieve this target would be to educate engineers to raise their level of skill. Another way would be to
make use of a structured descriptive assembler, C-compiler, or the like with a view toward facilitating programming. It is also possible to enhance debugging efficiency by promoting modular software development.
However, the conventional methods are not adequate for the purpose of solving the problems. Under these circumstances, it
is necessary to introduce a new system named real-time OS
To answer the above-mentioned demand, Renesas has developed a real-time operating system, tradenamed MR100, for use
with the R32C/100 series of 32-bit microcomputers .
When the MR100 is introduced, the following advantages are offered.
1. Software recycling is facilitated.
When the real-time OS is introduced, timing signals are furnished via the real-time OS so that programs dependent on timing can be reused. Further, as programs are divided into modules called tasks, structured programming
will be spontaneously provided.
That is, recyclable programs are automatically prepared.
2. Ease of team programming is provided.
When the real-time OS is put to use, programs are divided into functional modules called tasks. Therefore, engineers can be allocated to individual tasks so that all steps from development to debugging can be conducted inde pendently for each task.
Further, the introduction of the real-time OS makes it easy to start debugging some already finished tasks even if
the entire program is not completed yet. Since engineers can be allocated to individual tasks, work assignment is
easy.
3
3. Software independence is enhanced to provide ease of progra m debugging.
As the use of the real-time OS makes it possible to divide programs into small independent modules called tasks,
3
OS:Operating System
- 3 -
the greater part of program debugging can be initiated simply by observing the small modules.
4. Timer control is made easier.
To perform processing at 10 ms intervals, the microcomputer timer function was formerly used to periodically initiate an interrupt. However, as the number of usable microcomputer timers was limited, timer insufficiency was
compensated for by, for instance, using one timer for a number of different processing operations.
When the real-time OS is introduced, however, it is possible to create programs for performing processing at fixed
time intervals making use of the real-time OS time management function without paying special attention to the
microcomputer timer function. At the same time, programming can also be done in such a manner as to let the
programmer take that numerous timers are provided for the microcomputer.
5. Software maintainability is enhanced
When the real-time OS is put to use, the developed software consists of small program modules called tasks.
Therefore, increased software maintainability is provided because developed software maintenance can be carried
out simply by maintaining small tasks.
6. Increased software reliability is assured.
The introduction of the real-time OS makes it possible to carry out program evaluation and testing in the unit of a
small module called task. This feature facilitates evaluation and testing and increases software reliability.
7. The microcomputer performance can be optimized to improve the performance of microcomputer-based products.
With the real-time OS, it is possible to decrease the number of unnecessary microcomputer operations such as I/O
waiting. It means that the optimum capabilities can be obtained from microcomputers, and this will lead to microcomputer-based product p erf ormance improvement.
- 4 -
2.2 Relationship between TRON Specification and MR100
MR100 is the real-time operating system developed for use with the R32C/10 series of 32-bit microcomputers compliant
with µITRON 4.0 Specification. µITRON 4.0 Specification stipulates standard profiles as an attempt to ensure software
portability. Of these standard profiles, MR100 has implemented in it all service calls except for static APIs and task exception APIs
- 5 -
2.3 MR100 Features
The MR100 offers the following features.
1. Real-time operating system conforming to the μITORN Specification.
The MR100 is designed in compliance with the μITRON Specification which incorporates a minimum of the
ITRON Specification functions so that such functions can be incorporated into a one-chip microcomputer. As the
μITRON Specification is a subset of the ITRON Specification, most of the knowledge obtained from published
ITRON textbooks and ITRON seminars can be used as is.
Further, the application programs developed using the real-time operating systems conforming to the ITRON
Specification can be transferred to the MR100 with comparative ease.
2. High-speed processing is achieved.
MR100 enables high-speed processing by taking full advantage of the microcomputer architecture.
3. Only necessary modules are automatically selected to constantly build up a system of the
minimum size.
MR100 is supplied in the object library format of the R32C/100 series.
Therefore, the Linkage Editor functions are activated so that only necessary modules are automatically selected
from numerous MR100 functional modules to generate a system.
Thanks to this feature, a system of the minimum size is automatically generated at all times.
4. With the C-compiler NC100, it is possible to develop application programs in C language.
Application programs of MR100 can be developed in C language by using the C compiler NC100. Furthermore,
the interface library necessary to call the MR100 functions from C language is included with the software package.
5. An upstream process tool named "Configurator" is provided to simplify development procedures
A configurator is furnished so that various items including a ROM write form file can be created by giving simple
definitions.
Therefore, there is no particular need to care what libraries must be linked.
In addition, a GUI version of the configurator is available. It helps the user to create a configuration file without
the need to learn how to write it.
- 6 -
3. Introduction to Kernel
3.1 Concept of Real-time OS
This section explains the basic concept of real-time OS.
3.1.1 Why Real-time OS is Necessary
In line with the recent advances in semiconductor technologies, the single-chip microcomputer ROM capacity has increased. ROM capacity of 32K bytes.
As such large ROM capacity microcomputers are introduced, their program development is not easily carried out by conventional methods. Figure 3.1 shows the relationship between the program size and required development time (program
opment difficulty).
devel
This figure is nothing more than a schematic diagram. However, it indicates that the development period increases expo-
nentially with an increase in program size.
For example, the development of four 8K byte programs is easier than the development of one 32K byte program.
4
Development Period
4
8
16
Program Size
32
Kbyte
Figure 3.1 Relationship between Program Size and Development Period
Under these circumstances, it is necessary to adopt a method by which large-size programs can be developed within a short
period of time. One way to achieve this purpose is to use a large number of microcomputers having a small ROM capacity.
Figure 3.2 presents an example in which a number of microcomputers are used to build up an audio equipment system.
4
On condition that the ROM program burning step need not be performed.
- 7 -
p
Key input
microcomputer
Volume control
microcomputer
Remote control
microcomputer
Arbiter
microcomputer
Monitor
microcomputer
LED illumination
microcomputer
Mechanical
control
microcom
uter
Figure 3.2 Microcomputer-based System Example(Audio Equipment)
Using independent microcomputers for various functions as indicated in the above example offers the following advantages.
1. Individual programs are small so that program development is easy.
2. It is very easy to use previously developed software.
3. Completely independent programs are provided for various functions so that program development can easily be conducted by a number of engineers.
On the other hand, there are the following disadvantages.
1. The number of parts us ed increases, thereby raising the product cost.
2. Hardware design is complicated.
3. Product physical size is enlarged.
Therefore, if you employ the real-time OS in which a number of programs to be operated by a number of microcomputers
are placed under software control of one microcomputer, making it appear that the programs run on separate microcomputers, you can obviate all the above disadvantages while retaining the above-mentioned advantages.
Figure 3.3 shows an example system that will be obtained if the real-time OS is incorporated in the system indicated in
Figure 3.2.
- 8 -
Key input
Tas k
Remote control
Task
LED illumination
Task
real-time
OS
Volume control
Task
Monitor
Tas k
Mechanical
control
Task
Figure 3.3 Example System Configuration with Real-time OS(Audio Equipment)
In other words, the real-time OS is the software that makes a one-microcomputer system look like operating a number of
microcomputers.
In the real-time OS, the individual programs, which correspond to a number of microcomputers used in a conventional system, are called tasks.
- 9 -
3.1.2 Operating Principles of Kernel
A kernel is the core program of real-time OS. The kernel is the software that makes a one-microcomputer system look like
operating a number of microcomputers. You should be wondering how the kernel makes a one-microcomputer system
function like a number of microcomputers.
As shown in Figure 3.4 the kernel runs a number of tasks according to the time-division system. That is, it changes the task
ute at fixed time intervals so that a number of tasks appear to be executed simultaneously.
to exec
Key input
Task
Remote control
Task
LED
illumination
Task
Volume control
Task
Monitor
Task
Mechanical
control
Task
Time
Figure 3.4 Time-division Task Operation
As indicated above, the kernel changes the task to execute at fixed time intervals. This task switching may also be referred
to as dispatching. The factors causing task switching (dispatching) are as follows.
• Task switching occurs upon request from a task.
• Task switching occurs due to an external factor such as interrupt.
When a certain task is to be executed again upon task switching, the system resumes its execution at the po int of last interruption (See Figure 3.5).
- 10 -
A
Program execution
interrupt
Program execution
resumed
Key input
Task
Remote control
Task
During this interval, it
appears that the key input
microcomputer is haled.
Figure 3.5 Task Execution Interruption and Resumption
In the state shown in Figure 3.5, it appears to the programmer that the key input task or its microcomputer is halted while
anot
her task assumes execution control.
Task execution restarts at the point of last interruption as the register contents prevailing at the time of the last interruption
are recovered. In other words, task switching refers to the action performed to save the currently executed task register
contents into the associated task management memory area and recover the register contents for the task to switch to.
To establish the kernel, therefore, it is only necessary to manage the register for each task and change the register contents
upon each task switching so that it looks as if a number of microcomputers exist (See Figure 3.6).
Key input
Task
R0
R1
PC
R0
R1
ctual
Register
PC
Kernel
Remote control
Task
R0
R1
PC
Register Register
Figure 3.6 Task Switching
The example presented inFigure 3.7
5
indicates how the individual task registers are managed. In reality, it is necessary
to provide not only a register but also a stack area for each task.
5
It is figure where all the stack areas of the task were arranged in the same section.
- 11 -
Memory map
Register
R0
Remote control
Task
PC
SP
R0
Key input
Tas k
PC
SP
R0
LED illumination
Task
Stack
section
Real-time
OS
PC
SP
SP
Figure 3.7 Task Register Area
SFR
- 12 -
A0A
A3A
Figure 3.8 shows the register and stack area of one tas
k in detail. In the MR100, the register of each task is stored in a stack
area as shown in Figure 3.8. This figure shows the state prevailing after register storage.
Key input
Task
SP
Register not stored
SP
PC
FLG
FB
SB
2
1
R7R5
R6R4
R3R1
R2R0
Register stored
SFR
Key input task
stack
Figure 3.8 Actual Register and Stack Area Management
- 13 -
3.2 Service Call
How does the programmer use the kernel functions in a program?
First, it is necessary to call up kernel function from the program in some way or other. Calling a kernel function is referred
to as a service call. Task activation and other processing operations can be initiated by such a service call (See Figure 3.9).
Key input
Task
Service call Task switching
Kernel
Figure 3.9 Service call
This service call is realized by a function call when the application program is written in C language, as shown below.
act_tsk(ID_main,3);
Remote control
task
Furthermore, if the application program is written in assembly language, it is realized by an assembler macro call, as shown
below.
act_tsk #ID_main
- 14 -
3.2.1 Service Call Processing
When a service call is issued, processing takes place in the following sequence.6
1. The current register contents are saved.
2. The stack pointer is changed from the task type to the real-time OS (system) type.
3. Processing is performed in compliance with the request made by the service call.
4. The task to be executed next is selected.
5. The stack pointer is changed to the task type.
6. The register contents are recovered to resume task execution.
The flowchart in Figure 3.10 shows the process between service call generation and task switching.
Key input Task
Service call issuance
Figure 3.10 Service Call Processing Flowchart
Register Save
<= OS
SP
Processing
Task S election
Task => S P
Register Restore
LED illumination Task
6
A different sequence is followed if the issued service call does not evoke task switching.
- 15 -
3.2.2 Processing Procedures for Service Calls from Handlers
When a service call is issued from a handler, task switching does not occur unlike in the case of a service call from a task.
However, task switching occurs when a return from a handler
7
is made.
The processing procedures for service calls from handlers are roughly classified into the following three types.
1. A service call from a handler that caused an interrupt during task execution
2. A service call from a handler that caused an interrupt during service call processing
3. A service call from a handler that caused an interrupt (multiplex interrupt) during handler execution
7
The service call can't be issued from non-kernel handler. Therefore, The handler described here does not include the non-kernel interrupt
handler.
- 16 -
Loading...
+ 274 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.