Renesas M3T-MR100 User Manual

Download

REJ10J1523-0100

M3T-MR100/4 V.1.00

User’s Manual

Real-time OS for R32C/100 Series

Rev.1.00 September 16, 2007

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.

\SUPPORT\Product-name\SUPPORT.TXT Renesas Tools Homepage http://www.renesas.com/en/tools

Preface

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.

Hereinafter abbreviated "real-time OS"

μ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.

Contents

Requirements for MR100 Use ......................................................................................................................................i

Document List...............................................................................................................................................................i

Right of Software Use...................................................................................................................................................i

Contents.............................................................................................................................................................iii

List of Figures ................................................................................................................................................. viii

List of Tables ..................................................................................................................................................... xi

1. User’s Manual Organization................................................................................................................... - 1 -

2. General Information ...............................................................................................................................- 3 -

2.1 Objective of MR100 Development...................................................................................................... - 3 -

2.2 Relationship between TRON Specification and MR100................................................................... - 5 -

2.3 MR100 Features .................................................................................................................................- 6 -

3. Introduction to Kernel ............................................................................................................................- 7 -

3.1 Concept of Real-time OS .................................................................................................................... - 7 -

3.1.1 Why Real-time OS is Necessary .................................................................................................- 7 -

3.1.2 Operating Principles of Kernel ................................................................................................. - 10 -

3.2 Service Call ....................................................................................................................................... - 14 -

3.2.1 Service Call Processing ............................................................................................................. - 15 -

3.2.2 Processing Procedures for Service Calls from Handlers......................................................... - 16 -

Service Calls from a Handler That Caused an Interrupt during Task Execution............................................. - 17 -

Service Calls from a Handler That Caused an Interrupt during Service Call Processing................................ - 18 -

Service Calls from a Handler That Caused an Interrupt during Handler Execution....................................... - 19 -

3.3 Object................................................................................................................................................. - 20 -

3.3.1 The specification method of the object in a service call ..........................................................- 20 -

3.4 Task ................................................................................................................................................... - 21 -

3.4.1 Task Status................................................................................................................................ - 21 -

3.4.2 Task Priority and Ready Queue ............................................................................................... - 25 -

3.4.3 Task Priority and Waiting Queue............................................................................................. - 26 -

3.4.4 Task Control Block(TCB) ..........................................................................................................- 27 -

3.5 System States.................................................................................................................................... - 28 -

3.5.1 Task Context and Non-task Context........................................................................................ - 28 -

3.5.2 Dispatch Enabled/Disabled States ...........................................................................................- 30 -

3.5.3 CPU Locked/Unlocked States ...................................................................................................- 30 -

3.5.4 Dispatch Disabled and CPU Locked States............................................................................. - 30 -

3.6 Regarding Interrupts........................................................................................................................ - 31 -

3.6.1 Types of Interrupt Handlers..................................................................................................... - 31 -

3.6.2 The Use of Non-maskable Interrupt ........................................................................................- 31 -

3.6.3 Controlling Interrupts............................................................................................................... - 32 -

3.7 Stacks ................................................................................................................................................ - 34 -

3.7.1 System Stack and User Stack................................................................................................... - 34 -

4. Kernel ....................................................................................................................................................- 35 -

4.1.1 Module Structure....................................................................................................................... - 35 -

4.1.2 Module Overview....................................................................................................................... - 36 -

4.1.3 Task Management Function..................................................................................................... - 37 -

4.1.4 Synchronization functions attached to task ............................................................................- 39 -

4.1.5 Synchronization and Communication Function (Semaphore)................................................ - 43 -

4.1.6 Synchronization and Communication Function (Eventflag) .................................................. - 45 -

4.1.7 Synchronization and Communication Function (Data Queue) ..............................................- 47 -

iii

4.1.8 Synchronization and Communication Function (Mailbox)..................................................... - 48 -

4.1.9 Memory pool Management Function(Fixed-size Memory pool) .............................................- 50 -

4.1.10 Variable-size Memory Pool Management Function ................................................................ - 51 -

4.1.11 Time Management Function..................................................................................................... - 54 -

4.1.12 Cyclic Handler Function ........................................................................................................... - 56 -

4.1.13 Alarm Handler Function........................................................................................................... - 57 -

4.1.14 System Status Management Function..................................................................................... - 58 -

4.1.15 Interrupt Management Function ............................................................................................. - 59 -

4.1.16 System Configuration Management Function ........................................................................ - 60 -

4.1.17 Extended Function (Short Data Queue) ..................................................................................- 60 -

4.1.18 Extended Function (Reset Function) ....................................................................................... - 61 -

5. Service call reffernce............................................................................................................................. - 63 -

5.1 Task Management Function ............................................................................................................ - 63 -

act_tsk Activate task .......................................................................................................................... - 65 -

iact_tsk Activate task (handler only).................................................................................................. - 65 -

can_act Cancel task activation request.............................................................................................. - 67 -

ican_act Cancel task activation request (handler only) ..................................................................... - 67 -

sta_tsk Activate task with a start code ............................................................................................. - 69 -

ista_tsk Activate task with a start code (handler only)..................................................................... - 69 -

ext_tsk Terminate invoking task ....................................................................................................... - 71 -

ter_tsk Terminate task ....................................................................................................................... - 73 -

chg_pri Change task priority.............................................................................................................. - 75 -

ichg_pri Change task priority(handler only) ...................................................................................... - 75 -

get_pri Reference task priority.......................................................................................................... - 77 -

iget_pri Reference task priority(handler only) .................................................................................. - 77 -

ref_tsk Reference task status ............................................................................................................ - 79 -

iref_tsk Reference task status (handler only).................................................................................... - 79 -

ref_tst Reference task status (simplified version) ........................................................................... - 82 -

iref_tst Reference task status (simplified version, handler only) ....................................................- 82 -

5.2 Task Dependent Synchronization Function.................................................................................... - 84 -

slp_tsk Put task to sleep..................................................................................................................... - 85 -

tslp_tsk Put task to sleep (with timeout)............................................................................................ - 85 -

wup_tsk Wakeup task........................................................................................................................... - 88 -

iwup_tsk Wakeup task (handler only)............................................................................................... - 88 -

can_wup Cancel wakeup request...................................................................................................... - 90 -

ican_wup Cancel wakeup request (handler only) .............................................................................- 90 -

rel_wai Release task from waiting..................................................................................................... - 92 -

irel_wai Release task from waiting (handler only) ............................................................................ - 92 -

sus_tsk Suspend task .......................................................................................................................... - 94 -

isus_tsk Suspend task (handler only) ................................................................................................. - 94 -

rsm_tsk Resume suspended task ........................................................................................................- 96 -

irsm_tsk Resume suspended task(handler only) .............................................................................- 96 -

frsm_tsk Forcibly resume suspended task....................................................................................... - 96 -

ifrsm_tsk Forcibly resume suspended task(handler only) ............................................................... - 96 -

dly_tsk Delay task............................................................................................................................... - 98 -

5.3 Synchronization & Communication Function (Semaphore) ........................................................ - 100 -

sig_sem Release semaphore resource ...............................................................................................- 101 -

isig_sem Release semaphore resource (handler only) ................................................................... - 101 -

wai_sem Acquire semaphore resource............................................................................................ - 103 -

pol_sem Acquire semaphore resource (polling) ................................................................................- 103 -

ipol_sem Acquire semaphore resource (polling, handler only) .....................................................- 103 -

twai_sem Acquire semaphore resource(with timeout).................................................................... - 103 -

ref_sem Reference semaphore status ............................................................................................... - 106 -

iref_sem Reference semaphore status (handler only)....................................................................... - 106 -

5.4 Synchronization & Communication Function (Eventflag)........................................................... - 108 -

set_flg Set eventflag......................................................................................................................... - 109 -

iset_flg Set eventflag (handler only) ................................................................................................- 109 -

clr_flg Clear eventflag..........................................................................................................................- 111 -

iclr_flg Clear eventflag (handler only) .............................................................................................- 111 -

wai_flg Wait for eventflag................................................................................................................. - 113 -

pol_flg Wait for eventflag(polling)................................................................................................... - 113 -

ipol_flg Wait for eventflag(polling, handler only)............................................................................ - 113 -

twai_flg Wait for eventflag(with timeout)......................................................................................... - 113 -

ref_flg Reference eventflag status .................................................................................................. - 116 -

iref_flg Reference eventflag status (handler only).......................................................................... - 116 -

5.5 Synchronization & Communication Function (Data Queue)....................................................... - 118 -

snd_dtq Send to data queue .............................................................................................................. - 119 -

psnd_dtq Send to data queue (polling)............................................................................................ - 119 -

ipsnd_dtq Send to data queue (polling, handler only)..................................................................... - 119 -

tsnd_dtq Send to data queue (with timeout).................................................................................. - 119 -

fsnd_dtq Forced send to data queue ............................................................................................... - 119 -

ifsnd_dtq Forced send to data queue (handler only) ...................................................................... - 119 -

rcv_dtq Receive from data queue .....................................................................................................- 122 -

prcv_dtq Receive from data queue (polling)................................................................................... - 122 -

iprcv_dtq Receive from data queue (polling, handler only)............................................................ - 122 -

trcv_dtq Receive from data queue (with timeout) ............................................................................ - 122 -

ref_dtq Reference data queue status ............................................................................................... - 125 -

iref_dtq Reference data queue status (handler only) ...................................................................... - 125 -

5.6 Synchronization & Communication Function (Mailbox).............................................................. - 127 -

snd_mbx Send to mailbox ................................................................................................................- 128 -

isnd_mbx Send to mailbox (handler only) ....................................................................................... - 128 -

rcv_mbx Receive from mailbox........................................................................................................... - 130 -

prcv_mbx Receive from mailbox (polling) ........................................................................................- 130 -

iprcv_mbx Receive from mailbox (polling, handler only) ................................................................. - 130 -

trcv_mbx Receive from mailbox (with timeout) .............................................................................. - 130 -

ref_mbx Reference mailbox status ....................................................................................................- 133 -

iref_mbx Reference mailbox status (handler only) ........................................................................- 133 -

5.7 Memory Pool Management Function (Fixed-size Memory Pool)................................................. - 135 -

get_mpf Aquire fixed-size memory block .......................................................................................... - 136 -

pget_mpf Aquire fixed-size memory block (polling)........................................................................ - 136 -

ipget_mpf Aquire fixed-size memory block (polling, handler only) ................................................ - 136 -

tget_mpf Aquire fixed-size memory block (with timeout) ............................................................. - 136 -

rel_mpf Release fixed-size memory block......................................................................................... - 139 -

irel_mpf Release fixed-size memory block (handler only) ................................................................- 139 -

ref_mpf Reference fixed-size memory pool status ........................................................................... - 141 -

iref_mpf Reference fixed-size memory pool status (handler only)................................................... - 141 -

5.8 Memory Pool Management Function (Variable-size Memory Pool) ............................................- 143 -

pget_mpl Aquire variable-size memory block (polling) .................................................................. - 144 -

rel_mpl Release variable-size memory block ...................................................................................- 146 -

ref_mpl Reference variable-size memory pool status ......................................................................- 148 -

iref_mpl Reference variable-size memory pool status (handler only) .............................................- 148 -

5.9 Time Management Function.......................................................................................................... - 150 -

set_tim Set system time .................................................................................................................... - 151 -

iset_tim Set system time (handler only) ........................................................................................... - 151 -

get_tim Reference system time......................................................................................................... - 153 -

iget_tim Reference system time (handler only) ................................................................................ - 153 -

isig_tim Supply a time tick................................................................................................................ - 155 -

5.10 Time Management Function (Cyclic Handler).............................................................................. - 156 -

sta_cyc Start cyclic handler operation............................................................................................. - 157 -

ista_cyc Start cyclic handler operation (handler only) .................................................................... - 157 -

stp_cyc Stops cyclic handler operation ............................................................................................- 159 -

istp_cyc Stops cyclic handler operation (handler only).................................................................... - 159 -

ref_cyc Reference cyclic handler status........................................................................................... - 160 -

iref_cyc Reference cyclic handler status (handler only) ..................................................................- 160 -

5.11 Time Management Function (Alarm Handler) .............................................................................- 162 -

sta_alm Start alarm handler operation............................................................................................ - 163 -

ista_alm Start alarm handler operation (handler only)................................................................ - 163 -

stp_alm Stop alarm handler operation .............................................................................................- 165 -

istp_alm Stop alarm handler operation (handler only)................................................................. - 165 -

ref_alm Reference alarm handler status.......................................................................................... - 166 -

iref_alm Reference alarm handler status (handler only) .................................................................- 166 -

5.12 System Status Management Function.......................................................................................... - 168 -

rot_rdq Rotate task precedence........................................................................................................ - 169 -

irot_rdq Rotate task precedence (handler only) ...............................................................................- 169 -

get_tid Reference task ID in the RUNNING state......................................................................... - 171 -

iget_tid Reference task ID in the RUNNING state (handler only) ................................................- 171 -

loc_cpu Lock the CPU .......................................................................................................................- 172 -

iloc_cpu Lock the CPU (handler only)............................................................................................... - 172 -

unl_cpu Unlock the CPU ................................................................................................................... - 174 -

iunl_cpu Unlock the CPU (handler only) ....................................................................................... - 174 -

dis_dsp Disable dispatching ............................................................................................................. - 175 -

ena_dsp Enables dispatching............................................................................................................. - 177 -

sns_ctx Reference context................................................................................................................. - 178 -

sns_loc Reference CPU state............................................................................................................ - 179 -

sns_dsp Reference dispatching state ................................................................................................- 180 -

sns_dpn Reference dispatching pending state.................................................................................. - 181 -

5.13 Interrupt Management Function................................................................................................... - 182 -

ret_int Returns from an interrupt handler (when written in assembly language).................. - 183 -

5.14 System Configuration Management Function.............................................................................. - 184 -

ref_ver Reference version information ............................................................................................- 185 -

iref_ver Reference version information (handler only) ................................................................... - 185 -

5.15 Extended Function (Short Data Queue)........................................................................................ - 187 -

vsnd_dtq Send to Short data queue ................................................................................................ - 188 -

vpsnd_dtq Send to Short data queue (polling).................................................................................. - 188 -

vipsnd_dtq Send to Short data queue (polling, handler only).......................................................... - 188 -

vtsnd_dtq Send to Short data queue (with timeout) .......................................................................- 188 -

vfsnd_dtq Forced send to Short data queue..................................................................................... - 188 -

vifsnd_dtq Forced send to Short data queue (handler only) ............................................................ - 188 -

vrcv_dtq Receive from Short data queue ....................................................................................... - 191 -

vprcv_dtq Receive from Short data queue (polling)......................................................................... - 191 -

viprcv_dtq Receive from Short data queue (polling,handler only) ..................................................- 191 -

vtrcv_dtq Receive from Short data queue (with timeout) .............................................................. - 191 -

vref_dtq Reference Short data queue status..................................................................................... - 194 -

viref_dtq Reference Short data queue status (handler only)......................................................... - 194 -

5.16 Extended Function (Reset Function)............................................................................................. - 196 -

vrst_dtq Clear data queue area .........................................................................................................- 197 -

vrst_vdtq Clear Short data queue area ...........................................................................................- 199 -

vrst_mbx Clear mailbox area ...........................................................................................................- 201 -

vrst_mpf Clear fixed-size memory pool area .................................................................................. - 203 -

vrst_mpl Clear variable-size memory pool area............................................................................. - 204 -

6. Applications Development Procedure Overview................................................................................ - 205 -

6.1 Overview.......................................................................................................................................... - 205 -

6.2 Development Procedure Example.................................................................................................. - 207 -

6.2.1 Applications Program Coding................................................................................................. - 207 -

6.2.2 Configuration File Preparation .............................................................................................. - 208 -

6.2.3 Configurator Execution........................................................................................................... - 209 -

6.2.4 System generation................................................................................................................... - 209 -

6.2.5 Writing ROM............................................................................................................................- 210 -

7. Detailed Applications.......................................................................................................................... - 211 -

7.1 Program Coding Procedure in C Language................................................................................... - 211 -

7.1.1 Task Description Procedure.................................................................................................... - 211 -

7.1.2 Writing a Kernel (OS Dependent) Interrupt Handler ..........................................................- 212 -

7.1.3 Writing Non-kernel Interrupt Handler.................................................................................. - 213 -

7.1.4 Writing Cyclic Handler/Alarm Handler................................................................................. - 213 -

7.2 Program Coding Procedure in Assembly Language .....................................................................- 215 -

7.2.1 Writing Task ............................................................................................................................- 215 -

7.2.2 Writing Kernel Interrupt Handler .........................................................................................- 216 -

7.2.3 Writing Non-kernel Interrupt Handler.................................................................................. - 216 -

7.2.4 Writing Cyclic Handler/Alarm Handler................................................................................. - 216 -

7.3 Modifying MR100 Startup Program.............................................................................................. - 218 -

7.3.1 C Language Startup Program (crt0mr.a30)........................................................................... - 219 -

7.4 Memory Allocation.......................................................................................................................... - 224 -

7.4.1 Section used by the MR100..................................................................................................... - 225 -

8. Using Configurator ................................................................................................................................. 227

8.1 Configuration File Creation Procedure ..............................................................................................227

8.1.1 Configuration File Data Entry Format.......................................................................................227

Operator ...................................................................................................................................................................228

Direction of computation .........................................................................................................................................228

8.1.2 Configuration File Definition Items............................................................................................229

[( System Definition Procedure )]............................................................................................................................229

[( System Clock Definition Procedure )]..................................................................................................................231

[( Definition respective maximum numbers of items )]..........................................................................................232

[( Task definition )]...................................................................................................................................................234

[( Eventflag definition )] ..........................................................................................................................................236

[( Semaphore definition )]........................................................................................................................................237

[(Data queue definition )] ........................................................................................................................................238

[( Short data queue definition )]..............................................................................................................................239

[( Mailbox definition )] .............................................................................................................................................240

[( Fixed-size memory pool definition )]....................................................................................................................241

[( Variable-size memory pool definition )]...............................................................................................................242

[( Cyclic handler definition )]...................................................................................................................................244

[( Alarm handler definition )] ..................................................................................................................................245

[( Interrupt vector definition )]................................................................................................................................246

[( Fixed interrupt vector definition )]......................................................................................................................247

8.1.3 Configuration File Example.........................................................................................................250

8.2 Configurator Execution Procedures ...................................................................................................254

8.2.1 Configurator Overview.................................................................................................................254

Executing the configurator requires the following input files:..............................................................................254

When the configurator is executed, the files listed below are output. ..................................................................254

8.2.2 Setting Configurator Environment .............................................................................................255

8.2.3 Configurator Start Procedure......................................................................................................256

8.2.4 Precautions on Executing Configurator......................................................................................256

8.2.5 Configurator Error Indications and Remedies ...........................................................................257

Error messages ........................................................................................................................................................257

Warning messages ...................................................................................................................................................259

9. Sample Program Description.................................................................................................................. 260

9.1 Overview of Sample Program .............................................................................................................260

9.2 Program Source Listing.......................................................................................................................261

9.3 Configuration File................................................................................................................................262

10. Stack Size Calculation Method ........................................................................................................... 264

10.1 Stack Size Calculation Method...........................................................................................................264

10.1.1 User Stack Calculation Method...................................................................................................266

10.1.2 System Stack Calculation Method ..............................................................................................268

10.2 Necessary Stack Size...........................................................................................................................272

11. Note.................................................................................................................................................. - 275 -

11.1 The Use of INT Instruction............................................................................................................ - 275 -

11.2 The Use of registers of bank .......................................................................................................... - 275 -

11.3 Regarding Delay Dispatching ........................................................................................................- 276 -

11.4 Regarding Initially Activated Task................................................................................................- 277 -

12. Appendix .......................................................................................................................................... - 279 -

12.1 Data Type........................................................................................................................................ - 279 -

12.2 Common Constants and Packet Format of Structure ..................................................................- 280 -

12.3 Assembly Language Interface........................................................................................................ - 282 -

vii

List of Figures

Figure 3.1 Relationship between Program Size and Development Period.....................................- 7 -

Figure 3.2 Microcomputer-based System Example(Audio Equipment) .........................................- 8 -

Figure 3.3 Example System Configuration with Real-time OS(Audio Equipment) ......................- 9 -

Figure 3.4 Time-division Task Operation .......................................................................................- 10 -

Figure 3.5 Task Execution Interruption and Resumption ............................................................- 11 -

Figure 3.6 Task Switching...............................................................................................................- 11 -

Figure 3.7 Task Register Area.........................................................................................................- 12 -

Figure 3.8 Actual Register and Stack Area Management .............................................................- 13 -

Figure 3.9 Service call......................................................................................................................- 14 -

Figure 3.10 Service Call Processing Flowchart..............................................................................- 15 -

Figure 3.11 Processing Procedure for a Service Call a Handler that caused an interrupt during Task

Execution - 17 -

Figure 3.12 Processing Procedure for a Service Call from a Handler that caused an interrupt during

Service Call Processing.............................................................................................................- 18 -

Figure 3.13 Processing Procedure for a service call from a Multiplex interrupt Handler ..........- 19 -

Figure 3.14 Task Identification.......................................................................................................- 20 -

Figure 3.15 Task Status...................................................................................................................- 21 -

Figure 3.16 MR100 Task Status Transition ...................................................................................- 22 -

Figure 3.17 Ready Queue (Execution Queue) ................................................................................- 25 -

Figure 3.18 Waiting queue of the TA_TPRI attribute ...................................................................- 26 -

Figure 3.19 Waiting queue of the TA_TFIFO attribute.................................................................- 26 -

Figure 3.20 Task control block ........................................................................................................- 27 -

Figure 3.21 Cyclic Handler/Alarm Handler Activation .................................................................- 29 -

Figure 3.22 Interrupt handler IPLs................................................................................................- 31 -

Figure 3.23 Interrupt control in a Service Call that can be Issued from only a Task.................- 32 -

Figure 3.24 Interrupt control in a Service Call that can be Issued from a Task-independent ...- 33 -

Figure 3.25 System Stack and User Stack .....................................................................................- 34 -

Figure 4.1 MR100 Structure............................................................................................................- 35 -

Figure 4.2 Task Resetting................................................................................................................- 37 -

Figure 4.3 Alteration of task priority..............................................................................................- 38 -

Figure 4.4 Task rearrangement in a waiting queue ......................................................................- 38 -

Figure 4.5 Wakeup Request Storage...............................................................................................- 39 -

Figure 4.6 Wakeup Request Cancellation.......................................................................................- 39 -

Figure 4.7 Forcible wait of a task and resume...............................................................................- 40 -

Figure 4.8 Forcible wait of a task and forcible resume..................................................................- 41 -

Figure 4.9 dly_tsk service call .........................................................................................................- 42 -

Figure 4.10 Exclusive Control by Semaphore ................................................................................- 43 -

Figure 4.11 Semaphore Counter .....................................................................................................- 43 -

Figure 4.12 Task Execution Control by Semaphore.......................................................................- 44 -

Figure 4.13 Task Execution Control by the Eventflag...................................................................- 46 -

Figure 4.14 Data queue ...................................................................................................................- 47 -

Figure 4.15 Mailbox .........................................................................................................................- 48 -

Figure 4.16 Message queue .............................................................................................................- 49 -

Figure 4.17 Memory Pool Management..........................................................................................- 50 -

Figure 4.18 pget_mpl processing.....................................................................................................- 52 -

Figure 4.19 rel_mpl processing .......................................................................................................- 53 -

Figure 4.20 Timeout Processing......................................................................................................- 54 -

Figure 4.21 Cyclic handler operation in cases where the activation phase is saved ...................- 56 -

Figure 4.22 Cyclic handler operation in cases where the activation phase is not saved.............- 56 -

Figure 4.23 Typical operation of the alarm handler......................................................................- 57 -

Figure 4.24 Ready Queue Management by rot_rdq Service Call ..................................................- 58 -

Figure 4.25 Interrupt process flow..................................................................................................- 59 -

Figure 6.1 MR100 System Generation Detail Flowchart ............................................................- 206 -

Figure 6.2 Program Example ........................................................................................................- 208 -

viii

Figure 6.3 Configuration File Example ........................................................................................- 209 -

Figure 6.4 Configurator Execution ...............................................................................................- 209 -

Figure 6.5 System Generation.......................................................................................................- 210 -

Figure 7.1 Example Infinite Loop Task Described in C Language.............................................- 211 -

Figure 7.2 Example Task Terminating with ext_tsk() Described in C Language......................- 212 -

Figure 7.3 Example of Kernel Interrupt Handler........................................................................- 213 -

Figure 7.4 Example of Non-kernel Interrupt Handler ................................................................- 213 -

Figure 7.5 Example Cyclic Handler Written in C Language ......................................................- 214 -

Figure 7.6 Example Infinite Loop Task Described in Assembly Language................................- 215 -

Figure 7.7 Example Task Terminating with ext_tsk Described in Assembly Language...........- 215 -

Figure 7.8 Example of kernel(OS-depend) interrupt handler.....................................................- 216 -

Figure 7.9 Example of Non-kernel Interrupt Handler of Specific Level ....................................- 216 -

Figure 7.10 Example Handler Written in Assembly Language ..................................................- 217 -

Figure 7.11 C Language Startup Program (crt0mr.a30) .............................................................- 222 -

Figure 8.1 The operation of the Configurator .................................................................................. 255

List of Tables

Table 3.1 Task Context and Non-task Context ..............................................................................- 28 -

Table 3.2 Invocable Service Calls in a CPU Locked State.............................................................- 30 -

Table 3.3 CPU Locked and Dispatch Disabled State Transitions Relating to dis_dsp and loc_cpu- 30 -

Table 5.1 Specifications of the Task Management Function.........................................................- 63 -

Table 5.2 List of Task Management Function Service Call...........................................................- 63 -

Table 5.3 Specifications of the Task Dependent Synchronization Function ................................- 84 -

Table 5.4 List of Task Dependent Synchronization Service Call ..................................................- 84 -

Table 5.5 Specifications of the Semaphore Function ...................................................................- 100 -

Table 5.6 List of Semaphore Function Service Call.....................................................................- 100 -

Table 5.7 Specifications of the Eventflag Function......................................................................- 108 -

Table 5.8 List of Eventflag Function Service Call .....................................................................- 108 -

Table 5.9 Specifications of the Data Queue Function..................................................................- 118 -

Table 5.10 List of Dataqueue Function Service Call....................................................................- 118 -

Table 5.11 Specifications of the Mailbox Function.......................................................................- 127 -

Table 5.12 List of Mailbox Function Service Call ........................................................................- 127 -

Table 5.13 Specifications of the Fixed-size memory pool Function.............................................- 135 -

Table 5.14 List of Fixed-size memory pool Function Service Call ..............................................- 135 -

Table 5.15 Specifications of the Variable-size memory Pool Function........................................- 143 -

Table 5.16 List of Variable -size memory pool Function Service Call.........................................- 143 -

Table 5.17 Specifications of the Time Management Function ....................................................- 150 -

Table 5.18 List of Time Management Function Service Call ......................................................- 150 -

Table 5.19 Specifications of the Cyclic Handler Function.........................................................- 156 -

Table 5.20 List of Cyclic Handler Function Service Call.............................................................- 156 -

Table 5.21 Specifications of the Alarm Handler Function...........................................................- 162 -

Table 5.22 List of Alarm Handler Function Service Call.............................................................- 162 -

Table 5.23 List of System Status Management Function Service Call ......................................- 168 -

Table 5.24 List of Interrupt Management Function Service Call...............................................- 182 -

Table 5.25 List of System Configuration Management Function Service Call..........................- 184 -

Table 5.26 Specifications of the Short Data Queue Function......................................................- 187 -

Table 5.27 List of Long Dataqueue Function Service Call ..........................................................- 187 -

Table 5.28 List of Reset Function Service Call.............................................................................- 196 -

Table 7.1 C Language Variable Treatment...................................................................................- 212 -

Table 8.1 Numerical Value Entry Examples ....................................................................................227

Table 8.2 Operators............................................................................................................................ 228

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 -

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. 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,

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.

Development Period

Program Size

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.

On condition that the ROM program burning step need not be performed.

- 7 -

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

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 -

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

ctual

Kernel

Remote control

Task

Figure 3.6 Task Switching

The example presented in Figure 3.7

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.

It is figure where all the stack areas of the task were arranged in the same section.

- 11 -

Memory map

Remote control

Task

Key input

Tas k

LED illumination

Task

Stack section

Real-time

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

FLG

R7R5

R6R4

R3R1

R2R0

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

<= OS

Processing

Task S election

Task => S P

LED illumination Task

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

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

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 -

Service Calls from a Handler That Caused an Interrupt during Task Execution

eduling (task switching) is initiated by the ret_int service call

Sch

(See Figure 3.11).

TaskA Interrupt handler

Interrupt

Save Registers

iset_flg

Service call processing

Restore Registers

ret_int

Task selection

SP <= User

Scheduler

TaskB

Restore Registers

Figure 3.11 Processing Procedure for a Service Call a Handler that caused an interrupt during Task

Execution

The ret_int service call is issued automatically when kernel interrupt handler is written in C language (when #pragma INTHANDLER speci-

fied)

- 17 -

Service Calls from a Handler That Caused an Inte

rrupt during Service Call Processing

Scheduling (task switching) is initiated after the system returns to the interrupted service call processing (See Figure 3.12).

TaskA

Interrupt handler

wup_tsk

Interrupt

Save Registers

SP <= System

Task selection

SP <= User

Restore Registers

Save

iset_flg

Restore Registers

ret_int

Service call processing

TaskB

Figure 3.12 Processing Procedure for a Service Call from a Handler that caused an interrupt during

Service Call Processing

- 18 -

Service Calls from a Handler That Caused an Interrupt during Handler Execution

s think of a situation in which an interrupt occurs during handler execution (this handler is hereinafter referred to as

Let u handler A for explanation purposes). When task switching is called for as a handler (hereinafter referred to as handler B) that caused an interrupt during handler A execution issued a service call, task switching does not take place during the execution of the service call (ret_int service call) returned from handler B, but is effected by the ret_int service call from handler A (See Figure 3.13).

nterrupt

TaskA

Interrupt

Interrupt handler A

Save Registers

SP <= System

Restore Register

ret_int

Interrupt handler A

Save Registers

iset_flg

Restore Register

Service call processing

Task selection

SP <= User

Restore Registers

TaskB

ret_int

Figure 3.13 Processing Procedure for a service call from a Multiplex interrupt Handler

- 19 -

3.3 Object

The object operated by the service call of a semaphore, a task, etc. is called an "object." An object is identified by the ID number

3.3.1 The specification method of the object in a service call

Each task is identified by the ID number internally in MR100. For example, the system says, "Start the task having the task ID number 1." However, if a task number is directly written in a program, the resultant program would be very low in readability. If, for

instance, the following is entered in a program, the programmer is constantly required to know what the No. 2 task is.

act_tsk(2);

Further, if this program is viewed by another person, he/she does not understand at a glance what the No. 2 task is. To avoid such inconvenience, the MR100 provides means of specifying the task by name (function or symbol name).

The program named "configurator cfg100 ,"which is supplied with the MR100, then automatically converts the task name to the task ID number. This task identification system is schematized in Figure 3.14.

sta_tsk(Task name)

Name

Configurator

ID number

Starting the task having the designated ID number

Real-time OSProgram

Figure 3.14 Task Identification

act_tsk(ID_task);

This example specifies that a task corresponding to "ID_task" be invok ed. It should also be noted that task name-to-ID number conversion is effected at the time of program generation. Therefore,

the processing speed does not decrease due to this conversion feature.

- 20 -

3.4 Task

This section describes how tasks are managed by MR100.

3.4.1 Task Status

The real-time OS monitors the task status to determine whether or not to execute the tasks. Figure 3.15 shows the relationship between key input task execution control and task status. When there is a key input, the

key input tas waits for key input, task execution is not needed. In that situation, the key inpu t task in the WAITING state.

k must be executed. That is, the key input task is placed in the execution (RUNNING) state. While the system

Key input

Task

Key input processing

RUNNIG state WAITING state RUNNING state

Waiting for key input

Key input

rocessing

Figure 3.15 Task Status

The MR100 controls the following six different states including the RUNNING and WAITING states.

1. RUNNING state

2. READY state

3. WAITING state

4. SUSPENDED state

5. WAITING-SUSPENDED state

6. DORMANT state

Every task is in one of the above six different states. Figure 3.16 shows task status transition.

- 21 -

READY state

MPU execlusive right acquisition

MPU execlusive right relinquishment

WAITING state

RUNNING state

Entering the WAITING state

SUSPENDED state clear request from other task

WAITING-SUSPENDED

SUSPEND request from other task

state

WAITING state clear

Forced termin ation request from other task

SUSPENDED

SUSPENDED state clear request

Forced termination request from other task

state

DORMANT

state

Task activation

Figure 3.16 MR100 Task Status Transition

1. RUNNING state

In this state, the task is being executed. Since only one microcomputer is used, it is natural that only one task is being executed. The currently executed task changes into a different state when any of the following conditions occurs.

♦ The task has normally terminated itself by ext_tsk service call. ♦ The task has placed itself in the WAITING.

♦ Since the service call was issued from the RUNNING state task, the WAITING state of another

task with a priority higher than the RUNNING state task is cleared.

♦ Due to interruption or other event occurrence, the interrupt handler has placed a different task

having a higher priority in the READY state.

♦ The priority assigned to the task has been changed by chg_pri or ichg_pri service call so that the

priority of another READY task is rendered higher.

♦ When the ready queue of the issuing task priority is rotated by the rot_rdq or irot_rdq service call

and control of execution is thereby abandoned

When any of the above conditions occurs, rescheduling takes place so that the task having the highest priority among those in the RUNNING or READY state is placed in the RUNNING state, and the execution of that task starts.

2. READY state

The READY state refers to the situation in which the task that meets the task execution conditions is still waiting for execution because a different task having a higher priority is currently being executed. When any of the following conditions occurs, the READY task that can be executed second according to the ready queue

is placed in the RUNNING state.

♦ A currently executed task has normally terminated itself by ext_tsk service call.

By issuing dly_tsk, slp_tsk, tslp_tsk, wai_flg, twai_flg, wai_sem, twai_sem, rcv_mbx, trcv_mbx,snd_dtq,tsnd_dtq,rcv_dtq, trcv_dtq,

vtsnd_dtq, vsnd_dtq,vtrcv_dtq,vrcv_dtq, get_mpf, and tget_mpf service call.

- 22 -

♦ A currently executed task has placed itself in the WAITING state.10 ♦ A currently executed task has changed its own priority by chg_pri or ichg_pri service call so that

the priority of a different READY task is rendered higher.

♦ Due to interruption or other event occurrence, the priority of a currently executed task has been

changed so that the priority of a different READY task is rendered higher.

♦ When the ready queue of the issuing task priority is rotated by the rot_rdq or irot_rdq service call

and control of execution is thereby abandoned

3. WAITING state

When a task in the RUNNING state requests to be placed in the WAITING state, it exits the RUNNING state and enters the WAITING state. Th e WAITING state is usua lly used as the condition in which the completion of I/O device I/O operation or the processing of some other task is awaited. The task goes into the WAITING state in one of the following ways.

♦ The task enters the WAITING state simply when the slp_tsk service call is issued. In this case, the

task does not go into the READY state until its WAITING state is cleared explicitly by some other task.

♦ The task enters and remains in the WAITING state for a specified time period when the dly_tsk

service call is issued. In this case, the task goes into the READY state when the specified time has elapsed or its WAITING state is cleared explicitly by some other task.

♦ The task is placed into WAITING state for a wait request by the wai_flg, wai_sem, rcv_mbx,

snd_dtq, rcv_dtq, vsnd_dtq, vrcv_dtq, or get_mpf service call. In this case, the task goes from WAITING state to READY state when the request is met or WAITING state is explicitly canceled by another task.

♦ The tslp_tsk, twai_flg, twai_sem, trcv_mbx, tsnd_dtq, trcv_dtq, vtsnd_dtq, vtrcv_dtq and tget_mpf

service calls are the timeout-specified versions of the slp_tsk, wai_flg, wai_sem, rcv_mbx, snd_dtq, rcv_dtq, vsnd_dtq, vrcv_dtq and get_mpf service calls. The task is placed into WAITING state for a wait request by one of these service calls. In this case, the task goes from WAITING state to READY state when the request is met or the specified time has elapsed.

♦ If the task is placed into WAITING state for a wait request by the wai_flg, wai_sem, rcv_mbx,

snd_dtq, rcv_dtq, vsnd_dtq, vrcv_dtq, get_mpf, twai_flg, twai_sem, trcv_mbx, tsnd_dtq, trcv_dtq, vtsnd_dtq, vtrcv_dtq and tget_mpf service call, the task is queued to one of the following waiting queues depending on the request.

z Event flag waiting queue z Semaphore waiting queue z Mailbox message reception waiting queue z Data queue data transmission waiting queue z Data queue data reception waiting queue z Short data queue data transmission waiting queue z Short data queue data reception waiting queue z Fixed-size memory pool acquisition waiting queue

4. SUSPENDED state

When the sus_tsk service call is issued from a task in the RUNNING state or the isus_tsk service call is issued from a handler, the READY task designated by the service call or the currently executed task enters the SUSPENDED state. If a task in the WAITING state is placed in this situation, it goes into the WAITING-SUSPENDED state.

The SUSPENDED state is the condition in which a READY task or currently executed task

is excluded from scheduling to halt processing due to I/O or other error occurrence. That is, when the suspend request is made to a READY task, that task is excluded from the execution queue.

Note that no queue is formed for the suspend request. Therefore, the suspend request can only be made to the

Depends on the dly_tsk, slp_tsk, tslp_tsk, wai_flg, twai_flg, wai_sem, twai_sem, rcv_mbx, trcv_mbx,snd_dtq,tsnd_dtq,rcv_dtq, trcv_dtq,

vtsnd_dtq, vsnd_dtq,vtrcv_dtq,tget_mpf, get_mpf and vrcv_dtq service call.

If the task under execution is placed into a forcible wait state by the isus_tsk service call from the handler, the task goes from an executing state directly to a forcible wait state. Please note that in only this case exceptionally, it is possible that a task will go from an executing state directly to a forcible wait state.

- 23 -

tasks in the RUNNING, READY, or WAITING state.12 If the suspend request is made to a task in the SUSPENDED state, an error code is returned.

5. WAITING-SUSPENDED

If a suspend request is issued to a task currently in a WAITING state, the task goes to a WAITING-SUSPENDED state. If a suspend request is issued to a task that has been placed into a WAITING state for a wait request by the slp_tsk, wai_flg, wai_sem, rcv_mbx, snd_dtq, rcv_dtq, vsnd_dtq, vrcv_dtq, get_mpf, tslp_tsk, twai_flg, twai_sem, trcv_mbx, tsnd_dtq, trcv_dtq, vtsnd_dtq, vtrcv_dtq or tget_mpf service call, the task goes to a WAITING-SUSPENDED state.

When the wait condition for a task in the WA ITING-SUSPENDED state is cleared, that task goes into the SUSPENDED state. It is conceivable that the wait condition may be cleared, when any of the following conditions occurs.

♦ The task wakes up upon wup_tsk, or iwup_tsk service call issuance. ♦ The task placed in the WAITING state by the dly_tsk or tslp_tsk service call wakes up after the

specified time elapse.

♦ The request of the task placed in the WAITING state by the wai_flg , wai_sem, rcv_mbx, snd_dtq,

rcv_dtq, vsnd_dtq, vrcv_dtq, get_mpf, tslp_tsk, twai_flg, twai_sem, trcv_mbx, tsnd_dtq, trcv_dtq, vtsnd_dtq, vtrcv_dtq or tget_mpf service call is fulfilled.

♦ The WAITING state is forcibly cleared by the rel_wai or irel_wai service call

When the SUSPENDED state clear request by rsm_tsk or irsm_tsk is made to a task in the WAITING-SUSPENDED state, that task goes into the WAITING state. Since a task in the SUSPENDED state cannot request to be placed in the WAITING state, status change from SUSPENDED to WAITING-SUSPENDED does not possibly occur.

6. DORMANT

This state refers to the condition in which a task is registered in the MR100 system but not activated. This task state prevails when either of the following two conditions occurs.

♦ The task is waiting to be activated. ♦ The task is normally terminated by ext_tsk service call or forcibly terminated by ter_tsk service

call.

If a forcible wait request is issued to a task currently in a wait state, the task goes to a WAITING-SUSPENDED state.

- 24 -

3.4.2 Task Priority and Ready Queue

In the kernel, several tasks may simultaneously request to be executed. In such a case, it is necessary to determine which task the system should execute first. To properly handle this kind of situation, the system organizes the tasks into proper execution priority and starts execution with a task having the highest priority. To comple te task execution quickly, tasks related to processing operations that need to be performed immediately should be given higher priorities.

The MR100 permits giving the same priority to several tasks. To provide proper control over the READY task execution order, the kernel generates a task execution queue called "ready queue." The ready queue structure is shown in Figure

The ready queue is provided and controlled for each priority level. The first task in the ready queue having the

3. highest priority is placed in the RUNNING state.

Priority

TCB

TCBTCB

Figure 3.17 Ready Queue (Execution Queue)

TCB

The TCB(task control block is described in the next chapter.)

The task in the RUNNING state remains in the ready queue.

- 25 -

3.4.3 Task Priority and Waiting Queue

In The standard profiles in µITRON 4.0 Specification support two waiting methods for each object. In one method, tasks are placed in a waiting queue in order of priority (TA_TPRI attribute); in another, tasks are placed in a waiting queue in order of FIFO (TA_TFIFO).

Figure 3.18 and Figure 3.19 depict the manner in which tasks are placed in a "taskA," and "taskB."

ID No.

taskA taskC taskD

Priority 1 Priority 5 Priority 6

taskB

Figure 3.18 Waiting queue of the TA_TPRI attribute

ID No.

waiting queue in order of "taskD," "taskC,"

Priority 9

taskD taskA taskB

Priority 9 Priority 6 Priority 1

taskC

Figure 3.19 Waiting queue of the TA_TFIFO attribute

Priority 5

- 26 -

3.4.4 Task Control Block(TCB)

The task control block (TCB) refers to the data block that the real-time OS uses for individual task status, priority, and other control purposes.

The MR100 manages the following task information as the task control block

• Task connection pointer

Task connection pointer used for ready queue formation or other purp oses.

• Task status

• Task priority

• Task register information and other data

• Wake-up counter

Task wake-up request storage area.

• Flag wait mode

This is a wait mode during eventflag wait.

• Flag wait pattern

This area stores the flag wait pattern when using the eventflag wait service call (wai_flg, twai_flg). No flag wait pattern area is allocated when the eventflag is not used.

• Startup request counter

This is the area in which task startup requests are accumulated.

The task control block is schematized in Figure 3.20.

TCB

Task Connection pointer

Status

storage stack area pointer(current SP value)

TCB TCB

Priority

Wake-up counter

Flag wait mode

ctivation counter

Flag wait pattern

Called the task context

This area is allocated only when the timeout function is used.

Figure 3.20 Task control block

- 27 -

3.5 System States

3.5.1 Task Context and Non-task Context

The system runs in either context state, "task context" or "non-task context." The differences between the task content and non-task context are shown in Table 3-1. Task Context and Non-task Context.

Table 3.1 Task Context an d Non-task Context

Task context Non-task context Invocable service call Those that can be invoked from

task context

Task scheduling Occurs when the queue state has

changed to other than dispatch disabled and CPU locked states.

Stack User stack System stack

The processes executed in non-task context include the following.

Those that can be invoked from non-task context

It does not occur.

1. Interrupt Handler

A program that starts upon hardware interruption is called the interrupt handler. The MR100 is not concerned in interrupt handler activation. Therefore, the interrupt handler entry address is to be directly written into the interrupt vector table.

There are two interrupt handlers: Non-kernel interrupts (OS independent interrupts) and kernel interrupts (OS dependent interrupts). For details about each type of interrupt, refer to Section 3.6.

stem clock interrupt handler (isig_tim) is one of these interrupt handlers.

The sy

2. Cyclic Handler

The cyclic handler is a program that is started cyclically every preset time. The set cyclic handler may be started or stopped by the sta_cyc(ista_cyc) or stp_cyc(istp_cyc) service call.

The cyclic handler startup time of day is unaffected by a change in the time of day by set_tim(iset_tim).

3. Alarm Handler

The alarm handler is a handler that is started after the lapse of a specified relative time of day. The alarm handler startup time of day is determined by a time of day relative to the time of day set by sta_alm(ista_alm), and is unaffected by a change in the time of day by set_tim(iset_tim).

The cyclic and alarm handlers are invoked by a subroutine call from the system clock interrupt (timer interrupt) handler. Therefore, cyclic and alarm handlers operate as part of the system clock interrupt handler. Note that when the cyclic or alarm handler is invoked, it is executed in the interrupt priority level of the system clock interrupt.

- 28 -

Timer interrupt

Task

System clock interrupt handler

Cyclic handler

larm handler

Subroutine call

RTS

Figure 3.21 Cyclic Handler/Alarm Handler Activation

- 29 -

3.5.2 Dispatch Enabled/Disabled States

The system assumes either a dispatch enabled state or a dispatch disabled state. In a dispatch disabled state, no task scheduling is performed. Nor can service calls be invoked that may cause the service call issuing task to enter a wait state.

The system can be placed into a dispatch disabled state or a dispatch enabled state by the dis_dsp or ena_dsp service call, respectively. Whether the system is in a dispatch disabled state can be known by the sns_dsp service call.

3.5.3 CPU Locked/Unlocked States

The system assumes either a CPU locked state or a CPU unlocked state. In a CPU locked state, all external interrupts are disabled against acceptance, and task scheduling is not performed either.

The system can be placed into a CPU locked state or a CPU unlocked state by the loc_cpu(iloc_cpu) or unl_cpu(iunl_cpu) service call, respectively. Whether the system is in a CPU locked state can be known by the sns_loc service call.

The service calls that can be issued from a CPU locked state are limited to those that are listed in Table 3-2.

Table 3.2 Invocable Service Calls in a CPU Locked State

loc_cpu iloc_cpu unl_cpu iunl_cpu ext_tsk exd_tsk sns_tex sns_ctx sns_loc sns_dsp sns_dpn

3.5.4 Dispatch Disabled and CPU Locked States

In µITRON 4.0 Specification, the dispatch disabled and the CPU locked states are clearly discriminated. Therefore, if the unl_cpu service call is issued in a dispatch disabled state, the dispatch disabled state remains intact and no task scheduling is performed. State transitions are summarized in Table 3.3.

able 3.3 CPU Locked and Dispatch Disabled S tate Transitions Relating to d i s_dsp and loc_cpu

State

number

CPU locked

state

Content of state

Dispatch disabled

state

dis_dsp executed

ena_dsp executed

loc_cpu executed

1 O X X X => 1 => 3 2 O O X X => 2 => 4 3 X X => 4 => 3 => 1 => 3 4 X O => 4 => 3 => 2 => 4

unl_cpu executed

If a service call not issuable is issued when dispatch disabled, MR100 doesn't return the error and doesn't guarantee the operation.

MR100 does not return an error even when an uninvocable service call is issued from a CPU locked state, in which case, however, its operation cannot be guaranteed.

- 30 -

3.6 Regarding Interrupts

3.6.1 Types of Interrupt Handlers

MR100's interrupt handlers consist of kernel interrupt handlers and non-kernel interrupt handlers. The following shows the definition of each type of interrupt handler.

• Kernel interrupt handler

An interrupt handler whose interrupt priority level is lower than a kernel interruption mask level is called kernel interrupt handler. That is, interruption priority level is from 1 to system_IPL. A service call can be issued within a kernel interrupt handler. However, interrupt is delayed until it becomes receivable the kernel interrupt handler generated during service call processing.

• Non-kernel interrupt handler

An interrupt handler whose interrupt priority level is higher than a kernel interrupt mask level is called no n-ke rne l interrupt handler. That is, interruption priority level is from system_IPL+1 to 7. A service call cannot be issued within non-kernel interrupt handler. However, the non-kernel interrupt handler is able to be recieved during service call processing, even if it is the section where it is not able to receive a kernel interrupt handler:

Figure 3.22 shows the relationship between the non-kernel interrupt handlers and kernel interrupt handlers where the kernel

level is set to 3.

mask

Kernel mask level

Low

High

0 1 2 3 4 5 6 7

Kernel

Interrupt handler

Figure 3.22 Interrupt handler IPLs

3.6.2 The Use of Non-maskable Interrupt

Non-maskable interrupt ( ex. NMI interrupt ,Watchdog Timer interrupt) are treated as a non-kernel interrupt handler.

Non-kernel

Interrupt handler

- 31 -

3.6.3 Controlling Interrupts

Interrupt enable/disable control in a service call is accomplished by IPL manipulation. The IPL value in a service call is set to the kernel mask level(OS interrupt disable level = system.IPL) in order to disable interrupts for the kernel interrupt handler. In sections where all interrupts can be enabled, it is returned to the initial IPL value when the service call was invoked.

• For service calls that can be issued from only task context.

When the I flag before issuing a service call is 1.

Task Service call issued

I flag

IPL

When the I flag before issuing a service call is 0.

Task Service call issued

I flag

IPL

0 system.IPL system.IPL

Service call processing

1 0

Service call processing

1 0

Figure 3.23 Interrupt control in a Service Call that can be Issued from only a Task

- 32 -

• For service calls that can be issued from only non-task context or from both task context and non-task

context.

When the I flag before issuing a service call is 1

Task or Handler

I flag

IPL

When the I flag before issuing a service call is 0

Task or Handler

I flag

IPL

Service call issued

4 system.IPL system.IPL

Service call issued

4 system.IPL system.IPL

service call processing

1 0

0 0

Task or Handler

Figure 3.24 Interrupt control in a Service Call that can be Issued from a Task-independent

As shown in Figure 3.23 and Figure 3.24, the interrupt enable flag and IPL change in a service call. For this reason, if you wan

t to disable interrupts in a user application, Renesas does not recommend using th e method for manipulating the inter-

rupt disable flag and IPL to disable the interrupts. The following two methods for interrupt control are recommended:

1. Modify the interrupt control register (SFR) for the interrupt you want to be disabled.

2. Use service calls loc_cpu(iloc_cpu) and unl_cpu(iunl_cpu).

The interrupts that can be controlled by the loc_cpu service call are only the kernel interrupt. Use method 1 to control the no

n-kernel interrupts.

- 33 -

3.7 Stacks

3.7.1 System Stack and User Stack

The MR100 provides two types of stacks: system stack and user stack.

• User Stack

One user stack is provided for each task. Therefore, when writing applications with the MR100, it is necessary to furnish the stack area for each task.

• System Stack

This stack is used within the MR100 (during service call processing). When a service call is issued from a task, the MR100 switches the stack from the user stack to the system stack (See Figure 3.25). The system

stack use the interrupt stack(ISP).

Task MR100 service call processing

User Stack

Save Registers

XXX_XXX( )

Stack switching

Service call

processing

System Stack

Tas k sel ec tion

Stack switching

Restore Registers

User Stack

Figure 3.25 System Stack and User Stack

Switchover from user stack to system stack occurs when an interrupt of vector numbers 0 to 127 is generated. Consequently, all stacks used by the interrupt handler are the system stack.

- 34 -

4. Kernel

4.1.1 Module Structure

The MR100 kernel consists of the modules shown in Figure 4.1. Each of these modules is composed of functions that exercise individual module features.

The MR100 kernel is supplied in the form of a library, and only necessary features are linked at the time of system generation. More specifically, only the functions used are chosen from those which comprise these modules and linked by means of the Linkage Editor. However, the scheduler module, part of the task management module, and part of the time management module are linked at all times because they are essential feature functions.

The applications program is a program created by the user. It consists of tasks, interrupt handler, alarm handler, and cyclic handler.

User Modu le

Application Program

Task

Ma na g em e nt

Task-dep endent synchronization

System configuration

Management

Alarm/Cyclic handler

Mailbo x

Eventflag

Data qu eue

Semaphore

Memorypool

Management

short

Data queue

Scheduler

Time

Management

System stae

Ma nage me nt

Interrupt

Ma na gem ent

MR100 kernel

Har dw ar e

R32C/100 Microcomputer

Figure 4.1 MR100 Structure

For details, See 4.1.11.

- 35 -

4.1.2 Module Overview

The MR100 kernel modules are outlined below.

• Scheduler

Forms a task processing queue based on task priority and controls operation so that the high-priority task at the beginning in that queue (task with small priority value) is executed.

• Task Management Module

Exercises the management of various task states such as the RUNNING, READY, WAITING, and SUSPENDED state.

• Task Synchronization Module

Accomplishes inter-task synchronization by changing the task status from a different task.

• Interrupt Management Module

Makes a return from the interrupt handler.

• Time Management Module

Sets up the system timer used by the MR100 kernel and starts the user-created alarm handler

dler.

• System Status Management Module

Gets the system status of MR100.

• System Configuration Management Module

Reports the MR100 kernel version number or other information.

• Synchronization and Communication Module

This is the function for synchronization and communication among the tasks. The following four functional modules are offered.

♦ Eventflag

Checks whether the flag controlled within the MR100 is set up and then determines whether or not to initiate task execution. This results in accomplishing synchronization between tasks.

and cyclic han-

♦ Semaphore

Reads the semaphore counter value controlled within the MR100 and then determines whether or not to initiate task execution. This also results in accomplishing synchronization between tasks.

♦ Mailbox

Provides inter-task data communication by delivering the first data address.

♦ Data queue

Performs 32-bit data communication between tasks.

• Memory pool Management Module

Provides dynamic allocation or release of a memory area used by a task or a handler.

• Extended Function Module

Outside the scope of µITRON 4.0 Specification , this function performs reset processing on objects and short data queue function.

This handler actuates once only at preselected times.

This handler periodically actuates.

- 36 -

4.1.3 Task Management Function

The task management function is used to perform task operations such as task start/stop and task priority updating. The MR100 kernel offers the following task management function service calls.

• Activate Task (act_tsk, iact_tsk)

Activates the task, changing its status from DORMANT to either READY or RUNNING. In this service call, unlike in sta_tsk(ista_tsk), startup requests are accumulated, but startup code cannot be specified.

• Activate Task (sta_tsk, ista_tsk)

Activates the task, changing its status from DORMANT to either READY or RUNNING. In this service call, unlike in act_tsk(iact_tsk), startup requests are not accumulated, but startup code can be specified.

• Terminate Invoking Task (ext_tsk)

When the issuing task is terminated, its state changes to DORMANT state. The task is therefore not executed until it is restarted. If startup requests are accumulated, task startup processing is performed again. In that case, the issuing task behaves as if it were reset. If written in C language, this service call is automatically invoked at return from the task regardless of whether it is explicitly written when terminated.

• Terminate Task (ter_tsk)

Other tasks in other than DORMANT state are forcibly terminated and placed into DORMANT state. If startup requests are accumulated, task startup processing is performed again. In that case, the task behaves as if it was reset. (See Figure 4.2).

TaskA

ter_tsk(B)

Task B reset

Figure 4.2 Task Resetting

Startup request count > 0

TaskB

Ter mi nat ed

• Change Task Priority (chg_pri, ichg_pri)

If the priority of a task is changed while the task is in READY or RUNNING state, the ready queue also is updated. (See Figure 4.3). Furtherm also is updated. (See Figure 4.4).

ore, if the target task is placed in a waiting queue of objects with TA_TPRI attribute, the waiting queue

- 37 -

Priority

ID Number

１

Task A

Task C

When the priority of task B has been changed from 3 to 1

Task B

Task FTask E

Figure 4.3 Alteration of task priority

Task D

２

３

ｎ

taskA

Priority 1 Priority 2 Priority 3 Priority 4

When the priority of Task B is changed into 4

taskB

Figure 4.4 Task rearrangement in a waiting queue

• Reference task priority (get_pri, iget_pri)

Gets the priority of a task.

• Reference task status (simple version) (ref_tst, iref_tst)

Refers to the state of the target task.

• Reference task status (ref_tsk, iref_tsk)

Refers to the state of the target task and its priority, etc.

taskC taskB

- 38 -

4.1.4 Synchronization functions attached to task

The task-dependent synchronization functions attached to task is used to accomplish synchronization between tasks by placing a task in the WAIT, SUSPENDED, or WAIT-SUSPENDED state or waking up a WAIT state task.

The MR100 offers the following task incorporated synchronization service calls.

• Put Task to sleep (slp_tsk,tslp_tsk)

• Wakeup task (wup_tsk, iwup_tsk)

Wakeups a task that has been placed in a WAIT state by the slp_tsk or tslp_tsk service call. No task can be waked up unless they have been placed in a WAITING state by. If a wakeup request is issued to a task that has been kept waiting for conditions other than the slp_tsk or tslp_tsk service call or a task in other than DORMANT state by the wup_tsk or iwup_tsk service call, that wakeup request only will be accumulated. Therefore, if a wakeup request is issued to a task RUNNING state, for example, this wakeup request is temporarily stored in memory. Then, when the task in RUNNING state is going to be placed into WAITING state by the slp_tsk or tslp_tsk service call, the accumulated wakeup request becomes effective, so that the task continues executing again without going to W AITING state. (See Figure 4.5).

• Cancel Task Wakeup Requests (can_wup)

Clears the stored wakeup request.(See Figure 4.6).

Task

Wakeup request count

Task

Wakeup r equest c ount

wup_tsk wup_tsk wup_tsk

slp_tsk slp_tsk

0 0 1 2 1

Figure 4.5 Wakeup Request Storage

wup_tsk wup_tsk can_wup

slp_tsk slp_tsk

0 0 1 0

Figure 4.6 Wakeup Request Cancellation

Note that tasks in WAITING state, but kept waiting for the following conditions are not awaken.

Eventflag wait state, semaphore wait state, data transmission wait state, data reception wait state, timeout wait state, fixed length memory pool acquisition wait, short data transmission wait, or short data reception wait

- 39 -

• Suspend task (sus_tsk, isus_tsk)

• Resume suspended task (rsm_tsk, irsm_tsk)

These service calls forcibly keep a task suspended for execution or resume execution of a task. If a suspend request is issued to a task in READY state, the task is placed into SUSPENDED state; if issued to a task in WAIT ING state, the task is placed into WAITING-SUSPENDED state. Since MR100 allows only one forcible wait request to be nested, if sus_tsk is issued to a task in a forcible wait state, the error E_QOVR is returned. (See Figure 4.7).

E_QOVR

rsm_tsk sus_tsk

READY state

Task

RUNNING

state

sus_tsk

SUSPENDED

state

WAITING-

SUSPENDED

WAITING stateWAI TI NG st at e

state

Number of

suspension

request

0 1 1 0

Figure 4.7 Forcible wait of a task and resume

- 40 -

–

• Forcibly resume suspended task (frsm_tsk, ifrsm_tsk)

Clears the number of suspension requests nested to 0 and forcibly resumes execution of a task. Since MR100 allows only one suspension request to be nested, this service call behaves the same way as rsm_tsk and irsm_tsk..(See Figure 4.8).

frsm_tsk

READYstate

Task

READY state

sus_tsk

SUSPENDED

state

WAI TI NG

state

WAITING state

Number of

suspension

requests

Figure 4.8 Forcible wait of a task and forcible resume

WAITING

SUSPENDED

state

0 1 0

• Release task from waiting (rel_wai, irel_wai)

Forcibly frees a task from WAITING state. A task is freed from WAITING state by this service call when it is in one of the following wait states.

♦ Timeout wait state ♦ Wait state entered by slp_tsk service call (+ timeout included) ♦ Event flag (+ timeout included) wait state ♦ Semaphore (+ timeout included) wait state ♦ Message (+ timeout included) wait state ♦ Data transmission (+ timeout included) wait state ♦ Data reception (+ timeout included) wait state ♦ Fixed–size memory block (+ timeout included) acquisition wait state ♦ Short data transmission (+ timeout included) wait state ♦ Short data reception (+ timeout included) wait state

- 41 -

• Delay task (dly_tsk)

Keeps a task waiting for a finite length of time. Figure 4.9 shows an example in which execution of a task is kept

g for 10 ms by the dly_tsk service call. The timeout value should be specified in ms units, and no t in time

waitin tick units.

Task

dly_tsk(10)

10msec

Figure 4.9 dly_tsk service call

- 42 -

4.1.5 Synchronization and Communication Function (Semaphore)

The semaphore is a function executed to coordinate the use of devices and other resources to be shared by several tasks in cases where the tasks simultaneously require the use of them. When, for instance, four tasks simultaneously try to acquire a total of only three communication lines as shown in Figure 4.10, communication line-to-task connections can be made

out incurring contention.

with

Communication

Line

Communication

Line

Communication

Line

Task

Semaphore

Task

Figure 4.10 Exclusive Control by Semaphore

The semaphore has an internal semaphore counter. In accordance with this counter, the semaphore is acquired or released to prevent competition for use of the same resource.(See Figure 4.11).

cquired

Task

Returned after use

Figure 4.11 Semaphore Counter

The MR100 kernel offers the following semaphore synchronization service calls.

• Release Semaphore Resource(sig_sem, isig_sem)

Releases one resource to the semaphore. This service call wakes up a task that is waiting for the semaphores service, or increments the semaphore counter by 1 if no task is waiting for the semaphores service.

• Acquire Semaphore Resource(wai_sem, twai_sem)

Waits for the semaphor es service. If the semaphore counte r value is 0 (zero), the semaphore cannot be acquired. Therefore, the WAITING state prevails.

• Acquire Semaphore Resource(pol_sem, ipol_sem)

Acquires the semaphore resource. If there is no semaphore resource to acquire, an error code is returned and the WAITING state does not prevail.

- 43 -

• Reference Semaphore Status (ref_sem, iref_sem)

Refers the status of the target semaphore. Checks the count value and existence of the wait task for the target semaphore. Figure 4.12 shows example task execution control provided by the wai_sem and sig_sem service calls.

Task

Semaphore Counter

wai_sem sig_sem

wai_sem

WAI T state

3 2 1 0 0x

Figure 4.12 Task Execution Control by Semaphore

- 44 -

4.1.6 Synchronization and Communication Function (Eventflag)

The eventflag is an internal facility of MR100 that is used to synchronize the execution of multiple tasks. The eventflag uses a flag wait pattern and a 32-bit pattern to control task execution. A task is kept waiting until the flag wait conditions set are met.

It is possible to determine whether multiple waiting tasks can be enqueued in one eventflag waiting queue by specifying the eventflag attribute TA_WSGL or TA_WMUL.

Furthermore, it is possible to clear the eventflag bit pattern to 0 when the eventflag meets wait cond itions by specifying TA_CLR for the eventflag attribute.

There are following ev entflag service calls that are provided by the MR100 kernel.

• Set Eventflag (set_flg, iset_flg)

Sets the eventflag so that a task waiting the eventflag is released from the WAITING state.

• Clear Eventflag (clr_flg, iclr_flg)

Clears the Eventflag.

• Wait for Eventflag (wai_flg, twai_flg)

Waits until the eventflag is set to a certain pattern. There are two modes as listed below in which the even tflag is waited for.

♦ AND wait

Waits until all specified bits are set.

♦ OR wait

Waits until any one of the specified bits is set

• Wait for Eventflag (polling)(pol_flg, ipol_flg)

Examines whether the eventflag is in a certain pattern. In this service call, tasks are not placed in WAITING state.

• Reference Eventflag Status (ref_flg, iref_flg)

Checks the existence of the bit pattern and wait task for the target eventflag.

- 45 -

Figure 4.13 shows an example of task execution control by

the eventflag using the wai_flg and set_flg service calls. The eventflag has a feature that it can wake up multiple tasks collectively at a time. In Figure 4.13, there are six tasks linked one to another, task A to task F. When the flag pattern is set to 0xF by the set_flg

service call, t

he tasks that meet the wait conditions are removed sequentially from the top of the queue. In this diagram, the tasks that meet the wait conditions are task A, task C, and task E. Out of these tasks, task A, task C, and task E are removed from the queue.

If this event flag has a TA_CLR attribute, when the waiting of Task A is canceled, the bit pattern of the event flag will be set to 0, and Task C and Task E will not be removed from queue.

Flag queue Task A Task B Task C

Flag pattern

Wait pattern Wait mo de

0x0F

0xFF

AND

0x0F AND

set_flg

Task B

TaskD

0xFF AND

Task E

0xFF

Task F

0x10

Task F Task D

Flag pattern

0x0F

Figure 4.13 Task Execution Control by the Eventflag

- 46 -

4.1.7 Synchronization and Communication Function (Data Queue)

The data queue is a mechanism to perform data communication between tasks. In Figure 4.14, for example, task A can transmit data to the data queue and task B can receive the transmitted data from the data queue.

Data

Data Data

Task A

Figure 4.14 Data queue

Data in width of 32 bits can be transmitted to this data queue. The data queue has the function to accumulate data. The accumulated data is retrieved in order of FIFO

number of data that can be accumulated in the data queue is limited. If data is transmitted to the data queue that is full of data, the service call issuing task goes to a data transmission wait state.

There are following data queue service calls that are provided by the MR100 kernel.

Task B

. However, the

• Send to Data Queue(snd_dtq, tsnd_dtq)

The data is transmitted to the data queue. If the data queue is full of data, the task goes to a data transmission wait state.

• Send to Data Queue (psnd_dtq, ipsnd_dtq)

The data is transmitted to the data queue. If the data queue is full of data, the task returns error code without going to a data transmission wait state.

• Forced Send to Data Queue (fsnd_dtq, ifsnd_dtq)

The data is transmitted to the data queue. If the data queue is full of data, the data at the top of the data queue or the oldest data is removed, and the transmitted data is stored at the tail of the data queue.

• Receive from Data Queue (rcv_dtq, trcv_dtq)

The data is retrieved from the data queue. If the data queue has no data in it, the task is kept waiting until data is transmitted to the data queue.

• Receive from Data Queue (prcv_dtq,iprcv_dtq)

The data is received from the data queue. If the data queue has no data in it, the task returns error code without going to a data reception wait state.

• Reference Data Queue Status (ref_dtq,iref_dtq)

Checks to see if there are any tasks waiting for data to be entered in the target data queue and refers to the number of the data in the data queue.

First In First Out

- 47 -

4.1.8 Synchronization and Communication Function (Mailbox)

The mailbox is a mechanism to perform data communication between tasks. In Figure 4.15, for example, task A can drop a message into the mailbox and task B can retrieve the message from the mailbox. Since mailbox-based communication is achieved by transferring the start address of a message from a task to another, this mode of communication is performed at high speed independently of the message size.

The kernel manages the message queue by means of a link list. The application should prepare a header area that is to be used for a link list. This is called the message header. The message header and the area actually used by the application to store a message are called the message packet. The kernel rewrites the content of the message header as it manages the message queue. The message header cannot be rewritten from the application. The structure of the message queue is shown in Figure 4.16. The message header has its data types defined as shown below.

T_MSG: Mailbox message header T_MSG_PRI: Mailbox message header with priority included

Messages in any size can be enqueued in the message queue because the header area is reserved on the application side. In no event will tasks be kept waiting for transmission.

Messages can be assigned priority, so that messages will be received in order of priority beginning with the highest. In this case, TA_MPRI should be added to the mailbox attribute. If messages need to be received in order of FIFO, add TA_MFIFO to the mailbox attribute. be prioritized in which order they can receive a message, beginning with one that has the highest priority. In this case, add TA_TPRI to the mailbox attribute. If tasks are to receive a message in order of FIFO, add TA_TFIFO to the mailbox attrib-

ute.

Furthermore, if tasks in a message wait state are to receive a message, the tasks can

Message Message

TaskA

Figure 4.15 Mailbox

TaskB

It is in the mailbox definition "message_queue" of the configuration file that the TA_MPRI or TA_MFIFO attribute should be added.

It is in the mailbox definition "wait_queue" of the configuration file that the TA_TPRI or TA_TFIFO attribute should be added.

- 48 -

Message

queue

There are following data queue service calls that are provided by the MR100 kernel.

T_MSG header

Message A Message B Message C

Figure 4.16 Message queue

T_MSG header

• Send to Mailbox (snd_mbx, isnd_mbx)

Transmits a message. Namely, a message is dropped into the mailbox.

• Receive from Mailbox (rcv_mbx, trcv_mbx)

Receives a message. Namely, a message is retrieved from the mailbox. At this time, if the mailbox has no messages in it, the task is kept waiting until a message is sent to the mailbox.

• Receive from Mailbox (polling) (prcv_mbx, iprcv_mbx)

Receives a message. The difference from the rcv_mbx service call is that if the mailbox has no messages in it, the task returns error code without going to a wait state.

T_MSG header

• Reference Mailbox Status (ref_mbx, iref_mbx)

Checks to see if there are any tasks waiting for a message to be put into the target mailbox and refers to the message present at the top of the mailbox.

- 49 -

4.1.9 Memory pool Management Function(Fixed-size Memory pool)

A fixed-size memory pool is the memory of a certain decided size. The memory block size is specified at the time of a configuration. Figure 4.17 is a figure about the example of a fixed-size memory pool of operation.

• Acquire Fixed-size Memory Block (get_mpf, tget_mpf)

Acquires a memory block from the fixed-size memory pool that has the specified ID. If there are no blank memory blocks in the specified fixed-size memory pool, the task that issued this service call goes to WAITING state and is enqueued in a waiting queue.

• Acquire Fixed-size Memory Block (polling) (pget_mpf, ipget_mpf)

Acquires a memory block from the fixed-size memory pool that has the specified ID. The difference from the get_mpf and tget_mpf service calls is that if there are no blank memory blocks in the memory pool, the task returns error code without going to WAITING state.

Memory Block 1:

Memory Block 2:

Memory Block 3:

Fixed Length Memorypool

Used by TaskA

Used by TaskB

Figure 4.17 Memory Pool Management

Memory block ac quisition request

Memory block acquisition

Memory block ac quisition request

No blank memory blocks available

TaskC

TaskD

Goes to a wait state

• Release Fixed-size Memory Block (rel_mpf, irel_mpf)

Frees the acquired memory block. If there are any tasks in a wait state for the specified fixed-size memory pool, the task enqueued at the top of the waiting queue is assigned the freed memory block. In this case, the task changes its state from WAITING state to READY state. If there are no tasks in a wait state, the memory block is returned to the memory pool.

• Reference Fixed-size Memory Pool Status (ref_mpf, iref_mpf)

Checks the number and the size of blank blocks available in the target memory pool.

- 50 -

4.1.10 Variable-size Memory Pool Management Function

A variable-size memory pool refers to the one in which a memory block of any desired size can be acquired from the memory pool. The MR100 permits one of the following two memory pool management methods to be selected before the memory pool is used.

1. Normal block method

2. Small block method

Each of these methods are explained below.

[[Normal Block Method]]

The technique that allows you to arbitrary define the size of memory block acquirable from the memory pool is termed Variable-size scheme. The MR100 manages memory in terms of four fixed-size memory block sizes.

The MR100 calculates the size of individual blocks based on the maximum memory block size to be acquired. You specify the maximum memory block size using the configuration file.

• Equation for calculating four kinds of block sizes

a = (((max_memsize+(X-1))/ X × 8)+1) × 8 b = a × 2 c = a × 4 d = a × 8

max_memsize: the value specified in the configuration file X: data size for block control (8 byte)

• Example of a configuration file

If a variable-size memory pool is defined as shown above, the four kinds of fixed length block sizes are obtained from the define value of max_memsize as 56, 112, 224 and 448, respectively. Furthermore, the MR100 calculates the memory requested by the user based on a specified size to select the appropriate size from the four kinds of fixed length block sizes as it allocates the requested memory. In no event will a memory block other than these four kinds of size be allocated.

[[Small block method]]

Unlike the normal block method where memory is managed in four kinds of fixed length block sizes, the small block method manages memory in 12 kinds of fixed length block sizes. Since the block sizes in this method are prefixed as shown below, there is no need to specify a maximum size during configuration as in the normal block method.

The block sizes managed by the small block method are the following 12, beginning with the smallest: 24 bytes, 56 bytes, 120 bytes, 248 byt es, 5 04 by t e s, 1,016 bytes, 2,040 bytes, 4,088 bytes, 8,184 byte, 16 ,376 bytes, 32,760

bytes and 65,528 bytes.

variable_memorypool[]{

max_memsize = 400; <---- Maximum size

heap_size = 5000;

};

- 51 -

[[Comparison of Two Management Methods]]

• Processing speed

Generally speaking, the normal block method is faster in memory allocation/deallocation processing than the small block method.

• Memory usage efficiency

If the difference between the maximum and minimum sizes of memory to be acquired is 8 times or more, the small block method is higher in memory usage efficiency than the other method.

• Ease of configuration

For the normal block method, it is necessary that the maximum memory size to be acquired be known to the MR100. However, this is unnecessary for the small block method..

The variable-length memory pool management service calls provided by the MR100 include the following.

• Get a memory block (pget_mpl)

The block size specified by the user is acquired by first rounding it to the optimum block size among the four kinds of block sizes and then acquiring a memory block of the rounded size from the memory pool For example, if the user requests 200 bytes of memory, the requested size is rounded to 224 bytes, so that 224 bytes of memory is acquired. If a requested block of memory is successfully acquired, the start address of the acquired memory block and error code E_OK are returned. If memory acquisition fails, error code E_TMOUT is returned.

200 bytes

Rounding

224 bytes

Figure 4.18 pget_mpl processing

• Release Acquire Variable-size Memory Block (rel_mpl)

Releases a acquired memory block by pget_mpl service call.

Memorypool

TaskA

pget_mpl 200 bytes

The validity of the address of the memory block to which MR100 is passed as an argument and to release is not judged. Therefore, operation at the time of releasing the memory block which is already released or releasing the memory block which has not been gained is not guaranteed.

- 52 -

TaskA

Memorypool

rel_mpl

top of

address

Figure 4.19 rel_mpl processing

• Reference Acquire Variable-size Memory Pool Status (ref_mpl, iref_mpl)

Checks the total free area of the memory pool, and the size of the maximum free area that can immediately be acquired.

Memorypool

- 53 -

4.1.11 Time Management Function

The time management function provides system time management, time reading26, time setup27, and the functions of the alarm handler, which actuates at preselected times, and the cyclic handler, which actuates at preselected time intervals.

The MR100 kernel requires one timer for use as the system clock. There are following time management service calls that are provided by the MR100 kernel. Note, however, that the system clock is not an essential function of MR100. Therefore, if the service calls described below and the time management function of the MR100 are unused, a timer do es not need to be occupied for use by MR100.

• Place a task in a finite time wait state by specifying a timeout value

A timeout can be specified in a service call that places the issuing task into WAITING state.

This service call includes tslp_tsk, twai_flg, twai_sem, tsnd_dtq, trcv_dtq, trcv_mbx, tget_mpf, vtsnd_dtq, and vtrcv_dtq. If the wait cancel condition is not met before the specified timeout time elapses, the error code E_TMOUT is returned, and the task is freed from the waiting state. If the wait cancel condition is met, the error code E_OK is returned. The timeout time should be specified in ms units.

READY state

WAITING state

RUNNING state

WAITING state

tslp_tsk(50)

Timeou t value

tslp_tsk(50)

E_OK

E_TMOUT

iwup_tsk

Figure 4.20 Timeout Processing

MR100 guarantees that as stipulated in µITRON specification, timeout processing is not p erformed until a time equal to or greater than the specified timeout value elapses. More specifically, timeout processing is performed with the following timing.

1. If the timeout value is 0 (for only dly_tsk) The task times out at the first time tick after the service call is issued.

2. If the timeout value is a multiple of time tick interval The timer times out at the (timeout value / time tick interval) + first time tick. For example, if the time tick interval is 10 ms and the specified timeout value is 40 ms, then the timer times out at the fifth occurrence of the time tick. Similarly, if the time tick interval is 5 ms and the specified timeout value is 15 ms, then the timer times out at the fourth occurrence of the time tick.

get_tim service call

set_tim service call

SUSPENDED state is not included.

Strictly, in a dly_tsk service call, the "timeout value" is not correct. "delay time" is correct.

Strictly, in a dly_tsk service call, a timeout is not carried out, but the waiting for delay is canceled and the service call carries out the nor-

mal end.

- 54 -

3. If the timeout value is not a multiple of time tick interval

The timer times out at the (timeout value / time tick interval) + second time tick. For example, if the time tick interval is 10 ms and the specified timeout value is 35 ms, then the timer times out at the fifth occurrence of the time tick.

• Set System Time (set_tim)

• Reference System Time (get_tim)

The system time indicates an elapsed time from when the system was reset by using 48-bit data. The time is expressed in ms units.

- 55 -

4.1.12 Cyclic Handler Function

The cyclic handler is a time event handler that is started every startup cycle after a specified startup phase has elapsed. The cyclic handler may be started with or without saving the startup phase. In the former case, the cyclic handler is started

relative to the point in time at which it was generated. In the latter case, the cyclic handler is started relative to the point in time at which it started operating. Figure 4.21 and Figure 4.22 show typical operations of the cyclic handler.

he startup cycle is shorter than the time tick interval, the cyclic handler is started only once every time tick supplied

If t (processing equivalent to isig_tim). For example, if the time tick interval is 10 ms and the startup cycle is 3 ms and the cyclic handler has started operating when a time tick is supplied, then the cyclic handler is started every time tick.

Cyclic handler

created

Activation

phase

Activation

cycle

Handler does

not start

Start operating Stop operating

Activation

Handler does

not start

cycle

Handler starts Handler starts

Activation

cycle

Activation

cycle

Handler does

not start

Figure 4.21 Cyclic handler operation in cases where the activation phase is saved

Cyclic handler

created

Activation

phase

Activation

cycle

Handler does

not start

Start operating Stop operating

Handler does

not start

Activation

cycle

Handler starts Handler starts

Activation

cycle

Activation

cycle

Handler does

not start

Figure 4.22 Cyclic handler operation in cases where the activation phase is not saved

• Start Cyclic Handler Operation (sta_cyc, ista_cyc)

Causes the cyclic handler with the specified ID to operational state.

• Stop Cyclic Handler Operation (stp_cyc, istp_cyc)

Causes the cyclic handler with the specified ID to non-operational state.

• Reference Cyclic Handler Status (ref_cyc, iref_cyc)

Refers to the status of the cyclic handler. The operating status of the target cyclic handler and the remaining time before it starts next time are inspected.

- 56 -

4.1.13 Alarm Handler Function

The alarm handler is a time event handler that is started only once at a specified time. Use of the alarm handler makes it possible to perform time-dependent processing. The time of day is specified by a relative

time. Figure 4.23 shows a typical operation of the alarm handler.

Alarm handler

created

Start

operating

Activation

time

Figure 4.23 Typical operation of the alarm handler

• Start Alarm Handler Operation (sta_alm, ista_alm)

Causes the alarm handler with the specified ID to operational state.

• Stop alarm Handler Operation (stp_alm, istp_alm)

Causes the alarm handler with the specified ID to non-operational state.

• Reference Alarm Handler Status (ref_alm, iref_alm)

Refers to the status of the alarm handler. The operating status of the target alarm handler and the remaining time before it starts are inspected.

operating

Handler starts

Start

Stop

operating

Activation

time

Handler does

not start

- 57 -

4.1.14 System Status Management Function

• Rotate Task Precedence (rot_rdq, irot_rdq)

This service call establishes the TSS (time-sharing system). That is, if the ready queue is rotated at regular intervals, round robin scheduling required for the TSS is accomplished (See Figure 4.24)

Priority

１

２

３

ｎ

Figure 4.24 Ready Queue Management by rot_rdq Service Call

taskA

taskB taskC

taskD taskE taskF

Move the end of the queue

• Reference task ID in the RUNNING state(get_tid, iget_tid)

References the ID number of the task in the RUNNING state. If issued from the handler, TSK_NONE(=0) is obtained instead of the ID number.

• Lock the CPU (loc_cpu, iloc_cpu)

Places the system into a CPU locked state.

• Unlock the CPU (unl_cpu, iunl_cpu)

Frees the system from a CPU locked state.

• Disable dispatching (dis_dsp)

Places the system into a dispatching disabled state.

• Enable dispatching (ena_dsp)

Frees the system from a dispatching disabled state.

• Reference context (sns_ctx)

Gets the context status of the system.

• Reference CPU state (sns_loc)

Gets the CPU lock status of the system.

• Reference dispatching state (sns_dsp)

Gets the dispatching disable status of the system.

• Reference dispatching pending state (sns_dpn)

Gets the dispatching pending status of the system.

- 58 -

4.1.15 Interrupt Management Function

The interrupt management function provides a function to process requested external interrupts in real time. The interrupt management service calls provided by the MR100 kernel include the following:

• Returns from interrupt handler (ret_int)

The ret_int service call activates the scheduler to switch over tasks as necessary when returning from the interrupt handler. When using the C language, case, therefore, there is no need to invoke this service call.

, this function is automatically called at completion of the hand ler function. In this

Figure 4.25 shows an interrupt processing flow. Processing a seri is called a "scheduler.".

TaskA

Interrupt

Save Registers

Handler Processing

iwup_tsk

ret_int

es of operations from task selection to register restoration

pragma INTHANDLER Declare

(C language)

Task Selection

Restore Registers

Figure 4.25 Interrupt process flow

In the case that the interruput handler is specified by "#pragma INTHANDLER".

- 59 -

TaskB

4.1.16 System Configuration Management Function

This function inspects the version information of MR100.

• References Version Information(ref_ver, iref_ver)

The ref_ver service call permits the user to get the version information of MR100. This version information can be obtained in the standardized format of µITRON specification.

4.1.17 Extended Function (Short Data Queue)

The short data queue is a function outside the scope of µITRON 4.0 Specification. The data queue function handles data as consisting of 32 bits, whereas the short data queue handles data as consisting of 16 bits. Both behave the same way except only that the data sizes they handle are different.

• Send to Short Data Queue (vsnd_dtq, vtsnd_dtq)

The data is transmitted to the short data queue. If the short data qu eue is full of data, the task goes to a data transmission wait state.

• Send to Short Data Queue (vpsnd_dtq, vipsnd_dtq)

The data is transmitted to the short data queue. If the shor t data queue is full of data, the task returns erro r code without going to a data transmission wait state.

• Forced Send to Short Data Queue (vfsnd_dtq, vifsnd_dtq)

The data is transmitted to the short data queue. If the short data queue is full of data, the data at th e top of the short data queue or the oldest data is removed, and the transmitted data is stored at the tail of the short data queue.

• Receive from Short Data Queue(vrcv_dtq, vtrcv_dtq)

The data is retrieved from the short data queue. If the short data queue has no data in it, the task is kept waiting until data is transmitted to the short data queue.

• Receive from Short Data Queue (vprcv_dtq, viprcv_dtq)

The data is received from the short data queue. If the short data queue has no data in it, the task returns error code without going to a data reception wait state.

• Reference Short Data Queue Status (vref_dtq, viref_dtq)

Checks to see if there are any tasks waiting for data to be entered in the target short data queue and refers to the number of the data in the short data queue.

- 60 -

4.1.18 Extended Function (Reset Function)

The reset function is a function outside the scope of µITRON 4.0 Specification. It initializes the mailbox, data queue, and memory pool, etc.

• Clear Data Queue Area (vrst_dtq)

Initializes the data queue. If there are any tasks waiting for transmission, they are freed from WAITING state and the error code EV_RST is returned.

• Clear Mailbox Area (vrst_mbx)

Initializes the mailbox.

• Clear Fixed-size Memory Pool Area (vrst_mpf)

Initializes the fixed-size memory pool. If there are any tasks in WAITING state, they are freed from the WAITING state and the error code EV_RST is returned.

• Clear Variable-size Memory Pool Area (vrst_mpl)

Initializes the variable length memory pool.

• Clear Short Data Queue Area (vrst_vdtq)

Initializes the short data queue. If there are any tasks waiting for transmission, they are freed fro m WAITING state and the error code EV_RST is returned.

- 61 -

5. Service call reffernce

5.1 Task Management Function

Specifications of the task management function of MR100 are listed in Table 5.1 below. The task description languages in item No. 4 are those specified in the GUI configurator. They are not output to a configuration file, nor are the MR100 kernel concerned with them.

The task stack permits a section name to be specified for each task individually.

Table 5.1 Specifications of the Task Management Function

No. Item Content

1 Task ID 1-255 2 Task priority 1-255 3 Maximum number of activation request count 255

TA_HLNG : Tasks written in high-level language

4 Task attribute

5 Task stack Section specifiable

TA_ASM : Tasks written in assem-bly language TA_ACT：

Startup attribute

Table 5.2 List of Task Management Function Service Call

No. Service Call Function

T N E D U L

1 act_tsk 2 iact_tsk 3 can_act 4 ican_act 5 sta_tsk 6 ista_tsk 7 ext_tsk 8 ter_tsk 9 chg_pri

10 ichg_pri

11 get_pri

12 iget_pri 13 ref_tsk O O O O 14 iref_tsk 15 ref_tst O O O O 16 iref_tst

[S] [S] [S]

[B]

[S][B] [S][B] [S][B]

[S]

Activates task O O O O O O O O Cancels task activation request

Starts task and specifies start code

Exits current task O O O O O Forcibly terminates a task O O O O Changes task priority

Refers to task priority

Refers to task state

Refers to task state (simple ver-

sion)

O O O O

System State

- 63 -

Notes:

• [S]: Standard profile service calls

[B]: Basic profile service calls

• Each sign within " System State " is a following meaning.

♦ T: Can be called from task context ♦ N: Can be called from non-task context ♦ E: Can be called from dispatch-enabled state ♦ D: Can be called from dispatch-disabled state ♦ U: Can be called from CPU-unlocked state ♦ L: Can be called from CPU-locked state

- 64 -

act_tsk Activate task iact_tsk Activate task (handler only)

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER ercd = act_tsk( ID tskid ); ER ercd = iact_tsk( ID tskid );

zz PPaarraammeetteerrss

zz RReettuurrnn ppaarraammeetteerrss

ER ercd Terminated normally (E_OK) or error code

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc act_tsk TSKID iact_tsk TSKID

zz PPaarraammeetteerrss

TSKID ID number of the task to be started

ｔskid

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

[[[[ EErrrroorr CCooddee ]]]]

E_QOVR Queuing overflow

ID number of the task to be started

- 65 -

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

This service call starts the task indicated by tskid. The started task goes from DORMANT state to READY state or RUNNING state.

The following lists the processing performed on startup.

1. Initializes the current priority of the task.

2. Clears the number of queued wakeup requests.

3. Clears the number of suspension requests. Specifying tskid=TSK_SELF(0) specifies the issuing task itself. The task has passed to it as parameter the extended infor-

mation of it that was specified when the task was created. If TSK_SELF is specified for tskid in non-task context, operation of this service call cannot be guaranteed.

If the target task is not in DORMANT state, a task activation request by this service call is enqueued. In other words, the activation request count is incremented by 1. The maximum value of the task activation request is 255. If this limit is exceeded, the error code E_QOVR is returned.

If TSK_SELF is specified for tskid, the issuing task itself is made the target task. If this service call is to be issued from task context, use act_tsk; if issued from non-task context, use iact_tsk.

[[[[ EExxaammppllee pprrooggrraamm ssttaatteemmeenntt ]]]]

<<Example statement in C language>>

#include <itron.h> #include <kernel.h> #include “kernel_id.h” void task1( VP_INT stacd ) { ER ercd; : ercd = act_tsk( ID_task2 ); : } void task2( VP_INT stacd ) { : ext_tsk(); }

<<Example statement in assembly language>>

.INCLUDE mr100.inc .GLB task task: : PUSH.W R2 act_tsk #ID_TASK3 :

- 66 -

can_act Cancel task activation request ican_act Cancel task activation request (handler only)

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER_UINT actcnt = can_act( ID tskid ); ER_UINT actcnt = ican_act( ID tskid );

zz PPaarraammeetteerrss

ID tskid

zz RReettuurrnn PPaarraammeetteerrss

ER_UINT actcnt > 0 Canceled activation request count

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc can_act TSKID ican_act TSKID

zz PPaarraammeetteerrss

TSKID ID number of the task to cancel

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

[[[[ EErrrroorr ccooddee ]]]]

None

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

This service call finds the number of task activation requests enqueued for the task indicated by tskid, returns the result as a return parameter, and at the same time invalidates all of the task’s activation requests.

ID number of the task to cancel

actcnt < 0 Error code

Content after service call is issued

Specifying tskid=TSK_SELF(0) specifies the issuing task itself. If TSK_SELF is specified for tskid in non-task con text, operation of this service call cannot be guaranteed.

This service call can be invoked for a task in DORMANT state as the target task. In that case, the return parameter is 0. If this service call is to be issued from task context, use can_act; if issued from non-task context, use ican_act.

- 67 -

[[[[ EExxaammppllee pprrooggrraamm ssttaatteemmeenntt ]]]]

<<Example statement in C language>>

#include <itron.h> #include <kernel.h> #include “kernel_id.h” void task1() { ER_UINT actcnt; : actcnt = can_act( ID_task2 ); : } void task2() { : ext_tsk(); }

<<Example statement in assembly language>>

.INCLUDE mr100.inc .GLB task task: : can_act #ID_TASK2 :

- 68 -

sta_tsk Activate task with a start code ista_tsk Activate task with a start code (handler only)

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER ercd = sta_tsk( ID tskid,VP_INT stacd ); ER ercd = ista_tsk ( ID tskid,VP_INT stacd );

zz PPaarraammeetteerrss

ID tskid ID number of the target task VP_INT stacd Task start code

zz RReettuurrnn PPaarraammeetteerrss

ER ercd Terminated normally (E_OK) or error code

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc sta_tsk TSKID,STACD ista_tsk TSKID,STACD

zz PPaarraammeetteerrss

TSKID ID number of the target task STATCD Task start code

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

[[[[ EErrrroorr ccooddee ]]]]

E_OBJ Object status invalid (task indicated by tskid is not DOMANT state)

- 69 -

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

This service call starts the task indicated by tskid. In other words, it places the specified task from DORMANT state into READY state or RUNNING state. This service call does not enqueue task activation requests. Therefore, if a task activation request is issued while the target task is not DORMANT state, the error code E_OBJ is returned to the service call issuing task. This service call is effective only when the specified task is in DORMANT state. The task start code stacd is 32 bits long. This task start code is passed as parameter to the activated task.

If a task is restarted that was once terminated by ter_tsk or ext_tsk, the task performs the following as it starts up.

1. Initializes the current priority of the task.

2. Clears the number of queued wakeup requests.

3. Clears the number of nested forcible wait requests. If this service call is to be issued from task context, use sta_tsk; if issued from non-task context, use ista_tsk.

[[[[ EExxaammppllee pprrooggrraamm ssttaatteemmeenntt ]]]]

<<Example statement in C language>>

#include <itron.h> #include <kernel.h> #include “kernel_id.h” void task() { ER ercd; VP_INT stacd = 0; ercd = sta_tsk( ID_task2, stacd ); : } void task2(VP_INT msg) { if(msg == 0) : }

<<Example statement in assembly language>>

.INCLUDE mr100.inc .GLB task task: : PUSHM R3R1 PUSH.W R2 sta_tsk #ID_TASK4,#100 :

- 70 -

ext_tsk Terminate invoking task

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER ercd = ext_tsk();

zz PPaarraammeetteerrss

None

zz RReettuurrnn PPaarraammeetteerrss

Not return from this service call

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc ext_tsk

zz PPaarraammeetteerrss

None

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

Not return from this service call

[[[[ EErrrroorr ccooddee ]]]]

Not return from this service call

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

This service call terminates the invoking task. In other words, it places the issuing task from RUNNING state into DORMANT state. However, if the activation request count for the issuing task is 1 or more, the activ ation request count is decremented by 1, and processing similar to that of act_tsk or iact_tsk is performed. In that case, the task is placed from DORMANT state into READY state. The task has its extended information passed to it as parameter when the task starts up.

This service call is designed to be issued automatically at return from a task. In the invocation of this service call, the resources the issuing task had acquired previously (e.g., semaphore) are not re-

leased. This service call can only be used in task context. This service call can be used even in a CPU locked state, but cannot be

used in non-task context.

- 71 -

[[[[ EExxaammppllee pprrooggrraamm ssttaatteemmeenntt ]]]]

<<Example statement in C language>>

#include <itron.h> #include <kernel.h> #include “kernel_id.h” void task(void) { : ext_tsk(); }

<<Example statement in assembly language>>

.INCLUDE mr100.inc .GLB task task: : ext_tsk

- 72 -

ter_tsk Terminate task

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER ercd = ter_tsk( ID tskid );

zz PPaarraammeetteerrss

ID tskid ID number of the forcibly terminated task

zz RReettuurrnn PPaarraammeetteerrss

ER ercd Terminated normally (E_OK) or error code

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc ter_tsk TSKID

zz PPaarraammeetteerrss

TSKID ID number of the forcibly terminated task

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

[[[[ EErrrroorr ccooddee ]]]]

E_OBJ Object status invalid(task indicated by tskid is an inactive state) E_ILUSE Service call improperly used task indicated by tskid is the issuing task itself)

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

This service call terminates the task indicated by tskid. If the activation request count of the target task is equal to or greater than 1, the activation request count is decremented by 1, and processing similar to that of act_tsk or iact_tsk is performed. In that case, the task is placed from DORMANT state into READY state. The task has its extended information passed to it as parameter when the task starts up.

If a task specifies its own task ID or TSK_SELF, an E_ILUSE error is returned. If the specified task was placed into WAITING state and has been enqueued in some waiting queue, the task is dequeued

from it by execution of this service call. However, the semaphore and other resources the specified task had acquired previously are not released.

If the task indicated by tskid is in DORMANT state, it returns the error code E_OBJ as a return value for the service call. This service call can only be used in task context, and cannot be used in non-task context.

- 73 -

[[[[ EExxaammppllee pprrooggrraamm ssttaatteemmeenntt ]]]]

<<Example statement in C language>>

#include <itron.h> #include <kernel.h> #include “kernel_id.h” void task() {

: ter_tsk( ID_main ); :

}

<<Example statement in assembly language>>

.INCLUDE mr100.inc .GLB task task: : PUSH.W R2 ter_tsk #ID_TASK3 :

- 74 -

chg_pri Change task priority ichg_pri Change task priority(handler only)

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER ercd = chg_pri( ID tskid, PRI tskpri ); ER ercd = ichg_pri( ID tskid, PRI tskpri );

zz PPaarraammeetteerrss

ID tskid ID number of the target task PRI tskpri Priority of the target task

zz RReettuurrnn PPaarraammeetteerrss

ER ercd Terminated normally (E_OK) or error code

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc chg_pri TSKID,TSKPRI ichg_pri TSKID,TSKPRI

zz PPaarraammeetteerrss

TSKID ID number of the target task TSKPRI Priority of the target task

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

Register name Content after serv ice call is issued R0 Error code R3 Priority of the target task R2 ID number of the target task

[[[[ EErrrroorr ccooddee ]]]]

E_OBJ Object status invalid(task indicated by tskid is an inactive state)

- 75 -

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

The priority (base priority) of the task specified by tskid is changed to the value indicated by tskpri, and tasks are rescheduled based on the result of change.

If this service call is executed on a task queued in a ready queue (including a task under execution) or a task in a wait queue in which tasks are queued in order of priority, the object task is moved to the tail end of the tasks of relevant priority in the queue. When the same priority as before is specified, the object task is moved to the tail end of that queue also.

The smaller the number, the higher the task priority, with numeral 1 assigned the highest priority. The minimum numeric value specifiable as priority is 1. Furthermore, the maximum value of priority is the one specified in a configuration file, and the specifiable range of priority is 1 to 255. For example, if the following statement is written in a configuration file,

system{

stack_size = 0x100; priority = 13; };

then the specifiable range of priority is 1 to 13. If TSK_SELF is specified, the priority (base priority) of the issuing task is changed. If TSK_SELF is specified for tskid in a non-task context, the program operation cannot be guaranteed. If TPRI_INI is specified, the priority of a task is changed to its startup priority specified when it is generated. The changed task priority (base priority) remains effective until the task terminates or this service call is reexecuted. If the task indicated by tskid is in an inactive (DORMANT) state, error code E_OBJ is returned as the service call's return value. To use these service calls from task contexts, be sure to use chg_pri; to use them from non-task contexts, be sure to use ichg_pri.

[[[[ EExxaammppllee pprrooggrraamm ssttaatteemmeenntt ]]]]

<<Example statement in C language>>

#include <itron.h> #include <kernel.h> #include “kernel_id.h” void task() {

: chg_pri( ID_task2, 2 ); :

}

<<Example statement in assembly language>>

.INCLUDE mr100.inc .GLB task task: : PUSH.W R2 PUSH.W R3 chg_pri #ID_TASK3,#1 :

- 76 -

get_pri Reference task priority iget_pri Reference task priority(handler only)

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER ercd = get_pri( ID tskid, PRI *p_tskpri ); ER ercd = iget_pri( ID tskid, PRI *p_tskpri );

zz PPaarraammeetteerrss

ID tskid ID number of the target task PRI *p_tskpri Pointer to the area to which task priority is returned

zz RReettuurrnn PPaarraammeetteerrss

ER ercd Terminated normally (E_OK) or error code

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc get_pri TSKID iget_pri TSKID

zz PPaarraammeetteerrss

TSKID ID number of the target task

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

[[[[ EErrrroorr ccooddee ]]]]

E_OBJ Object status invalid(task indicated by tskid is an inactive state)

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

This service call returns the priority of the task indicated by tskid to the area indicated by p_tskpri. If TSK_SELF is specified, the priority of the issuing task itself is acquired. If TSK_SELF is specified for tskid in non-task context, operation of the service call cannot be guaranteed.

If the task indicated by tskid is in DORMANT state, it returns the error code E_OBJ as a return value for the service call. If this service call is to be issued from task context, use get_pri; if issued from non-task context, use iget_pri.

- 77 -

[[[[ EExxaammppllee pprrooggrraamm ssttaatteemmeenntt ]]]]

<<Example statement in C language>>

#include <itron.h> #include <kernel.h> #include “kernel_id.h” void task() { PRI p_tskpri; ER ercd;

ercd = get_pri( ID_task2, &p_tskpri );

}

<<Example statement in assembly language>>

.INCLUDE mr100.inc .GLB task task: : get_pri #ID_TASK2 :

- 78 -

ref_tsk Reference task status iref_tsk Reference task status (handler only)

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER ercd = ref_tsk( ID tskid, T_RTSK *pk_rtsk ); ER ercd = iref_tsk( ID tskid, T_RTSK *pk_rtsk );

zz PPaarraammeetteerrss

ID tskid ID number of the target task T_RTSK *pk_rtsk Pointer to the packet to which task status is returned

zz RReettuurrnn PPaarraammeetteerrss

ER ercd Terminated normally (E_OK)

Contents of pk_rtsk typedef struct t_rtsk{

STAT tskstat +0 2 Task status PRI tskpri +2 2 Current priority of task PRI tskbpri +4 2 Base priority of task STAT tskwait +6 2 Cause of wait ID wobjid +8 2 Waiting object ID TMO lefttmo +10 4 Left time before timeout UINT actcnt +14 4 Number of queued activation request counts UINT wupcnt +18 4 Number of queued wakeup request counts UINT suscnt +22 4 Number of nested suspension request counts

} T_RTSK;

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc ref_tsk TSKID, PK_RTSK iref_tsk TSKID, PK_RTSK

zz PPaarraammeetteerrss

TSKID ID number of the target task PK_RTSK Pointer to the packet to which task status is returned

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

Register name Content after service call is issued R0 Error code R2 ID number of the target task A1 Pointer to the packet to which task status is returned

[[[[ EErrrroorr ccooddee ]]]]

None

- 79 -

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

This service call inspects the status of the task indicated by tskid and returns the curren t information on that task to the area pointed to by pk_rtsk as a return parameter. If TSK_SELF is specified, the status of the issuing task itself is inspected. If TSK_SELF is specified for tskid in non-task context, operati on of the service call cannot be guaranteed.

 tskstat (task status)

tskstat has one of the following values returned to it depending on the status of the specified task.

• TTS_RUN(0x0001) RUNNING state

• TTS_RDY(0x0002) READY state

• TTS_WAI(0x0004) WAITING state

• TTS_SUS(0x0008) SUSPENDED state

• TTS_WAS(0x000C) WAITING-SUSPENDED state

• TTS_DMT(0x0010) DORMANT state

 tskpri (current priority of task)

tskpri has the current priority of the specified task returned to it. If the task is in DOMANT state, tskpri is indeterminate.

 tskbpri (base priority of task)

tskbpri has the base priority of the specified task returned to it. If the task is in DOMANT state, tskbpri is indeterminate.

 tskwait (cause of wait)

If the target task is in a wait state, one of the following causes of wait is returned. The values of the respective causes of wait are listed below. If the task status is other than a wait state (TTS_WAI or TTS_WAS), tskwait is indeterminate.

• TTW_SLP (0x0001) Kept waiting by slp_tsk or tslp_tsk

• TTW_DLY (0x0002) Kept waiting by dly_tsk

• TTW_SEM (0x0004) Kept waiting by wai_sem or twai_sem

• TTW_FLG (0x0008) Kept waiting by wai_flg or twai_flg

• TTW_SDTQ(0x0010) Kept waiting by snd_dtq or tsnd_dtq

• TTW_RDTQ(0x0020) Kept waiting by rcv_dtq or trcv_dtq

• TTW_MBX (0x0040) Kept waiting by rcv_mbx or trcv_mbx

• TTW_MPF (0x2000) Kept waiting by g e t_mpf or tget_mpf

• TTW_VSDTQ (0x4000) Kept waiting by vsnd_dtq or vtsnd_dtq

• TTW_VRDTQ(0x8000) Kept waiting by vrcv_dtq or vtrcv_dtq

 wobjid (waiting object ID)

If the target task is in a wait state (TTS_WAI or TTS_WAS), the ID of the waiting target object is returned. Otherwise, wobjid is indeterminate.

 lefttmo(left time before timeout)

If the target task has been placed in WAITING state (TTS_WAI or TTS_WAS) by other than dly_tsk, the left time before it times out is returned. If the task is kept waiting perpetually, TMO_FEVR is returned. Otherwise, lefttmo is indeterminate.

 actcnt(task activation request)

The number of currently queued task activation request is returned.

 wupcnt (wakeup request count)

The number of currently queued wakeup requests is returned. If the task is in DORMANT state, wupcnt is indeterminate.

 suscnt (suspension request count)

The number of currently nested suspension requests is returned. If the task is in DORMANT state, suscnt is indeterminate.

If this service call is to be issued from task context, use ref_tsk; if issued from non-task context, use iref_tsk.

TTW_VSDTQ and TTW_VRDTQ are the causes of wait outside the scope of µITRON 4.0 Specification.

- 80 -

[[[[ EExxaammppllee pprrooggrraamm ssttaatteemmeenntt ]]]]

<<Example statement in C language>> #include <itron.h>

#include <kernel.h> #include “kernel_id.h” void task() {

T_RTSK rtsk; ER ercd; : ercd = ref_tsk( ID_main, &rtsk ); :

}

<<Example statement in assembly language>>

_refdata: .blkb 26 .include mr100.inc .GLB task task:

: PUSH.W R2 PUSH.L A1 ref_tsk #TSK_SELF,#_refdata

- 81 -

ref_tst Reference task status (simplified version) iref_tst Reference task status (simplified version, handler

only)

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER ercd = ref_tst( ID tskid, T_RTST *pk_rtst ); ER ercd = iref_tst( ID tskid, T_RTST *pk_rtst );

zz PPaarraammeetteerrss

ID tskid ID number of the target task T_RTST *pk_rtst Pointer to the packet to which task status is returned

zz RReettuurrnn PPaarraammeetteerrss

ER ercd Terminated normally (E_OK)

Contents of pk_rtsk typedef struct t_rtst{

STAT tskstat +0 2 Task status STAT tskwait +2 2 Cause of wait

} T_RTST;

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc ref_tst TSKID, PK_RTST iref_tst TSKID, PK_RTST

zz PPaarraammeetteerrss

TSKID ID number of the target task PK_RTST Pointer to the packet to which task status is returned

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

Register name Content after service call is issued R0 Error code A0 ID number of the target task A1 Pointer to the packet to which task status is returned

[[[[ EErrrroorr ccooddee ]]]]

None

- 82 -

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

This service call inspects the status of the task indicated by tskid and returns the curren t information on that task to the area pointed to by pk_rtst as a return value. If TSK_SELF is specified, the status of the issuing task itself is inspected. If TSK_SELF is specified for tskid in non-task context, operati on of the service call cannot be guaranteed.

 tskstat (task status)

tskstat has one of the following values returned to it depending on the status of the specified task.

• TTS_RUN(0x0001) RUNNING state

• TTS_RDY(0x0002) READY state

• TTS_WAI(0x0004) WAITING state

• TTS_SUS(0x0008) SUSPENDED state

• TTS_WAS(0x000C) WAITING-SUSPENDED state

• TTS_DMT(0x0010) DORMANT state

 tskwait (cause of wait)

If the target task is in a wait state, one of the following causes of wait is returned. The values of th e respective causes of wait are listed below. If the task status is other than a wait state (TTS_WAI or TTS_WAS), tskwait is indeterminate.

• TTW_SLP (0x0001) Kept waiting by slp_tsk or tslp_tsk

• TTW_DLY (0x0002) Kept waiting by dly_tsk

• TTW_SEM (0x0004) Kept waiting by wai_sem or twai_sem

• TTW_FLG (0x0008) Kept waiting by wai_flg or twai_flg

• TTW_SDTQ(0x0010) Kept waiting by snd_dtq or tsnd_dtq

• TTW_RDTQ(0x0020) Kept waiting by rcv_dtq or trcv_dtq

• TTW_MBX (0x0040) Kept waiting by rcv_mbx or trcv_mbx

• TTW_MPF (0x2000) Kept waiting by g e t_mpf or tget_mpf

• TTW_VSDTQ (0x4000) Kept waiting by vsnd_dtq or vtsnd_dtq

• TTW_VRDTQ(0x8000) Kept waiting by vrcv_dtq or vtrcv_dtq

If this service call is to be issued from task context, use ref_tst; if issued from non-task context, use iref_tst.

[[[[ EExxaammppllee pprrooggrraamm ssttaatteemmeenntt ]]]]

<<Example statement in C language>>

#include <itron.h> #include <kernel.h> #include “kernel_id.h” void task() {

T_RTST rtst; ER ercd; : ercd = ref_tst( ID_main, &rtst ); :

}

<<Example statement in assembly language>>

_refdata: .blkb 4 .include mr100.inc .GLB task task:

: PUSH.W R2 PUSH.L A1 ref_tst #ID_TASK2,#_refdata

TTW_VSDTQ and TTW_VRDTQ are the causes of wait outside the scope of µITRON 4.0 Specification.

- 83 -

5.2 Task Dependent Synchronization Function

Specifications of the task-dependent synchronization function are listed in below.

Table 5.3 Specifications of the Task Dependent Synchronization Function

No. Item Content 1 Maximum value of task wakeup request count 255

2 Maximum number of nested forcible task wait requests count 1

Table 5.4 List of Task Dependent Synchronization Service Call

No. Service Call Function

1 slp_tsk 2 tslp_tsk 3 wup_tsk 4 iwup_tsk 5 can_wup 6 ican_wup 7 rel_wai 8 irel_wai

9 sus_tsk 10 isus_tsk 11 rsm_tsk 12 irsm_tsk 13 frsm_tsk 14 ifrsm_tsk 15 dly_tsk

Notes:

[S][B] [S] [S][B] [S][B] [B]

[S][B] [S][B] [S][B]

[S][B]

[S]

[S][B]

Puts task to sleep O O O Puts task to sleep (with timeout) O O O

Releases task from waiting

Suspends task

Wakes up task

Cancels wakeup request

Delays task O O O

• [S]: Standard profile service calls

[B]: Basic profile service calls

• Each sign within " System State " is a following meaning.

System State

T N E D U L

O O O O

- 84 -

slp_tsk Put task to sleep tslp_tsk Put task to sleep (with timeout)

[[[[ CC LLaanngguuaaggee AAPPII ]]]]

ER ercd = slp_tsk(); ER ercd = tslp_tsk( TMO tmout );

zz PPaarraammeetteerrss

z slp_tsk

None

z tslp_tsk

TMO tmout Timeout value

zz RReettuurrnn PPaarraammeetteerrss

ER ercd Terminated normally (E_OK) or error code

[[[[ AAsssseemmbbllyy llaanngguuaaggee AAPPII ]]]]

.include mr100.inc slp_tsk tslp_tsk TMO

zz PPaarraammeetteerrss

TMO Timeout value

zz RReeggiisstteerr ccoonntteennttss aafftteerr sseerrvviiccee ccaallll iiss iissssuueedd

tslp_tsk

slp_tsk

[[[[ EErrrroorr ccooddee ]]]]

E_TMOUT Timeout E_RLWAI Forced release from waiting

- 85 -

[[[[ FFuunnccttiioonnaall ddeessccrriippttiioonn ]]]]

This service call places the issuing task itself from RUNNING state into sleeping wait state. The task placed into WAITING state by execution of this service call is released from the wait state in the following cases:

 When a task wakeup service call is issued from another task or an interrupt

The error code returned in this case is E_OK.

 When a forcible awaking service call is issued from another task or an interrupt

The error code returned in this case is E_RLWAI.

 When the first time tick occurred after tmout elapsed (for tslp_tsk)

The error code returned in this case is E_TMOUT.

If the task receives sus_tsk issued from another task while it has been placed into WAITING state by this service call, it goes to WAITING-SUSPENDED state. In this case, even when the task is released from WAITING state by a task wakeup service call, it still remains in SUSPENDED state, and its execution cannot be resumed until rsm_tsk is issued.

The service call tslp_tsk may be used to place the issuing task into sleeping state for a given length of time by specifying tmout in a parameter to it. The parameter tmout is expressed in ms units. For example, if this service call is written as tslp_tsk(10);, then the issuing task is placed from RUNNING state into WAITING state for a period of 10 ms. If specified as tmout =TMO_FEVR(–1), the task will be kept waiting perpetually, with the service call operating the same way as slp_tsk.

The values specified for tmout must be within (0x7FFFFFFF-time tick value). If any value exceeding this limit is specified, operation of the service call cannot be guaranteed.

This service call can only be issued from task context, and cannot be issued from non-task context.

- 86 -

Renesas M3T-MR100 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Requirements for MR100 Use

Document List

Right of Software Use

1. User’s Manual Organization

2. General Information

2.1 Objective of MR100 Development

2.2 Relationship between TRON Specification and MR100

2.3 MR100 Features

3. Introduction to Kernel

3.1 Concept of Real-time OS

3.1.1 Why Real-time OS is Necessary

3.1.2 Operating Principles of Kernel

3.2 Service Call

3.2.1 Service Call Processing

3.2.2 Processing Procedures for Service Calls from Handlers

Service Calls from a Handler That Caused an Interrupt during Task Execution

Service Calls from a Handler That Caused an Interrupt during Handler Execution

3.3 Object

3.3.1 The specification method of the object in a service call

3.4 Task

3.4.1 Task Status

3.4.2 Task Priority and Ready Queue

3.4.3 Task Priority and Waiting Queue

3.4.4 Task Control Block(TCB)

3.5 System States

3.5.1 Task Context and Non-task Context

3.5.2 Dispatch Enabled/Disabled States

3.5.3 CPU Locked/Unlocked States

3.5.4 Dispatch Disabled and CPU Locked States

3.6 Regarding Interrupts

3.6.1 Types of Interrupt Handlers

3.6.2 The Use of Non-maskable Interrupt

3.6.3 Controlling Interrupts

3.7 Stacks

3.7.1 System Stack and User Stack

4. Kernel

4.1.1 Module Structure

4.1.2 Module Overview

4.1.3 Task Management Function

4.1.4 Synchronization functions attached to task

4.1.5 Synchronization and Communication Function (Semaphore)

4.1.6 Synchronization and Communication Function (Eventflag)

4.1.7 Synchronization and Communication Function (Data Queue)

4.1.8 Synchronization and Communication Function (Mailbox)

4.1.9 Memory pool Management Function(Fixed-size Memory pool)

4.1.10 Variable-size Memory Pool Management Function

4.1.11 Time Management Function

4.1.12 Cyclic Handler Function

4.1.13 Alarm Handler Function

4.1.14 System Status Management Function

4.1.15 Interrupt Management Function

4.1.16 System Configuration Management Function

4.1.17 Extended Function (Short Data Queue)

4.1.18 Extended Function (Reset Function)

5. Service call reffernce

5.1 Task Management Function

5.2 Task Dependent Synchronization Function