OSEKSAMPMANUAL - Motorola / Freescale Semiconductor

OSEK Operat ing System

Rev. 1.2

NON-DISCLOSURE AGREEMENT REQUIRED

HC12

OSEK

Operating System

User’s Manual

Rev. 1.2

May 19, 1999

NON-DISCLOSURE AGREEMENT REQUIRED

User’s Manual

User’s Manual MC68HC(7)05H12 — Rev. 1.2

2MOTOROLA

Motorola reserves the right to make changes without further notice to

any products herein to improve reliability, function or design. Motorola

does not assume any liability arising out of the application or use of any

product or circuit described herein; neither does it convey any license

under i ts patent rights nor the rights of othe rs. M otorola prod ucts a re not

designed, intended, or authorized for use as components in systems

intended for surgical implant into the body, or other applications intended

to support or sustain life, or for any other application in which the failure

of the Mot orola pro duct co uld cr eate a si tu ation where per sonal injury or

death may occur. Should Buyer purchase or use Motorola products for

any such unintended or unauthorized application, Buyer shall indemnify

and hold Motorola and its officers, employees, subsidiaries, affiliates,

and distributors harmless against all claims, costs, damages, and

expenses, and reasonable attorney fees arising out of, directly or

indirectly, any claim of personal injury or death associated with such

unintended or unauthorized use, even if such claim alleges that Motorola

was negligent re gard i ng the design or manu factur e of the part. Moto rol a

and are register ed tr adem arks of M otoro la, Inc. Mo toro la , Inc. is an

Equal Employment Opportunity/Affirmative Action Employer.

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Legal Notices 3

NON-DISCLOSURE AGREEMENT REQUIRED

Legal Notices

iii

The information in this document has been carefully checked and is

believed to be entirely reliable, however, no responsibility is assumed for

inaccuracies. Furthermore, Motorola reserves the right to make changes

to any products herein to improve reliability, function or design. Motorola

does not assume liability arising out of the application or use of any

product or circuit described herein; neither does it convey any license

under its patent rights or the rights of others.

The software described in this document is furnished under a license

agreement. The software may be used or copied only in accordance with

the terms of the agreement.

No part of th is publicat ion ma y be repr oduced or transmitted in an y form

or by any means - graphic, electronic, electrical, mechanical, chemical,

including photocopying, recording in any medium, taping, by any

computer or information storage retrieval systems, etc., without prior

permissions in writing from Motorola Inc.

Permission is granted to reproduce and transmit the Problem Report

Form, the Customer Satisfaction Survey, and the Registration Form to

Motorola.

IMPORTANT NOTICE TO USERS

While every effort has been made to ensure the accuracy of all

information in this document, Motorola assumes no liability to an y party

for any l oss o r damage cau s ed by error s or omi ssions or by statem ents

of any kind in this document, its updates, supplements, or special

editions, whether such errors are omissions or statements resulting from

negligence, accident, or any other cause. Motorola further assumes no

liability arising out of the application or use of any product or system

described herein; nor any liability for incidental or consequential

damages arising from the use of this document. Motorola discl aims all

warranties regarding the information contained herein, whether

expressed, implied or statutory, including implied warranties of

merchantability or fitness for a particular purpose.

NON-DISCLOSURE AGREEMENT REQUIRED

Legal Notices

User’s Manual OSEK Opera ting System — Rev 1.2

4 Legal Notices MO TORO LA

TRADEMARKS

Microsoft, MS-DOS and Windows are trademarks of Microsoft.

UNIX is a trademark of AT&T Bell Laboratories.

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Table of Contents 5
 NON-DISCLOSURE AGREEMENT REQUIRED
User’s Manual — OSEK Operating System
Table of Contents
Section 1. Overview
Section 2. Notation
2.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
2.2 Manual Structure  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
2.3 Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . .27
2.4 Definitions, Acronyms and Abbreviations. . . . . . . . . . . . . . . . .27
2.5 Installation Instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
2.5.1 Required Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
2.5.2 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
2.6 Technical Support Information . . . . . . . . . . . . . . . . . . . . . . . . .29
Section 3. Operating System Architecture
3.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
3.2 Processing Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
3.3 Conformance Classes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
3.4 OSEK OS Overall Architecture. . . . . . . . . . . . . . . . . . . . . . . . .35
3.5 Application Program Interface  . . . . . . . . . . . . . . . . . . . . . . . . .37
Sectio n 4. Task Management
4.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
4.2 Task Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
4.3 Task State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
4.3.1 Extended Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
4.3.2 Basic Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
4.4 Task Activation and Termination  . . . . . . . . . . . . . . . . . . . . . . .44
4.5 Task Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

 NON-DISCLOSURE AGREEMENT REQUIRED
Table of Contents
User’s Manual OSEK Opera ting  System — Rev 1.2
Table of Contents MOTOROLA
6 Task Priorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
7 Task Related Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
7.1 Task Configuration Table . . . . . . . . . . . . . . . . . . . . . . . . . .49
7.2 Task Control Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
7.2.1 Persistent Node Assignment . . . . . . . . . . . . . . . . . . . . . .52
7.3 Task Link Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
7.4 Task Stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
7.4.1 Stack Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
7.5 Allocation of Fixed Stack Linked with the Task Node . . . . .56
7.5.1 Dynamic Stack Allocation from the Stack Pool . . . . . . . .57
7.5.2 Persistent Stack Allocation from the Stack Pool . . . . . . .57
7.5.3 Explicit Stack Allocation. . . . . . . . . . . . . . . . . . . . . . . . . .59
7.5.4 Stack Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
8 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
8.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
8.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
8.3 Task Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
8.4 Run-time Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
8.5 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
8.6 Conventions  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 3
Section 5. Sc heduler
1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
2.1 Simple Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
3 Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
3.1 Non-preemptive Scheduling . . . . . . . . . . . . . . . . . . . . . . . .67
3.2 Full-preemptive Scheduling. . . . . . . . . . . . . . . . . . . . . . . . .68
3.3 Mixed-preemptive Scheduling. . . . . . . . . . . . . . . . . . . . . . .69
4 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
4.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
4.2 Run-time Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
4.3 Scheduler Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Section 6. Int errupt Proc essing
1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

Table of Contents
OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Table of Contents 7
 NON-DISCLOSURE AGREEMENT REQUIRED
3 ISR Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
4 ISR Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
4.1 ISR Category 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
4.2 ISR Category 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
4.3 ISR Category 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
5 Interrupt Flag Manipulation. . . . . . . . . . . . . . . . . . . . . . . . . . . .77
6 Local Variables Considerations . . . . . . . . . . . . . . . . . . . . . . . .78
7 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
7.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
7.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
7.3 Run-time Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
7.4 Conventions  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 1
7.5 ISR Definition  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
7.6 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Section 7. Resource Management
1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
3 Access to Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
3.1 Priority Ceiling Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . .87
3.2 Scheduler as a Resource . . . . . . . . . . . . . . . . . . . . . . . . . .88
4 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
4.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
4.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
4.3 Run-time Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
4.4 Resource Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Sectio n 8. Counters and Alarms
1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
3 Counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
4 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
5 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
5.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
5.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100

 NON-DISCLOSURE AGREEMENT REQUIRED
Table of Contents
User’s Manual OSEK Opera ting  System — Rev 1.2
Table of Contents MOTOROLA
5.3 Counters and Alarm Generation  . . . . . . . . . . . . . . . . . . . .101
5.4 Run-time Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
5.5 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Secti on 9. Events
1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
3 Events and Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
4 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
4.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
4.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
4.3 Events Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
4.4 Run-time Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
4.5 Additional Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Section 10. Communi cation
1 Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
2 Message Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
3 Unqueued Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
4 Queued Messages  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
5 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
5.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
5.2 Identifiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
5.3 Message Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
5.4 Run-time Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
5.5 Usage of Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Section 11. Error Handling and Special Routines
1 Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
3 Hook Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
4 Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
4.1 Error Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
4.2 Extended Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127

Table of Contents
OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Table of Contents 9
 NON-DISCLOSURE AGREEMENT REQUIRED
4.3 Possible Error R easons. . . . . . . . . . . . . . . . . . . . . . . . . . .128
5 Start-up Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
6 Application Modes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
7 System Shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
8 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
8.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Section 12. System Configuration
1 Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
3 Application Configuration File. . . . . . . . . . . . . . . . . . . . . . . . .134
4 OIL Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
4.1 OIL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
4.2 Standard OIL Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
4.3 Extended OIL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
4.4 Implementation Definition . . . . . . . . . . . . . . . . . . . . . . . . .135
4.4.1 Implementation Definition Grammar  . . . . . . . . . . . . . . .136
4.5 Application Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
4.5.1 Object Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
4.5.2 Include Directive  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
4.5.3 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
4.5.4 File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
4.6 Configuration File Rules . . . . . . . . . . . . . . . . . . . . . . . . . .140
Section 13. System O b jects Definition
1 Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
3 OS Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
3.1 Global System Attributes. . . . . . . . . . . . . . . . . . . . . . . . . .142
3.2 Task Related Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . .147
3.3 Interrupt Related Properties . . . . . . . . . . . . . . . . . . . . . . .149
3.4 Resources and Events Related Attributes. . . . . . . . . . . . .151
3.5 Counters and Alarms Related Attributes. . . . . . . . . . . . . .152
3.6 Messages Related Attributes  . . . . . . . . . . . . . . . . . . . . . .153
3.7 Hook Routines Related Attributes. . . . . . . . . . . . . . . . . . .154
3.8 OS Service Related Attributes. . . . . . . . . . . . . . . . . . . . . .155

 NON-DISCLOSURE AGREEMENT REQUIRED
Table of Contents
User’s Manual OSEK Opera ting  System — Rev 1.2
Table of Contents MOTOROLA
4 Task Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
4.1 Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
4.2 Object References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
5 Stack Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
5.1 Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
6 Resource Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
6.1 Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
7 Event Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
7.1 Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
8 Counter Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
8.1 Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
9 Alarm Definition  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
9.1 Object References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
10 Message Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
10.1 Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
10.2 Object References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
11 ISR Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
11.1 Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
11.2 Object References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
12 Different Application Modes Definition . . . . . . . . . . . . . . . . . .168
Section 14. Building of Application
1 Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
2 Application Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
3 Action Sequence to Build an Application . . . . . . . . . . . . . . . .172
3.1 Application Configuration  . . . . . . . . . . . . . . . . . . . . . . . . .173
3.2 Source Files  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
3.3 Compiling and Linking. . . . . . . . . . . . . . . . . . . . . . . . . . . .178
4 Sample Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Section 15. HC12 Platform-Specific Features
1 Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
2 Compiler-Specific Features  . . . . . . . . . . . . . . . . . . . . . . . . . .179
2.1 OSEK OS Environment Variables. . . . . . . . . . . . . . . . . . .179

Table of Contents
OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Table of Contents 11
 NON-DISCLOSURE AGREEMENT REQUIRED
2.2 Cosmic Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
3 Interrupt Flag Manipulation Specific Features . . . . . . . . . . . .180
4 HC12 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
4.1 Base Page Memory Usage . . . . . . . . . . . . . . . . . . . . . . . .182
4.1.1 Mapping RAM and REGISTERS . . . . . . . . . . . . . . . . . .182
4.2 Interrupt Vector Table . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
4.3 The Banked Memory Model Support. . . . . . . . . . . . . . . . .184
4.3.1 Banked Memory Model Overview . . . . . . . . . . . . . . . . .184
4.3.2 Configuration of the Application for Banked Memory. . .185
4.3.3 Cosmic Compiler Issue . . . . . . . . . . . . . . . . . . . . . . . . .186
4.4 Recommendations on System Properties. . . . . . . . . . . . .187
4.4.1 UseMainStack property . . . . . . . . . . . . . . . . . . . . . . . . .187
4.4.2 UseSameContext Property  . . . . . . . . . . . . . . . . . . . . . .187
4.4.3 InterruptMaskControl Property. . . . . . . . . . . . . . . . . . . .187
4.4.4 CounterSize Property. . . . . . . . . . . . . . . . . . . . . . . . . . .188
4.4.5 Unused Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
4.5 System Timer Hardware . . . . . . . . . . . . . . . . . . . . . . . . . .188
4.6 Scheduler Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .191
4.7 Alarms Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
5 Task Stack Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Section 16. Application Troubleshooting
1 Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
2 System Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
3 Using OS Extended Status for Debugging . . . . . . . . . . . . . . .193
4 Context Switch Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
5 Stack Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
6 Known Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
Section 17. System Services
1 Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
3 Task Management Services. . . . . . . . . . . . . . . . . . . . . . . . . .199
3.1 Data types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
3.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
3.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200

 NON-DISCLOSURE AGREEMENT REQUIRED
Table of Contents
User’s Manual OSEK Opera ting  System — Rev 1.2
Table of Contents MOTOROLA
3.4 Task Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
3.5 ActivateTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
3.6 TerminateTask  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
3.7 ChainTask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
3.8 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204
3.9 GetTaskId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
3.10 GetTaskState  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206
3.11 GetTCBInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207
3.12 Examples for Task Management Services . . . . . . . . . . . .208
4 ISR Management Services. . . . . . . . . . . . . . . . . . . . . . . . . . .210
4.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210
4.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
4.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
4.4 EnterISR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
4.5 LeaveISR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
4.6 EnableInterrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214
4.7 DisableInterrupt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
4.8 GetInterruptDescriptor. . . . . . . . . . . . . . . . . . . . . . . . . . . .217
4.9 Examples for Interrupt Management Services . . . . . . . . .218
5 Resource Management Services . . . . . . . . . . . . . . . . . . . . . .220
5.1 Data types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
5.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
5.3 Resource Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
5.4 GetResource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
5.5 ReleaseResource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223
5.6 Examples of Using Resources . . . . . . . . . . . . . . . . . . . . .224
6 Counters and Alarms Management Services. . . . . . . . . . . . .225
6.1 Data Types and Identifiers  . . . . . . . . . . . . . . . . . . . . . . . .225
6.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
6.3 Counter and Alarm Declaration. . . . . . . . . . . . . . . . . . . . .227
6.3.1 Counter Declarati on. . . . . . . . . . . . . . . . . . . . . . . . . . . .227
6.3.2 Alarm Declaration  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
6.4 InitCounter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
6.5 CounterTrigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
6.6 AdvanceCounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
6.7 GetCounterValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
6.8 GetCounterInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
6.9 SetRelAlarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

Table of Contents
OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Table of Contents 13
 NON-DISCLOSURE AGREEMENT REQUIRED
6.10 SetAbsAlarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235
6.11 CancelAlarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236
6.12 GetAlarmBase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
6.13 GetAlarm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
6.14 Examples for Counter and Alarm Management . . . . . . . .239
7 Event Management Services . . . . . . . . . . . . . . . . . . . . . . . . .242
7.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
7.2 Event Declarati on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
7.3 SetEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
7.4 ClearEvent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
7.5 GetEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
7.6 WaitEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
7.7 Examples of Using Events  . . . . . . . . . . . . . . . . . . . . . . . .247
8 Communication Management Services . . . . . . . . . . . . . . . . .249
8.1 Data Types and Identifiers  . . . . . . . . . . . . . . . . . . . . . . . .249
8.2 SendMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
8.3 ReceiveMessage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252
8.4 GetMessageResource. . . . . . . . . . . . . . . . . . . . . . . . . . . .253
8.5 ReleaseMessageResource. . . . . . . . . . . . . . . . . . . . . . . .254
8.6 GetMessageStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
8.7 Examples of Using Messages. . . . . . . . . . . . . . . . . . . . . .256
9 Operating System Execution Control . . . . . . . . . . . . . . . . . . .259
9.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
9.2 GetActiveApplicationMode . . . . . . . . . . . . . . . . . . . . . . . .259
9.3 StartOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
9.4 ShutdownOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
9.5 Examples of Appl ication Modes Usage. . . . . . . . . . . . . . .261
9.6 Hook Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
9.6.1 ErrorHook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
9.6.2 PreTaskHook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
9.6.3 PostTaskHook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
9.6.4 IdleLoopHook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
9.6.5 StartupHook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267
9.6.6 ShutdownHook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268
Section 18. ORTI Implementation
1 Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269

 NON-DISCLOSURE AGREEMENT REQUIRED
Table of Contents
User’s Manual OSEK Opera ting  System — Rev 1.2
14 Table of Contents MOTOROLA
18.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
18.3 ORTI Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271
18.3.1 ORTI Trace Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . .271
18.3.2 ORTI Breakpoint Interface. . . . . . . . . . . . . . . . . . . . . . . . .273
18.4 ORTI Supporting OS Properties. . . . . . . . . . . . . . . . . . . . . . .274
18.5 ORTI Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
Appendix A. Sample Application
A.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
A.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
A.3 Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
Appendix B. System Service Timing
B.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
B.2 General Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
Appendix C. Memory Requirements
C.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
C.2 Memory for the OSEK Operating System. . . . . . . . . . . . . . . .289
C.3 Data Sheet for the Cosmic . . . . . . . . . . . . . . . . . . . . . . . . . . .292
Appendix D. System Generation Error Messages
D.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
D.2 Error Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
D.3 Error Messages  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
D.4 Warning Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
Appendix E. Quick Reference
E.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
E.2 System Services Quick Reference. . . . . . . . . . . . . . . . . . . . .319
E.3 OIL language Quick Reference  . . . . . . . . . . . . . . . . . . . . . . .325
E.3.1 OS Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326

Table of Contents
OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Table of Contents 15
 NON-DISCLOSURE AGREEMENT REQUIRED
E.3.2 TASK Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345
E.3.3 ISR Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
E.3.4 STACK Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
E.3.5 RESOUR CE Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
E.3.6 ALARM Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
E.3.7 COUNTER Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
E.3.8 MESSAGE Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
E.3.9 EVENT Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .351
User’s Manual Index

NON-DISCLOSURE AGREEMENT REQUIRED

Table of Contents

User’s Manual OSEK Opera ting System — Rev 1.2

16 Table of Contents MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA List of Figures 17
 NON-DISCLOSURE AGREEMENT REQUIRED
Figure Title Page
User’s Manual — OSEK Operating System
List of Figures
3-1 Restricted upward compatibility for conformance classes . .33
4-1 Task status model of an Extended Task with its task 
transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
4-2 Task status model with task transitions for Basic Tasks . . .4 4
4-3 Task management architecture . . . . . . . . . . . . . . . . . . . . . .46
4-4 Task priorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
4-5 Persistent task node assignment . . . . . . . . . . . . . . . . . . . . .53
4-6 Task link table  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
4-7 Fixed stack linked with the task node. . . . . . . . . . . . . . . . . .56
4-8 Dynamic stack allocation from the stack pool  . . . . . . . . . . .57
4-9 Persistent stack allocation from the stack pool  . . . . . . . . . .58
4-10 Static stack allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
5-1 Non-preemptive scheduling . . . . . . . . . . . . . . . . . . . . . . . . .68
5-2 Full-preemptive scheduling  . . . . . . . . . . . . . . . . . . . . . . . . .69
7-1 Priority Ceiling Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
8-1 Counters and alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
8-2 Two cases for the absolute alarm  . . . . . . . . . . . . . . . . . . . .98
9-1 Synchronization by events in case of full-preemptive 
scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
9-2 Synchronization by events in case of full-preemptive 
scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
10-1 Operations with Queued Messages. . . . . . . . . . . . . . . . . .116
11-1 System startup in the OSEK OS  . . . . . . . . . . . . . . . . . . . .129
14-1 Application building process. . . . . . . . . . . . . . . . . . . . . . . .173
15-1 Banked Memory Model  . . . . . . . . . . . . . . . . . . . . . . . . . . .185
18-1 Application Building Process with ORTI Support . . . . . . . .270

NON-DISCLOSURE AGREEMENT REQUIRED

List of Figur e s

User’s Manual OSEK Opera ting System — Rev 1.2

18 List of Figures MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA List of Tables 19
 NON-DISCLOSURE AGREEMENT REQUIRED
Figure Title Page
User’s Manual — OSEK Operating System
List of Tables
3-1 OSEK OS Conformance Classes. . . . . . . . . . . . . . . . . . . . . .34
3-2 OSEK OS maximal system resources . . . . . . . . . . . . . . . . . .35
4-1 States and status transitions in the case of Extended Tasks.42
4-2 States and status transitions in the case of Basic Tasks . . . .43
4-3 Task Properties  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
4-4 Task Management R un-time Services . . . . . . . . . . . . . . . . . .62
6-1 Interrupt Management Services in the OSEK OS  . . . . . . . . .81
8-1 Counter and Alarm Management Run-time Services. . . . . .102
9-1 Event Management Run-time Services . . . . . . . . . . . . . . . .109
10-1 Features of the Message Concept . . . . . . . . . . . . . . . . . . . .113
10-2 Task Management Run-time Services . . . . . . . . . . . . . . . . .119
11-1 OSEK OS system services for hook routi nes. . . . . . . . . . . .124
11-2 OSEK OS Error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
14-1 System Generator command line options  . . . . . . . . . . . . . .174
15-1 Parameters to define System Timer hardware. . . . . . . . . . .189
18-1 ORTI Generator Command Line Options. . . . . . . . . . . . . . .276
B-1 OSEKOS_20 version of the Operating System run-time services 
timing characteristics (HC12D60, Cosmic software) . . . . . .285
C-1 OSEKOS_20 version of the Operating System memory 
requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292
E-1 OSEK OS services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
E-2 Data Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .322
E-3 Constructional elements. . . . . . . . . . . . . . . . . . . . . . . . . . . .323
E-4 OSEK Operating System run-time services return values 
and error values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324
E-5 OSEK Operating System constants . . . . . . . . . . . . . . . . . . .325
E-6 OS Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
E-7 TASK Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345
E-8 ISR Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
E-9 STACK Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
E-10 RESOURCE Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . .348

NON-DISCLOSURE AGREEMENT REQUIRED

Lis t of Tables

User’s Manual OSEK Opera ting System — Rev 1.2

20 List of Tables MOTOROLA

E-11 ALARM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348

E-12 COUNTER Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . .349

E-13 MESSAGE Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . .349

E-14 EVENT Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .351

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Overview 21

NON-DISCLOSURE AGREEMENT REQUIRED

User’s Manual — OSEK Operating System

Section 1. Overview

OSEK1 Operating System (OSEK OS) is a real-time operating system

which conforms to the specification of the OSEK/VDX Operating System

version 2.0, revision 1, 15 October 1997.

OSEK OS conforms to the following requirements:

• OS is fully configured and statically scaled;

• OSEK OS is a ROM-able system, i.e. the OS code may be

executed from Read-Only-Memory. OSEK OS may be placed into

chip memory d uring manu facture, an d users’ appl icatio ns may be

added during development time;

• OS performance parameters are well known;

• Being written in strict correspondence with ANSI C standard, the

OS and application on its basis can be easily ported from one

platform to another.

A wide rang e of scalability, a set of system ser vices, various scheduling

mechanisms, and convenient configuration features make the OSEK

Operating System feasible for a broad spectrum of applications and

hardware platforms.

The OSEK OS provides a pool of different services and processing

mechanisms for task management and synchronization, data exchange,

resource management, and interrupt handling. The following features

are granted to the user:

1. The ter m OSEK means ‘Off ene Systeme und deren Schnittstellen fur die Elektr onik im Kraft-

fahrzeug ’ (Open systems and the corresponding interfaces for aut om oti ve electronics). A r eal-

time operating system, software interfaces and functions for communication and network man-

agement tasks are thus jointly specified within the OSEK standard.

NON-DISCLOSURE AGREEMENT REQUIRED

Overview

User’s Manual OSEK Opera ting System — Rev 1.2

22 Overview MOTOROLA

Task Management

• Activation and termination of tasks;

• Management of task states, task switch.

Scheduling Policies

• Full-, non-, and mixed-preemptive scheduling techniques.

Event Control

• Event Control for task synchronization.

Interrupt Management

• Services for hardware interrupt flag manipulations;

• Frames for interrupt service routines.

Resource Managem ent

• Mutually exclusive access control for inseparable operations to

jointly used resources or devices, or for control of a program flow.

Communication1

• Unqueued Message: Data exchange without buffering;

• Queued Message: Data exchange with buffering.

Counter2 and alarm management

• Counter management provides services for execution of recurring

events;

• Alarm ma nagem ent is based on co unter ma nagem ent. It ena bl es

entry o f (cyclic) alar m requests. The expir ation of a preset re lative

counter value, or the fact that a preset absolute counter value is

reached, results in activation of a task, or setti ng of a task event.

1. Communi cation part of OSEK Operat in g System conforms the spe cification of the OSEK Com-

municati on System, version 2.1, revision 1, 17 June 1998.

2. Counter Management part of OSEK Operating System conforms the specification of the OSEK

Operating System Application Progr am Int erfac e version 1.00, 11 September 199 5.

Overview

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Overview 23

NON-DISCLOSURE AGREEMENT REQUIRED

Error treatment

• Mechanism supporting the user in various error classes.

ORTI Subsystem

• ORTI provides interface to Operating System run-ti me data for

“OSEK aware” debuggers.

OSEK Ope rating S ystem is scaled in t w o ways – eithe r b y ch angi ng the

set of system ser vices or via the so-called Conformance Classe s. They

are available to satisfy different requi rements concerning functionality

and capability of t he OS. These Conformance Classes do not only differ

concerning the number of services they provide, but also with regard to

their capab ilities and scalability. The classes ar e based on one an other

in upwardly compatible fashion. The Conformance Classes are

generated by meaningful grouping of services (see

Section 3.3 Conformance Classes).

The OSEK OS is built according to the user’s configuration i nstructions

at system gene ration time. Both system a nd application para meters are

configured statically. Therefore, a special tool called the System

Generator is used for this purpose. Special statements are designed to

tune any parameter. The user must only edit the definition file, run

System Generator and then assemble resulting files with application

files. Thu s, the user can adapt th e Ope rating Syst em to the c ontro l task

and the tar get hardwar e. OS cannot be modified l ater a t execution ti me.

OSEK Operating System is well documented and measured. In the

User’s Manual, all system mechanisms, particularities, services and

programming techniques are described in detail with numerous

examples. Numbers for performance characteristics and memory

requirements are provided.

NON-DISCLOSURE AGREEMENT REQUIRED

Overview

User’s Manual OSEK Opera ting System — Rev 1.2

24 Overview MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Notation 25
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 2. Notation
2.1 Contents
2.2 Manual Structure  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
2.3 Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . .27
2.4 Definitions, Acronyms and Abbreviations. . . . . . . . . . . . . . . . .27
2.5 Installation Instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
2.6 Technical Support Information . . . . . . . . . . . . . . . . . . . . . . . . .29
2.2 Manual Structure
This User’s Manual consists of the following sections:
Section 1 Overview descr ibes what the OSEK OS is  and highl ights its 
basic features.
Section 2 Notation contains a description of the Manual structure, 
typographical conventions and the list of acronyms.
Section 3 Operating System Architecture gives a high level 
description of OS architecture and presents OS Conformance Classes.
Sect ion 4 Task Managem en t explains the task concept in OSEK and 
all other questions related to tasks.
Section 5 Scheduler provides a description of scheduling policies in 
OSEK OS.
Section 6 Interrupt Processing highlights the OSEK approach to 
interrupt handling.
Section 7 Resource Managem ent describes resource management 
and task coordination by resources.

 NON-DISCLOSURE AGREEMENT REQUIRED
Notation
User’s Manual OSEK Opera ting  System — Rev 1.2
26 Notation MOTOROLA
 
 
 
Section 8 Counters and Alarms describes usage of these control 
mechanisms in OSEK OS.
Section 9 Events is devoted to event management and task 
coordination by events.
Section 10 Communication describes message concept in OSEK and 
their usage.
Section 11 Error Handling and Special Routines describes support 
provided to the user to debug an application and handle errors.
Section 12 System Configuration describes possible OSEK OS 
versions, configuration options and the configuration mechanism.
Section 14 Building of Application contains information on how to 
build an user’s application using OSEK OS. It also describes memory 
requirements.
Section 15 HC12 Platform-Specific Features discusses special 
OSEK OS features for different MCU types and issues connected with 
porting applications to these MCUs.
Sect ion 16 Ap plicatio n Troublesh ootin g co ntains u seful i nfo rma tion 
for debugging applications developed using OSEK OS. 
Section 17 System Services provides a detailed description for all 
OSEK Oper ating System run-ti me services, with appr opriate examp le s. 
Section 18 ORTI Implementation provides information about 
preparation all data needed for OSEK aware debugger to display 
information about application in OSEK terms.
Appendix A Sample Application contains the text and listing of a 
sample customer application developed using OSEK OS. 
Appendix B System Service Timing provides information about OS 
services execution time. 
Ap pe nd ix C M em or y Re qu i re men ts  pro vides infor matio n ab out t he 
amoun t of  R OM a nd RA M  direc tl y used  by va riou s ver si ons o f the  OSEK 
OS.

Notation

Typographical Convent ions

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Notation 27

NON-DISCLOSURE AGREEMENT REQUIRED

Appendix D System Generation Error Messages explains OSEK OS

System Generator error messages.

Appendix E Quick Reference briefly lists all OSEK OS run-time

services, with entry and exit conditions.

2.3 Typographical Conventions

This manual employs the following typographical conventions:

boldface type

Bold is used for important terms, notes and warnings.

Italics

Italics are used for all OSEK names of directives, macros,

constants, routines and variables.

Courier font

Courier typeface is used for code examples in the text.

Courier

Italic

Courier Italic typeface is used for OSEK terms when these are

first introduced.

2.4 Definitions, Acronyms and Abbreviations

API Application Program Interface (a set of data types and functions)

BCC Basic Conf orma nce Class, a defin ed set of f uncti onalit y in OSEK, for

which the waiting state of tasks is not permitted

BT Basic task (task, which never has the waiting state)

CPU Central Processo r Unit

ECC Extended Conforma nce Class, a defi ned set of functional ity in

OSEK, for which the waiting state of tasks i s permitted

ECU Electr onic Control Unit (simi lar to MCU)

ET Extended Task (task, which may have the waiting state)

NON-DISCLOSURE AGREEMENT REQUIRED

Notation

User’s Manual OSEK Opera ting System — Rev 1.2

28 Notation MOTOROLA

2.5 Installation Instructions

2.5.1 Required Environment

Thi s version of the product i s to be used o n an IBM PC 486 (and hi gher)

compatible. To install and evaluate the product, you require

approximately 4 MB of hard disk space.

The PC must work under MS Windows 95 or Windows NT 4.0 during

OSEK installation.

To use OSEK OS after installation install the Cross Compiler on yo ur

computer (See Section 15 for more information). You must call the DOS

prompt under Windows NT to run the NMAKE utility.

All supplied makefiles are developed for the Microsoft C++ NMAKE

utility.

ID Identifier, an abstr act ide ntifier of a system object

ISF Interrupt Stack Fra me , a stacked model of CPU regi sters, produced

by CPU hardware and/or software instructions during CPU interrupt

ISR Inter rupt Servi ce Routi ne

MCU Microcontroller Uni t (Motorola’s micro controll ers)

MO Message object

N/A Not applicable

OIL OSEK Implementation Language

ORTI OSEK Run Time Interface

Orti Ge n ORTI Generator Utilit y

OS Operating System, a part of the OSEK

OSEK Open sys tems and their corresponding int erfaces for automotive

electronics (in German)

OSEKOS_20 Implementation of the OSEK OS according to "OSEK/VDX Operat-

ing System", Version 2.0 Revision 1, 15 October 1997

RAM Random Access Memory

ROM Read Only Memory

SG, SysGen System Generator

Notation

Technical Support Information

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Notation 29

NON-DISCLOSURE AGREEMENT REQUIRED

2.5.2 Installation

To setup OSEK OS on your hard drive:

1. Insert the installation disk into a 3.5” floppy drive. The following

instructions assume that the drive letter is a:. If another drive is

chosen, substitute that drive letter where appropriate.

2. Run the A:\SETUP.EXE program either from the File Manager or

Program Manager.

3. Follow the prompts and instructions of the installation program.

4. After installation verify the consistency of the package by means

of comparing the real set of files and directories with the list in

FILELIST.TXT file.

After installation, the hard drive should contain the root directory of

OSEK which contains a set of files in the following subdirectories:

• BIN System Generator

• INC Operating System header files

• SRC Operating System source files

• HWSPEC Hardware specific files (usual ly startup and vector

table files)

• SAMPLE OSEK Operating System Sample application

• MAN User’s Documentation

There is a file titl ed FILELIST.TXT file in the OSEK OS root directory.

This document contains a complete list of files included in this release.

2.6 Technical Support Information

For additional product or support information please contact your local

Motorola Sales Office. Alternatively, use the following contact methods:

Email: osek@helpline.sps.mot.com

Phone: +44 13 55 35 53 98 (English)

+49 89 92 10 38 83 (German or English)

NON-DISCLOSURE AGREEMENT REQUIRED

Notation

User’s Manual OSEK Opera ting System — Rev 1.2

30 Notation MOTOROLA

Fax: +44 13 55 26 52 01 (English)

+49 89 92 10 38 20 (German or English)

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Operating System Architecture 31
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 3. Operating System Architecture
3.1 Contents
3.2 Processing Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
3.3 Conformance Classes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
3.4 OSEK OS Overall Architecture. . . . . . . . . . . . . . . . . . . . . . . . .35
3.5 Application Program Interface  . . . . . . . . . . . . . . . . . . . . . . . . .37
3.2 Processing Levels
The OSEK Operating System provides a pool of different services and 
processing mechanisms. It serves as a basis for application programs 
which are independent of each other, and provides their environment on 
a processor. The OSEK OS enables a controlled real-time execution of 
several processes which virtually run in parallel.
The OSEK Operating System provides a defined set of interfaces for the 
user. Th ese i nterfaces ar e used by ent i ties whi ch are com peting  for the 
CPU. There are two types of entities:
• Interrupts (service routines managed by the Operating System);
• Tasks (basic tasks and extended tasks).
The highest processing priority is assigned to the interrupt level, where 
interrupt service routines (ISR) are executed. Interrupt services may call 
a number of operating system services. The processing level of the 
operating system has a priority ranking immediately below the former 
one. This is the level on which the operating system works: task 
management procedures, scheduler and system services. Just below 
this is the task level on which the application software is executed. Tasks 
are executed according to their user assigned priority. A distinction is 

NON-DISCLOSURE AGREEMENT REQUIRED

Operatin g System Architecture

User’s Manual OSEK Opera ting System — Rev 1.2

32 Operating System Architecture MOTOROLA

made between the management of tasks with and without waiting state

(Extended and Basic Tasks, see Section 4.2 Task Concept). The run

time context refers to resources which are occupied at the beginning of

execution time and are released again once the task is finished.

The following priority rules have been established:

• Interrupts have precedence over tasks;

• The interrupt priority is defined by specific hardware conditions;

• For items handled by the OS, bigger numbers refer to higher

priorities;

• The task’s priority is statically assi gned by the user.

The Operating System provides services and ensures compliance with

the priority rules mentioned above.

3.3 Conformance Classes

Vari ous requirements of the application software for the system, and

various capab ilities of a specific system ( e.g. processor type, amoun t of

memory) demand different features of the operating system. These

operating system features are described as Conformance Classes (CC).

They differ in the number of services provided, their capabilities and

different types of tasks.

Conformance classes were created to support the following objectives:

• To provide convenient groups of operating system features for

easier understanding and discussion of the OSEK operating

system.

• To allow partial implementations along pre-defined lines. These

partial implementations may be certi fied as OSEK compliant.

• To create un upgrade path from classes of lesser functionality to

classes of higher functionality with no changes to the application

using OSEK related features.

The desired Conformance Class is selected by the user at system

generation time and cannot be changed during execution.

Operating System Architect ure

Conformance Classes

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Operating System Architecture 33

NON-DISCLOSURE AGREEMENT REQUIRED

The definition of the functionalities provided by each Conformance Class

depend s on the prop erties of the t asks and on the scheduling beha vio r.

As th e task pro perties (Basic o r Ex tended, see Sect ion 4.3 Task Stat e

Model) have a distinct influence on CC, they also assume part of their

names. There are Basic-CC and Extended-CC, and each of these

groups can have various “derivatives”.

Conformance classes are determined by the following attributes:

• Multiply requesting of task activation (see Section 4.4 Task

Activation an d Termination);

• Task types (see Section 4.3 Task State Model);

• Number of tasks per priority.

Figure 3-1. Restricted upward compatibility for conformance

classes

The following Conformance Classes are defined in the OSEK OS:

BCC1, BCC2, ECC1, ECC2.

• BCC1 – o nly Basic tasks, limite d to o ne re quest p er ta sk and o ne

task per priority, while all tasks have different priorities;

• BCC2 – like BCC1, more than one task per priority possible and

multiple activation admissible;

• ECC1 – like BCC1, plus Extended tasks;

• ECC2 – like BCC2, plus Extended tasks without multiply activation

admissible.

ECC1

ECC2

BCC1

BCC2

1 task/pri ority

no multiply activations

>1 task/priority

multiply activations for

basic tasks only

BT only BT and ET

NON-DISCLOSURE AGREEMENT REQUIRED

Operatin g System Architecture

User’s Manual OSEK Opera ting System — Rev 1.2

34 Operating System Architecture MOTOROLA

BCC1 defines the minimum Conformance Class of the OSEK OS, ECC2

defines its maximum CC.

Multiple activations means that the OSEK OS receives and records

activations (even multiple activations) of a task already activated.

In the OSEK OS the number of task multiply activations is defined in a

basic task specific attribute during system generation. If the maximum

number of multiply activations has not been reached, the activation of

the basic task is queued in a Scheduler queue to preserve task activation

order.

Table 3-1 presents minimum resources to which an application may

resort, determined for each Conformance Class in the OSEK OS.

The system configuration option

(specified by the user) defines the

class of the overall system. This option can have values

BCC1

BCC2

ECC1

ECC2

(see Section 13.3 OS Definition).

It is impossible to have tasks of different Conformance Classes in one

application! All tasks must strictly conform to the Conformance Class

specified at the system configuration stage.

Table 3-1. OSEK OS Conformance Classes

BCC1 BCC2 ECC1 ECC2

Mul tip le acti vatio n of tasks no yes BT: no,

ET: no BT: yes,

ET: no

Number of tasks which are

not in the

suspended

st a te >=8>= 16, any combination

of BT/ET

Number of tasks per priority 1 >1 1

(both BT/ET) >1

(both BT/ET)

Numb er of events per t ask - BT: no

ET: >= 8

Numbe r of pr iority classes >=8

Resources only

Scheduler >= 8 resources (i nclud ing Scheduler)

Alarm >= 1 singl e or cyclic alarm

Messages possible

Operating System Architect ure

OSEK OS Over all Architectu re

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Operating System Architecture 35

NON-DISCLOSURE AGREEMENT REQUIRED

Table 3-2 presents maximal values for system resources:

1. See Appendix C Memory Requirements for memory consumption numbers.

2. Keeping this value allows a byte to be used whic h improve s RAM and ROM requireme nts

and execution speed.

3. In case of using resource access check, number of resources is limited to 8, including

Scheduler. This corresponds to the following system configuration: STATUS = EXTEND-

ED, Resources = TRUE, ResourceAccessCheck = TRUE, FastResource = FALSE (see

Section 13.3 OS Def ini tion for the details of system configuration).

3.4 OSEK OS Overall Architecture

The OS EK OS is a real-time opera ting system, which is executed within

a single electronic control unit. It provides local services for user’s tasks.

The OSEK OS consists of the following components:

• Sched uler – contr ols t he allocati on of the CPU t o the

different tasks;

• Task management – provides operations with tasks;

• ISR management – provides entry/exit frames for interrupt

service routines and supports CPU

interrupt flag manipulation;

• Resource management– supports a special kind of semaphore

for mutually exclusive access to shared

resources;

Table 3-2. OSEK OS maximal system resources

BCC1 BCC2 ECC1 ECC2

Number of tasks which are

not in the

suspended

st a te limited onl y to RAM and/or ROM available (1)

Number of tasks per pri ority li mited only to RAM available

Numb er of events per t ask - BT: -

ET: 8(2)

Numbe r of pr iority classes 256(2)

Resources only

Scheduler limited only to RAM and/or ROM available(3)

Alarm li m it ed only to RAM and/or ROM available

Mess ages li m it ed only to RAM and/or ROM av ail able

NON-DISCLOSURE AGREEMENT REQUIRED

Operatin g System Architecture

User’s Manual OSEK Opera ting System — Rev 1.2

36 Operating System Architecture MOTOROLA

• Local communication – provides message exchange between

tasks;

• Counter management – provides operations on objects like

timers and incremental counters;

• Alarm management – links the tasks and counters;

• Err or h andlers – handl e the user’ s applica tion erro rs and

inte rnal er rors, a nd provi de r ecovery f rom

the error conditions;

• Hook routines – provide additional debugging features

• System start-up – initializes the data and starts the

execution of the applications;

• System timer – provides implementation-independent

time management.

As yo u have see n in Table 3-1, Co nformance Classes, in ge neral, differ

in the degree of services provided for the task management and

scheduling (number of tasks per priority, multiple requesting,

Basic/Extended Tasks). In higher CC advanced functionality is added for

resource management and event management only. But even in the

lowest BCC1 the user is provided with merely all OSEK OS service

mechanisms.

The OSEK Operating System is scaled not only via Conformance

Classes but it also has many various extensions which can be in any

Conformance Class. These extensions affect memory requirements and

overall syste m perfor mance. The exten sions can be turned on or turned

off with the help of the corresponding system configuration options.

These are all described in Section 12 System Configuration.

Since the OSEK Operating System is fully statically configured, the

confi guration proce ss is suppor ted by the System Generator (SG). This is

a command-line utility, which processes system generation statements

defined by the user in the special file. These statements fully describe

the desired system features and application object’s parameters. SG

produces C-code that is to be compiled together with other user’s source

code. The produced code consists of C-language definitions and

declarations of data as well as C-preprocessor directives. See

Operating System Architect ure

Appl ication Program Interface

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Operating System Architecture 37

NON-DISCLOSURE AGREEMENT REQUIRED

Section 12 System Configuration and S ect ion 14 Bu ildi ng of

Application for details about system generation.

3.5 Application Program Interface

The OSEK Operating System establishes the Application Program

Interface (API) which must be used for all user actions connected with

system calls and system objects. This API defines data types used by

the system, the syntax of all run-time service call s, declarations and

definitions of the system.

OSEK OS data types are described in subsections dedicated to the

corresponding mechanisms. Syntax of system calls and system

configuration statements are described briefly in corresponding

subsections and in detail in Section 12 System Configuration and

Section 17 System Services.

NOTE:

The user’s source code shall strictly correspond to the rules presented

in this Manual.

The OSEK OS can has the E xtended Status. It means that additi onal

checki ng is made i nside all OS activiti es and extended r eturn codes are

retur ned by all OS services to indicate error s if they have occu rred. See

Section 17 System Services and Sect ion 11.4 Error Hand ling

about Extended Status return values. To provide the Extended Status in

the system, the configuration option

STATUS

must be set to

EXTENDED

at the configuration stage.

NON-DISCLOSURE AGREEMENT REQUIRED

Operatin g System Architecture

User’s Manual OSEK Opera ting System — Rev 1.2

38 Operating System Architecture MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Task Management 39
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
S ect io n 4. Task Ma nage ment
4.1 Contents
4.2 Task Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
4.3 Task State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
4.4 Task Activation and Termination  . . . . . . . . . . . . . . . . . . . . . . .44
4.5 Task Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
4.6 Task Priorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
4.7 Task Related Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
4.8 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
4.2 Task Concept
Complex control software can conveniently be subdivided into parts 
exec uted a ccordin g to thei r  real- time r equire ments. The se parts can be 
implemented by means of tasks. A task provides the framework for the 
execution of functions. The Operating System provides parallel and 
asynchronous task execution organization by the scheduler.
OSEK OS provides a set of tools for the user to manage tasks. They are 
activated before their execution – memory resources needed for a task 
are allocated. Tasks may be terminated after necessary actions are 
perfor med – me mory reso urces are  released. A fter a task  is activate d, it 
may run and terminate or it may be implemented in an endless loop with 
at least one synchronizing system call. It is not possible to run several 
parallel endless loops without switching mechanism (scheduler). Tasks 
can be switched during their execution from one to another, or may be 
inte rru pted by  ISR. If no  task is acti ve, only th e schedu ler idl e loop  runs 
(s ee Section 5.2 General). Task states and transitions between them 
are discussed in  Section 4.3 Task State Model.

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Rev 1.2

40 Task Management MOTOROLA

Two different task concepts are provided by the OSEK OS:

• Basic Tasks (BT);

• Extended Tasks (ET).

Basic Tasks only release the processor, if:

• they are being terminated,

• the OSEK OS is executing higher-priority tasks, or

• interrupts occur which cause the processor to switch to an

interrupt service routine.

Extended Tasks are distinguished from Basic Tasks by being allowed to

use additional operating system services which may result in a

waiting

state. The

waiting

state allows the processor to be freed and to be

reassigned to a lower-priority task without the need to terminate the

Extended Task.

Both kinds of tasks have their advantages which must be compared,

appl ication dep endent. They ar e both justified an d are suppo rted by the

OSEK operating system.

Each task has a set of data related to it – a task descriptor located in

ROM ( task configuration table) and a task control block in RAM (task node)

for activated tasks. Also, each task has its own stack assigned. See

Section 4.7 Task Related Resources about the task control block, t he

task configuration table and the task stack.

Every running task is represented by its run time context. This refers to

CPU registers and some compiler-dependent ‘pseudor egisters’ i n RAM.

Whe n th e t ask i s inter rupt ed or preempte d by a nothe r task, the run ti me

context is saved in the task’s stack. Run time context differs for non-

preemptive and preemptive tasks; for preemptive tasks, more RAM is

requir ed to save th e cont ext. T here fore , for a m ixed-pr eem ptive syste m

(it means that both non-preemptive and preemptive tasks can exist in the

system, see Section 5.3 Scheduling Policy) a distinction can be made

by the Operating System between these types of contexts. It is

controlled by the

UseSameContext

configuration option. In the case

where different contexts are saved for non-preemptive and preemptive

tasks, the OS must perform add itional cod e to distingu ish the task typ e.

Task Managem ent

Task State Mode l

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 41

NON-DISCLOSURE AGREEMENT REQUIRED

Otherwise, some more RAM is re quired to st ore the ‘full’ co ntext for no n-

preemptive tasks too. The use of this option is applicati on dependent.

4.3 Task State Model

A task can be in several states since the processor can only execute one

instruction of a task at any point in time, but several tasks may be

competing for the processor at the same time. The OSEK OS is

responsible for saving and restoring task context in conjunction with

state transitions whenever necessary.

4.3.1 Extended Tasks

Extended Tasks have four task states:

•

running

In the running state, the CPU is assigned to the

task, so that its instructions can be executed.

Only one task can be in this state at any point in

time, while all the other states can be adopted

simultaneously by several tasks.

•

ready

All functional prerequisites for a transition into

the running state exist, and the task only waits

for allocation of the processor. The scheduler

decides which ready task is executed next.

•

waiting

A task cannot be executed (any longer),

because it has to wait for at least one event

(see Section 9 Events).

•

suspended

In the su spended state , the task is passive and

does not occupy any resources, merely ROM.

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Rev 1.2

42 Task Management MOTOROLA

Figure 4-1. Task status model of an Extended Task with its task

transitions

Termination of tasks is only possible if the task terminates itself (‘self-

termination’). This restriction is to avoid complex book-keeping of

resources dynamically allocated by the task.

running

ready

suspendedwaiting

wait terminate

preempt start

release activate

Table 4-1. States and status transitions in the case of Extended Tasks

Tran sition Former state New state Des cription

activate suspended ready A new task is entered into the

ready

list by a system

service.

start ready running A

ready

task selected by the scheduler is executed.

wait running waiting To be able to con tinue operation, the

running

task

requires an event. It causes its transition into the

waiting

state by using a syste m service.

release waiting ready Events have occurred on which a task has wa ited.

preempt running ready The scheduler decides to start another task. The

running

task is put into the

ready

state.

terminate running suspended The

running

task cau se s its transition into the

suspended

state by a system service.

Task Managem ent

Task State Mode l

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 43

NON-DISCLOSURE AGREEMENT REQUIRED

There is no provision for a direct tra nsition from the

suspended

state into

the

waiting

state. This transition is redundant and would add to the

complexity of the scheduler. The

waiting

state is not directly entered

from the

suspended

state since the task starts and explicitly enters the

waiting

state on it s own.

4.3.2 Basic Tasks

The state model of Basic Tasks is nearly identical to the Extended Tasks

state model. The only exception is that Basi c Tasks do not have a

waiting

state.

•

running

In the running state, the CPU is assigned to the

task so that its instructions can be executed.

Only one task can be in this state at any point in

time, while all the other states can be adopted

simultaneously by several tasks.

•

ready

All functional prerequisites for a transition into

the running state exist, and the task only waits

for allocation of the processor. The scheduler

decides which ready task is executed next.

•

suspended

In the su spended state , the task is passive and

does not occupy any resources, merely ROM.

Table 4-2. States and status transitions in the case of Basic Tasks

Transition Former state New state Description

activate suspended ready A new task is entered into the

ready

list by a system

service.

start ready running A

ready

task selected by the scheduler is executed.

preempt running ready The scheduler decides to start another task. The

running

task is put into the

ready

state.

terminate running suspended The

running

task cau se s its transition into the

suspended

state by a system service.

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Rev 1.2

44 Task Management MOTOROLA

Figu re 4-2. Task st atus mo del with task tr ansitions for Basi c Ta sks

4.4 Task Activation and Termination

Dep ending on the Confor mance C lass, a t ask can be activated sing le or

multiple.

The difference between single and multiple activation is that:

• For of a task suited for multi ple activation, all task activations are

noted down. It means that whenever a task i s activated by the

application, the appropriate task is started at the next possible

time, even if it is already running while the request is issued. In

suc h cases, the re quest is saved by the op eratin g s ystem, so the

task can be started again by the operating system once it has

been terminated. This procedure is repeated several times until all

request s have been com pleted. In th e OS EK OS the a cti vation of

the basic task is queued in Scheduler queues to preserve task

activation order.

running

ready

suspended

terminate

preempt start

activate

Task Managem ent

Task Activation and Te rmin ation

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 45

NON-DISCLOSURE AGREEMENT REQUIRED

• In the case of a task suited for single activation, ei ther the task

activation is noted down, or, if the task has already been

requested, nothing happens.

Multiple activation property exists only for BCC2 and ECC2

Conformance Classes. It is possible to turn it off via the system

configuration option

MultiplyActivation

OSEK OS uses the scheme of task acti vation an d terminat io n as shown

on Figure 4-3. This idea allows dynamic memory reallocation which

provides economical consumption of resources.

During task activation the

ActivateTask

service analyzes the task

configuration table of the task to be activated, and allocates a stack

buffer and a task node as specified in the task configuration table. In the

figure the typical allocation met hod is shown – a stack buffer is retrieved

from t he stack pool and a t ask node fro m the schedu ler’s list of free task

nodes. If these resources are available, then the task node is initialized

and inserted into the scheduler’s queues to be dispatched.

If the task does not have multiply activation requests, then the

TerminateTask

and

ChainTask

service s release both the task node and

the stack buffer and return them to the system for re-use. If a task has

multiple acti vation requests, then

TerminateTask

and

ChainTask

services do not release the task node and the stack buffer because

these structures will be used for task reactivation.

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Rev 1.2

46 Task Management MOTOROLA

Figure 4-3. Task management architecture

Hence, task activation may be considered as dynamic resource

allocation, because task control blocks and stack pools are allocated

dynamically. This approach allows the optimization of resource usage,

because one resource (for instance, a task control block) may be used

by different tasks at different times.

But, in th e case where re quested reso urces aren’t a vailable, it m ay lead

to indeterministic behavior of the operating system. This situation may

occur when too many tasks are activated. To avoid that weakness, the

user is also allowed to statically assign task control blocks and stack

areas for critical tasks. Such explicitly defined resources are held by a

task for the application life time. In this case, the task control block and/or

the task stack are not released and cannot be re-assigned for other

tasks.

Activate task Terminate task

Scheduler queues

Stack pools Task nodes

(control blocks) Task configuration tables

Free task

node

Stack

buffer

Running

task mode

Initialized

task mode

Task

configuration

table

Task Managem ent

Task Properties

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 47

NON-DISCLOSURE AGREEMENT REQUIRED

4.5 Task Properties

In OS EK OS every task i s chara cterized by the set o f pro pert ies . Th ese

properties define the task behavior and resource allocation method.

Each ta sk property has its own name, and the user defines the task

features by setting the corresponding properties in the task definition.

See Section 12 System Configuration about task definition. The list of

possible task properties is provided in Table 4-3.

4.6 Task Priorities

OSEK OS specifies the value 0 as the lowest priority in the operating

system. Accordingly bigger numbers define higher priorities.

In OSEK OS a priority is statically assigned to each task and it cannot be

changed by the user at the execution time. Some Conformance Classes

permit sever al tasks of the same priority level (see Section 3-1 OSEK

OS Conformance Classes). A dynamic priority management is not

Table 4-3. Task Properties

Property Name Property Value Descri ption

TYPE BASIC Ba sic task

EXTENDE D Extended task

SCHEDULE NO N N on-pree mptive task

FULL Preemptive task

AUTOSTART TRUE/ FA LS E Acti va te the task at syste m start-u p

PersistentNode TRUE/FALSE A persistent task control block is assigned (linked with the task

configuration tables)

StackMethod

POOLSTACK A stack should be allocat ed to the ta sk during task a ctivation –

dynamic stack allocation from the stack pool

OWNSTACK A stack is explicitly assigned to the task (address of the top of

the stack is included in the task configuration table)

NODESTACK A task node stack is implicitly assigned to be used by the task

(during the task activation)

PersistentStack TRUE/FALSE A persistent stack from the stack pool (t he pool identifier is

included in the task configuration table)

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Re v 1.2

48 Task Management MOTOROLA

supported. However, in particular cases the operating system can trea t

a task with a defined higher priority. In this context, please refer to

Section 7.3.1 Priority Ceiling Protocol.

On the basi s of th e task pr iority the schedul er decides wh ich is the next

of the

ready

tasks to be tr ansferred into the

running

state. Tasks are

started depending on their order of activation, according to the FIFO

mechanism, whereby an Extended Task in the

waiting

state does not

block the start of subsequent tasks of identical priority.

A preempted task is considered to be the oldest task in the

ready

list of

its current priority. A task being released from the

waiting

state is treated

like the newest task in the

ready

list of its priority.

Figure 4-4 illustrates how tasks priorities affect the order of their

execution

Figure 4-4. Task priorities

3N 2 1 0

FIFO

list of

ready

tasks

high low

priority

these tasks will be

executed in turn later

search the

next task to

be processed

> >

actually processed

and terminated task

(with priority N) scheduler next running task

CPU

scheduler

• • •

processor time

Task Managem ent

Task Related Resources

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 49

NON-DISCLOSURE AGREEMENT REQUIRED

Sever al tasks of dif ferent priorities are in the

ready

state – three tasks of

priority 3, o ne of priority 2, one o f priority 1, and two pr iority 0 tasks. The

task that has waited the longest time, depending of its order of

requesting, is shown at the bottom of each FIFO queue. The CPU has

just processed and terminated a task with priority N. The scheduler

selects the next task to be processed (priority 3, first FIFO location).

Befor e priority 2 tasks ca n be p rocessed, all tasks o f higher priority must

have been executed completel y.

Thus, the following three steps are made to switch to the next running

task:

1. The scheduler searches for all tasks in the

ready

state.

2. From the set of

ready

tasks, the scheduler determines the set of

tasks with the highest priority.

3. Within the set of tasks in the

ready

state and of the highest priority,

the scheduler finds the task that has been in the

ready

stat e the

longest time (‘oldest’ task).

4.7 Task Related Resources

Each task has a

task configuration table

in ROM and

task control block

(task node)

and

task stack

in RAM (during the task run time, if they are

not assigned statically). These resources uniquely define task properties

and th e task run-time cont ext. A lso, at r un- time t he

task link table

exists

in RAM to provide the correspondence between the task control block

and the task configuration table.

4.7.1 Task Configuration Table

The ROM-based

task configuration table

contains a static task

description. This table holds all the information describing the task’s

properties and serves to initialize the RAM-based task control block

during task activation.

The task configuration table contains the following data:

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Re v 1.2

50 Task Management MOTOROLA

• Task p rope rties (see Table 4-3) which def in e a ru n-tim e b ehavi or

of the task, as well as task activation parameters. The main

properties are whether it is a Basic/Extended task (for the

extended Conformance Classes only) or a preemptive/non-

preemptive task (for a mixed-preemptive scheduling policy). The

properties also specify the source of the stack for the task, and the

assi gnment of the task control block;

• OS internal priority of the task1;

• User defined priority of the task;

• The hardware memory bank of the task2. If banked memory model

is not supported (the

HCBankCode

system con figuration option is

turned off) this field is absent in the task configuration table;

• The starting interrupt mask of the task. This field is absent if

interrupt mask control is not supported;

• The program counter value (the entry po int) of the task;

• The address of the persistent task node, that is a task node that is

permanently assigned to the task (see Section 4.7.2 Task

Control Block). This field is absent if persistent task control

blocks are not supported in the system;

• The address of the task st ack source, i.e. the ad dress of the stack

pool or the constant address of the own task stack (see

Section 4.7.4 Task Stack). This field is absent if all tasks use

only node stacks.

• The maximum number of the task multiply activations.

• The address of the element of the task link table (see

Section 4.7.3 Task Link Table). This field is absent if the

simplified scheduler is used in the system ( see

Section 5.2.1 Simple Scheduler) or the system configuration

option

TaskIndexMethod

is off and task multiple activation is not

supported.

1. OSEK OS uses int ernal task priority during run-time. This priority is ca lcula ted by OSEK OS

SysG en tool d uring app licat ion con figur ation. It may di ffer from user -defi ned task pr iori ty as a r e-

sult of optimi zation.

2. Thi s propert y is not used in current version of OSEK OS.

Task Managem ent

Task Related Resources

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 51

NON-DISCLOSURE AGREEMENT REQUIRED

Some of these para meters are specified by the user during system

configuration by means of the T

ASK

object definition, whi le others are

generated automatically. See Section 12 System Configuration and

Section 14 Building of Application about system configuration and

building an application.

4.7.2 Task Control Block

A RAM-based task control block (task node) serves as a dynamic

descri pto r of the task. It is vali d only dur ing task e xecuti on, that is w hen

the task is not in the suspended state. Except persistent node

a ssignment (see Section 4.7.2.1 Persistent Node Assignment), this

task contro l block is l inked to the sched uler’s list of fr ee nodes when i t is

not assigned to the task. In general, this block is allocated to the task

during task activation, and it is initialized at that moment (see Figure 4-

3).

The task control block contains the following data:

• A pointer for linking the task control block into scheduler queues.

This field is ab sent if the simplified scheduler is used in the

system;

• The current task status. Some of the status bits are copied from

the task property bits of the task configuration table. Other bits are:

– a task waiting bit, which is set when the task is waiting for an

event(s);

– a scheduler bit, which is set when the task occupies the

scheduler.

• The cu rre nt task prior ity. In gene ral , t he cur rent pri o rity m ay diffe r

from the starting priority (located in the task configuration table)

during the periods of time when the task occupies the resources,

see Section 7.3.1 Priority Ceiling Protocol.This field is absent

if the simplified scheduler is used in the system;

• A pointer to the task configuration table;

• The task context (for non-preempti ve tasks), or a pointer to the

stack frame, where the context is saved (for preempti ve tasks).

Note, that for mixed-preemptive scheduling systems, both non-

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Re v 1.2

52 Task Management MOTOROLA

preemptive context and a pointer to the preemptive context are

defined if the system configuration option

UseSameContext

turned on. Otherwise, the preemptive context is used for non-

preemptive tasks also;

• Two fields for event control in Extended Classes of the system.

The first field contains the mask of the events the task is waiting

for, while the second field contains the mask of the events that are

set for the task (see Section 9 Events). If event man agem ent is

not supported, these fields are absent;

• The pointer to the head of the list of resources occupied by the

task (if resource management is supported and the system

property

FastResource

is turned off, see Section 7 Resource

Management);

• The address of the stack buffer allocated to the task. It is used

duri ng task termin ation when task mana gement retu rns this stack

buffer into the stack pool. If stack pools are not supported in the

system then this field is absent;

• The address of the task node stack or address of the persistent

task stack if persistent node assignment is supported by the

system. This field is absent if neither task node stacks nor

persistent stacks are used;

• The re al address of the to p of the task stack. Th is field is absent i f

multiple activation is not supported and the system configuration

option

ChainTaskItself

is turned off.

The task control block size depends on the system configuration and

task properties. See Appendix B S ystem Service Timi ng

4.7.2.1 Pers istent Node Assignment

The task control block may be statically assigned to the task. This

mechanism prevents a task activation failure due to missing free task

nodes and increases the speed of task activation/termination operations

by means of excluding a task node queue manipulation. This

mechanism is called persistent task node assignment, and it is illustrated

in Figure 4-5. To define persistent node assignment for the task, the

task pro perty

PersistentNode

must b e set in the TASK definition for this

Task Managem ent

Task Related Resources

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 53

NON-DISCLOSURE AGREEMENT REQUIRED

task and the system configuration option

PersistentNode

must be turned

on.

As it is in the figur e, task#2 has persiste nt task node#3 assigned to this

task. T herefore , this task contro l block cann ot be use d by any othe r task

in the system, and is not l inked into the scheduler’s list of free nodes

when task#2 is not activated (not used). Thi s task node is exclusively

assigned for use by task#2. On the other hand, task#1 may use any of

task nodes #1, #2 or #4, if they are free while task#2 is activated.

Persistent task node assignment may be used in combination with any

of the stack allocation options (see Se ctio n 4.7.4 T ask St ack).

Figure 4-5. Persistent task node assignment

4.7.3 Task Link Table

Every task in the system is defined via the ROM-based task

configuration table. When a task is activated, the task allocates a task

node, and the address of the task configuration table is stored in the task

Free task node #1

the task node address

Task configuration table #1

Task configuration table #2

Task nodes array

Free task node #2

Persistent task node #3

Free task node #4

Activate task

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Re v 1.2

54 Task Management MOTOROLA

node. To accelerate the procedure of run-time task referencing, the

system supports a special RAM-based vector of the links between the

task configuration tables and task nodes. This vector is called the

task

link table

. It se rves for fast a ccess to t he task configuration table and the

corresp onding task cont rol block during oper ations which reference to a

task.

The task link table is illustrated in the figure below:

Figur e 4-6. Task link table

The task link table contains one element per task configured in the

system. The element contains a NULL-pointer if the task is in the

suspended state, or the task node address if the task is in the non-

suspended state (it is saved there during task activation). For instance,

in Figure 4-6 task#1 is not activated, while task#2 and task#8 are

activated. Task#2 uses task node#4, and task#8 uses task node#1. The

task configuration table contains the address of the task link element.

The system uses this address when th e task is refer enced, and looks at

the contents of the elem ent of the task link table to define the current

state of the task.

If the OSEK OS supports task multiple activations, then the task link

table contains one additional element per task. The element is the

Task node #1

Task node #4

Task configuration tables

Task link table

Task nodes

Task node #2

Task node #3

Task node #4

NULL

...

Task node #1

Task #2

Task #1

...

Task #8

Task Managem ent

Task Related Resources

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 55

NON-DISCLOSURE AGREEMENT REQUIRED

counter of times of activation. That is, the content of this field increments

each time the task to be activated is in the non-suspended state, and

decrements each time the task is terminating.

4.7.4 Task Stack

4.7.4.1 Stack Allocation

During run-time, every task has its own stack. The stack is either

dynamically assigned to a task during its activation or statically allocated

for a task d uring system initialization. If a stack is alloc ated dynamically,

it is got from a

stack pool

. Several options are possible for static stack

assi gnment during system start-up.

Stack pools are used by task management to dynamically allocate stack

area for a task during task activa tion. To have stack pools in the system

the configuration option

StackPool

must be turned on. The user should

specify the desired number of stack pool with a defined number of

buffers of the required size in them. This is done with the help of the

STACK

definition statements, see Section 12 System

Configurationand Section 14 Building of Application. The stack

pool contains a queue of stacks of a fixed size. The task control block

contains the address of the stack pool contro l block, and the stack buffer

is unlinked from the pool and assigned to the task during task activation.

During task termination the stack buffer is returned to the stack pool.

The simplest method of stack allocation is to use task node stacks. Each

task in the OSEK Operating system has the stack linked with a task

node. The size of this stack is the same for all tasks. It is defined by

means of the corresponding OS property

NodeStackSize

. See

Sect ion 4.7. 5 Allocatio n of Fixed St ack Linked with the Task Nod e

for this option.

The following options are available for task stack allocation:

1. Allocation of fixed stack linked with the task node.

2. Dynamic stack allocation from the stack pool.

3. Persistent stack allocation from the stack pool.

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Re v 1.2

56 Task Management MOTOROLA

4. Explicit stack allocation.

These options may be used simultaneously in the system, but each task

must use only one of them. These options allow the user to optimize

stack usage in the application.

The use of the stack allocation options is illustrated in Figure 4-7,

Figure 4-8, Figure 4-9, Figure 4-10 and explained bel ow.

4.7.5 Allocation of Fixed Stack Linked with the Task Node

Figur e 4-7. Fixed stack linked with the task node

To allocate a task stack in this manner, the

NODESTACK

value shou ld

be assi gne d to th e StackMe t hod t ask pro pert y. Eve ry task contr ol block

in the system has an associated stack. The size of this stack is defined

by mean s of the

NodeStackSize

OS property and is the same for all task

nodes. During task activation, the system allocate s a t ask control block

and the linked stack, and uses this stack as a task stack. Because all

task control blocks have an associated stack, it is the simplest method

of stack allocation. But, in this case, all tasks will use a sta ck of the same

(fixed) size regardless of the stack space really needed for tasks. To

remove such a stack type, the system configuration option

NodeStack

should be turned off.

task node stack

Task configuration table #1 Task node #1

stack pointer

Task node stack

Task Managem ent

Task Related Resources

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 57

NON-DISCLOSURE AGREEMENT REQUIRED

4.7.5.1 Dynamic Stack Allocation f rom the Stack Pool

Figure 4- 8. Dynamic stack allocation from the stack pool

To for ce a task to use dynamic sta ck allocation, the

POOLSTACK

val ue

shoul d be assigne d to the

StackMethod

t ask propert y and the r eference

to the stack poo l. The stack pool is defi ne d separa tel y a nd it is sta ti cally

assigned to the task. Task #2 is configured to allocate a stack from the

stack pool during task activation. The task configuration table contains

the address of the stack pool, and the system allocates a stack buffer

from this pool, saving the address of the stack buffer in task node #2.

During task termination the stack buffer is returned to the stack pool

queue. The user is allowed to configure a stack pool of different sizes

and set the number of stack buffers in each to satisfy different stack

space requir ements for various tasks.

NOTE:

The user is responsible for the proper quantity of stack buffers to avoid

a possible failure of task activation if there are no stack buffers left. Also,

the increased time of task activation/termination due to stack pool

manipulations timing should be taken into consideration. This me thod

allows most efficient RAM distribution for task stacks.

4.7.5.2 Pers istent Stack Allocation from the Stack Pool

To use persistent stack allocation from the stack pool the user should set

both

PersistentNode

and

PersistentStack

task properties. The system

configuration option

PersistentStack

must be turned on. In this case, the

task stack is allocated from the stack pool during system initialization

and th e address of the stack is written in th e ta sk control block, w hich is

stack pointer

Task configuration table #2 Task node #2

stack buffer

stack pool node

Stack pool

Stack buffer

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Re v 1.2

58 Task Management MOTOROLA

persistently designated to the task too. In Figure 4-9 task #3 is

configured so that the persistent task node and a stack buffer from the

specified pool are allocated for the task at system start-up, and the

address of the allocated stack buffer is placed in the task node.

Figure 4-9. Persistent stack allocation from the stack pool

NOTE:

Persistent stack from a stack pool may be assigned only for the task with

assigned persistent task node and with assigned stack pool.

stack pointer

Task configuration table #3

Task node #3

stack buffer

task node address

stack pool node

Free task node #1

Free task node #2

Persistent task node #3

Free task node #4

Task nodes

Stack pool

Buffer

Persistent

buffer

Task Managem ent

Task Related Resources

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 59

NON-DISCLOSURE AGREEMENT REQUIRED

4.7.5.3 Explicit Stack Allocation

Figure 4-10. Static stack allocation

Persistent stack allocation is selected when the

OWNSTACK

value is

given to the

StackMethod

property in the task definition. T he system

configuration option

TaskOwnStack

must be turned on. The user must

also specify the stack size. In the figure above, task #4 has a stack

permanently assigned to the task. The user is allowed to assign one

static stack area to different tasks, if these tasks are not activated

simultaneously. But with such stack allocation there is the overhead

connected with non-used RAM areas when the task is not activated.

4.7.5.4 Stack Size

The minimal size of the task stack depends on:

• the scheduling policy (non-preemptive or preemptive task);

• the services that are used by the task;

• the interrupt and error handling policy;

• the processor type.

The r ecommend ed values of th e minimal task stack size a re provide d in

Section 15.5 Task Stack Size.

NOTE:

If the task stack is less than the minimal value for the given configuration,

it may lead to unpredictable behavior of the task and to a system crash.

Task configuration table #4

stack pointer

top of stack

Static stack Task node #4

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Re v 1.2

60 Task Management MOTOROLA

4.8 Programming Issues

4.8.1 Configuration Options

The following system config uration options affect the task man agement:

•

MultiplyActivation

The option controls the multiply activation

ability for Conformance Classes. If the

option is turned off, multiply activation is

disabled for tasks of these Conform a nce

Classes. This option may be turned on

only for BCC2, ECC2 Conformance

Classes.

•

TaskIndexMethod

If this option is turned on then the

intermediate vector of the pointers to the

tasks control blocks is used (fast and

deterministic access to task control

blocks).

•

NodeStack

This option defines the presence of task

node stacks in the system. If it is turned off

there are no task node stacks

implemented.

•

StackPool

This opt ion def ines the prese nce of stack

pools in the system. If it is turned off, there

are no stack pools implemented.

•

PersistentNode

If this option is turned on, a persistent task

control block m ay be assign ed to the task.

•

PersistentStack

If this option is turned on, a persistent

stack buffer may be assigned to the task.

•

TaskOwnStack

This option defines that a task may have

its own stack.

•

UseSameContext

If this option is turned on, the same run

time context fram e is used both for non-

preemptive and preemptive tasks in

mixed-pr eemptive systems.

Task Managem ent

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 61

NON-DISCLOSURE AGREEMENT REQUIRED

•

TaskBasePage

If thi s op tion is tu rned on, the t ask cont rol

blocks are placed into the base page

memory. It increases the system

performance, since the CPU accesses

the base page faster than extended

memory. In this case, the user is

responsible for the necessary amount of

RAM in the base page for the desired

number of task control blocks.

4.8.2 Data Types

The OSEK OS establishes the following data types for the task

management:

•

TaskType

The abstract data type for task

identification;

•

TaskRefType

The data type to refer variables of the

TaskType

data type;

•

TaskStateType

The data type for variables to store the

state of a task;

•

TaskStateRefType

The data type to refer variables of the

TaskStateType

data type.

The following data types belong to OSEK OS extension:

•TaskControlBlockType The data type for task control block

(task node);

•TaskControlBlockRefType The data type to refer variables of the

TaskControlBlockType data type.

Only these data types may be used for operations with tasks.

4.8.3 Task Definition

Each ta sk in an application is generated by means of using the

TASK

system generation statement.

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Re v 1.2

62 Task Management MOTOROLA

The task definition looks like the following:

TASK <TaskName> {

TYPE = <TaskType>;

PRIORITY = <TaskPriority>;

SCHEDULE = <TaskScheduling>;

ACTIVATION = <TaskMultiplyActivation>;

AUTOSTART = <TaskInitState>;

StackMethod = <TaskStackAssignment>;

};

The application defini tion file contains on e such state ment per task. Th e

task generation statement is described in detail in Section 12 System

Configuration.

To refer to a task, the constructional statement

DeclareTask

should be

used to declare the task before references to it.

DeclareTask

looks like the following:

DeclareTask( TaskType <TaskName> )

4.8.4 Run-t ime Services

OSEK OS grants a set of services for the user to manage tasks. A

detailed description of these services is provided in Section 17 System

Services. Here only a brief list of them is given.

1. Thi s servic e is not define d in the OSEK OS v.2.0 rev.1 speci fi cation. This is an ext ension of OSEK OS.

Table 4-4. Task Management Run-time Services

Service Name Description

ActivateTa sk Activates the task, i.e. put i t from the

suspended

in to th e

ready

state

Terminat eTask Terminates the task, i.e. put it from the

ready

into the

suspended

state

C hainTas k Terminat es the task and activates a new one immediatel y

Schedul e Yields control to a higher-priority ready task (if any exists)

GetTaskId Gets the identifier of the running task

GetTaskState Gets the status of the specified task

GetTCBInfo(1) Copies conten ts of the runn ing task control block

by the address specified

Task Managem ent

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Task Management 63

NON-DISCLOSURE AGREEMENT REQUIRED

Examples of using the run-time services are provided in

Section 17.3.12 Examples for Task Management Services.

4.8.5 Constants

The fol lowing constants are use d wi th in th e O SEK Ope rating System to

indicate task states:

•

RUNNING

Constant of data type

TaskStateType

for task

state

running

•

WAITING

Constant of data type

TaskStateType

for task

state

waiting

•

READY

Constant of data type

TaskStateType

for task

state

ready

•

SUSPENDED

Constant of data type

TaskStateType

for task

state

suspended

These constants can be used for variables of the

TaskStateType

The following constant is used within the OSEK OS to indicate task:

•

INVALID_TASK

Constant of data type

Task Type

for an

undefined task

4.8.6 Conventions

Within the OSEK OS application a task should be defined according to

the following pattern:

TASK ( TaskName )

{

...

}

The name of the task function will be generated from

TaskName

macro

TASK

NON-DISCLOSURE AGREEMENT REQUIRED

Task Management

User’s Manual OSEK Opera ting System — Re v 1.2

64 Task Management MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Scheduler 65
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 5. Schedu ler
5.1 Contents
5.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
5.3 Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
5.4 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
5.2 General
The algorithm deciding which task has to be started and triggering all 
necessary OSEK Operating System internal activities is called scheduler. 
It performs all actions to switch the CPU from one instruction thread to 
another. It is either switching from task to task or from ISR back to a task. 
The task exe cuti on sequ ence is contr olled on th e base of task pr iori ties 
(see section Section 4.6 Task Prioritie s) and the scheduling policy 
used. 
The scheduler is activated whenever a task switch is possible according 
to the scheduling policy. The principle of multitasking allows the 
operating system to execute various tasks concurrently. The sequence 
of their execution depends on the scheduling policy, therefore it has to 
be clearly defined.
Sched uler als o provides the  endless id le loop if  there is no ta sk ready to 
be runn in g. It may occur, when all tasks are  in the 
suspended
 or 
waiting
 
state until the awakening signal from an Interrupt Service Routine 
occ urs. In this case there is no curr ently running ta sk in the system, and 
the sched ul er  occupies  the p rocesso r pe rfor ming a n en dl ess loop  whi le 
the ISR awaits a task to be exe cuted. It is possible to call a special user’s 
hook from the scheduler idle loop. This property is turned on via the 
system configuration option 
IdleLoopHook
. If it is supported by 
hardware, the scheduler’s idle loop may be replaced by an instruction 

NON-DISCLOSURE AGREEMENT REQUIRED

Scheduler

User’s Manual OSEK Opera ting System — Re v 1.2

66 Scheduler MOTOROLA

that puts the CPU in low power mode to reduce power consumption. This

property is turned on via the system configuration option

HCLowPower

The scheduler has its own small stack (the

scheduler’s stack

) which is

needed for the endless idle loop. T he stack size is specified by the user ,

see section Section 13.3.1 Global System Attributes. The system

property

UseMainStack

can be specified by the user. In this case, the

same stack is used by the main() function, by the scheduler and by ISRs.

This o ption saves RAM con sumptio n, b ut th e u ser is responsi ble for th e

required memory amount for the stack.

The scheduler can be treated as a specific resource that can be

occupied by any task. See Section 7.3.2 Scheduler as a Resource for

details.

The scheduling policy and some scheduler-related parameters are

defined by the user, see Section 13.3.1 Global System Attributes and

Section 13.3.2 Task Related Attributes.

5.2.1 Simple Sc he duler

If each task in the application has an unique priority, the simplified

scheduler may be used to reduce memory and time consumption. In this

case, the scheduler uses a table of tasks instead of queues. This system

property can be turned on via the system configuration option

SimpleScheduler

. By default this option is turned off.

The option does not depend on Conformance Classes so it is possible

to use this system property in ECC2 as well as in BCC1, but unique task

priorities are required (one task per priority).

The simplified scheduler cannot be used with resource management

and task multiply activation. Therefore, if the

SimpleScheduler

and the

Resources

MultiplyActivation

options are both turned ON in the

system configuration file, then

SimpleScheduler

is ignored by the

System Generator, and an error message is produced (see

Section 12 System Conf iguration).

Scheduler

Schedul ing Policy

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Scheduler 67

NON-DISCLOSURE AGREEMENT REQUIRED

5.3 Scheduling Policy

The scheduling policy being used determines whether execution of a

task may be interrupted by other tasks or not. In this context, a distinction

is made between full-, non- and mixed-preemptive scheduling policies.

The scheduling policy affects the system performance and memory

resour ces. In the OSEK Ope rating System, all listed schedu lin g policies

are supported, but in the case of the mixed-preemptive policy, each task

in a n app lication ma y use only one of the thr ee po licie s. It is defi n ed via

the appropriate task property (preemptive/non-preemptive).

Note that the interruptibility of the system depends neither on the

Conformance Class, nor on the task type.

The desired scheduling policy is defined by the user via the system

configuration option

SCHEDULE

. The valid values are –

NON, FULL,

MIXED

5.3.1 Non -preemptive Scheduling

The sched uli ng policy i s conside red as n on-p reem ptive, if a task sw itch

is only performed via one of a selection of explicitly defined system

services (explicit point of rescheduling).

Non-preemptive scheduling imposes particular constraints on the

possible timing r e quirements of tasks. Specifically, the lower priority

non-preemptive section of a running task delays the start of a task with

hig her priority, up to the next poi nt of reschedu lin g. The time diagram o f

the task execution sequence for this policy looks like the following:

NON-DISCLOSURE AGREEMENT REQUIRED

Scheduler

User’s Manual OSEK Opera ting System — Re v 1.2

68 Scheduler MOTOROLA

Figur e 5-1. Non-preemptive scheduling

Task T2 has lower priority than task T1. Therefore, it delays task T1 up

the point of rescheduling (in this case termination of task T2).

The following points of rescheduling exist in the OSEK Operating

System:

• Successful termination of a task (via the

TerminateTask

system

service);

• Successful termination of a task with explicit activation of a

successor task (via the

ChainTask

system service);

• Explicit call of the scheduler (via the

Schedule

system service);

• Explicit wait call, if a transition into the waiting state takes place

(via the

WaitEvent

system service, Extended Tasks only).

In the non-preemptive system, all tasks are non-preemptive and the task

switching will take place exactly in the listed cases.

5.3.2 Full-pr eem ptive Sc heduling

Full-preemptive scheduling means that a task which is presently

running

may be rescheduled at any instruction by the occurrence of trigger

conditions pr eset by the operating system. Full-preemptive scheduling

will put the

running

task into the

ready

state as so on as a higher- prio rity

task has got

ready

. The task context is saved so that the preempted task

can be continued at the location where it was interrupted.

readysuspended running

Task T1

latency time

for task T1

activation of task T1

running suspended

Task T2

terminaton of task T2

Scheduler

Schedul ing Policy

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Scheduler 69

NON-DISCLOSURE AGREEMENT REQUIRED

With full-preemptive scheduling, the latency time is independent of the

run time of lower priority tasks. Certain restrictions are related to the

increased RAM space required for saving the context, and the enhanced

complexity o f features necessary fo r synchroniza tion between tasks. As

each task can theoretically be rescheduled at any location, access to

data that are used jointly with other tasks must be synchronized.

In a full-preemptive system all tasks are preemptive.

Figure 5-2. Full-preemptive scheduling

5.3.3 Mixed-preemptive Scheduling

If full-preemptive and non-preemptive scheduling principles are to be

used for execution of different tasks on the same system, the resulting

policy is called “mixed-preemptive” scheduling. The distinction is made

via the task property (preemptive/non-preemptive).

The definition of a non-preemptive task makes sense in a full-preemptive

operating system in the following cases:

• if the execution time of the task is in the same magnitude of the

time of a task switch,

• if RAM is to b e u sed econom ical ly to pr ovide space for saving the

task context,

• if the task must not be preempted.

Many applications comprise only a few parallel tasks with a long

execution time, for which a full-preemptive oper ating system would be

convenient, and many short tasks with a defined execution time where

running

suspended running

Task T1

activation of task T1

readyrunning

Task T2

terminaton of task T2

suspended

terminaton of task T1

NON-DISCLOSURE AGREEMENT REQUIRED

Scheduler

User’s Manual OSEK Opera ting System — Re v 1.2

70 Scheduler MOTOROLA

non-preemptive scheduling would be more efficient. For this

configuration, the mixed-preemptive scheduling policy was developed

as a compromise.

NOTE:

Tasks can be ported between preemptive, non-preemptive and mixed-

preemptive OSEK applications if they do not have any assumption of

non-preemptability. That mea ns that critical data must be protected

using resources and communication must be done using messages.

5.4 Programming Issues

5.4.1 Configuration Options

The following system configuration options are intended to define

scheduler properties:

•

SimpleScheduler

If this option is turned on, the simplified

scheduler will be used in the system if each

task has a unique priority. It reduces the OS

code and incr eases system performance.

•

SCHEDULE

This option defines which scheduling policy,

non-preemptive, full-preemptive or mixed-

preemptive, will be used in the application .

•

UseMainStack

If this option is turned on, the same stack area

is used for the main() funct ion ( dur ing start- up),

for the scheduler stack and for the ISR stack.

•

IdleLoopHook

If this option is turned on, then user supplied

hook will be called from the schedu ler idle loop.

•

HCLowPower

If this option is turned on, an instruction that

puts the CPU in low power mode is used

instead of the scheduler’s idle loop.

Scheduler

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Scheduler 71

NON-DISCLOSURE AGREEMENT REQUIRED

5.4.2 Run-t ime Services

The scheduler is not accessed by the user directly. The user can only

pass the CPU control to the scheduler by means of the

Schedule

system

service. This leads to task rescheduling.

The scheduler can be used by the programmer as a resource (in all

Conformance Classes). To provide this possibility, the services

GetResource

and

ReleaseResource

with the constant

RES_SCHEDULER

as a parameter can be called by a task. It means

that the task cannot be preempted by any othe r task a fter the scheduler

occupation, before the corresponding call

ReleaseScheduler

performed. While the task occupies the scheduler, it has the highest

priority and, therefore, cannot be interrupted by other tasks (only ISRs

can get t he CP U control dur ing this p eriod). S uch progr amming pr actice

can be used for important critical sections of code.

See the example:

GetResource( RES_SCHEDULER );

...

/* Critical section - this code cannot be interrupted by any other task */

...

ReleaseResource( RES_SCHEDULER ); /* End of the critical section */

5.4.3 Scheduler Definition

The scheduler parameters must be defined by the user in the

configuration file by setting the corresponding OS attri butes.

Defin ition of schedu ler related system propertie s looks like the following:

OS <name> {

.....

SCHEDULE = MIXED;

NodeNumber = <NumberOfTasks>;

SchedStackSize = <SchedulerStackSize>;

MaxPrio = <NumberOfPriorities>;

NodeStackSize = <TaskNodeStackSize>;

.....

};

The OS generation statement is described in detail in

Section 12 System Conf iguration.

NON-DISCLOSURE AGREEMENT REQUIRED

Scheduler

User’s Manual OSEK Opera ting System — Re v 1.2

72 Scheduler MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Interrupt Processing 73
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 6. Interrupt Processing
6.1 Contents
6.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
6.3 ISR Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
6.4 ISR Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
6.5 Interrupt Flag Manipulation. . . . . . . . . . . . . . . . . . . . . . . . . . . .77
6.6 Local Variables Considerations . . . . . . . . . . . . . . . . . . . . . . . .78
6.7 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
6.2 General
Interrupt processing is an important part of any real-time operating 
system. An Interrupt Service Routine (ISR) is a routine which is invoked 
from  an inte rrupt sou rce, such as  a timer or  an exter nal ha rdware eve nt. 
ISRs have  higher priori ty than all tasks and the  scheduler. Addr esses of 
ISRs should be pointed to in the vector table.
In OSEK OS, all IS Rs should use the  se parate stack (ISR stack) which  is 
used only by ISRs during their executi on. The size of the ISR stack is 
defined by the user. At the beginning of an Interrupt Service Routine, the 
user should switch to this stack using the system service 
EnterISR
. After 
the ISR completion, the corresponding service 
LeaveISR
 should be 
performed to switch back to the previous stack. The instruction 
sequence between the 
EnterISR
 and 
LeaveISR
 calls is considered as 
ISR frame. 
When interrupt occurs, either current stack can be used or the ISR stack. 
The current stack is:
• the stack of the interrupted task,

NON-DISCLOSURE AGREEMENT REQUIRED

Interrup t Processing

User’s Manual OSEK Opera ting System — Re v 1.2

74 Interrupt Processing MOTOROLA

• the scheduler’s stack if an interrupt occurred during scheduler

execution,

• ISR stack in case of nested interrupts.

OSEK OS supports nested interrupts, theoretically up to 255 levels1. A

special syst em counter tracks the number of nested interrupts. Since the

OS provides the means to switch the stack and to control the interrupt

mask, such nested interrupts, if written correctly, could be treated as a

single one. To not waste a task stack space for nested interrupts or

complicated ISR, the ISR stack is used.

OS also co ntrols the state of an interr upt mask. Th e user define s values

of the interrupt masks for disabling and enabling all interrupts, and the

default interrupt mask for task execution. See Section 13.3.3 Interrupt

Re lated Proper ties for details.

ISRs can communicate with tasks in the OSEK OS by the following

means:

• ISR can activate a task;

• ISR can send an unqueued or a queued message to a task;

• ISR can trigger a counter;

• ISR can get state of the task;

• ISR can set event for a task;

• ISR can get event mask of the task;

• ISR can manipulate alarms;

• ISR can get active application mode.

Interr upts cannot use any OS service s exce pt those which are special ly

allowed to be used within ISRs. When using other services, the system

behavior will be unpredictable. In the Extended (debugging) status of the

Operating System, the error will be reported in such a case. See

1. If

PreTaskHook

PostTaskHook

user’s hook s are used (see Section 11.3 Hook Routines)

and

GetTaskId

direc tive is support ed (s ee Section 17.3.9 GetTaskId) then OSEK OS s upport s

up to 127 levels of nes ted int errupts.

Interrupt Processing

ISR St a c k

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Interrupt Processing 75

NON-DISCLOSURE AGREEMENT REQUIRED

Section 6-1 Interrupt Management Serv ices in the OSEK OS and

Section 17 System Services for details.

6.3 ISR Stack

The purpose of the ISR stack is to save memory. Since interrupts can be

nested, it means, that every task stack must be big enough to store

several interrupt stack frames (in addition to task needs for local

vari ables, function call s, etc.). To avoid this overhea d, the separate ISR

stack is used in the OS EK Operating System. Switch ing to this stack is

performed by the

EnterISR

servi ce at th e beginning of IS R. This stack is

used only by ISRs, and if nested interrupts occur after the stack has

been switched, they will use this stack too. Before leaving the ISR,

switching back to the interrupted task stack must be achieved by means

LeaveISR

The interrupt stack fram e usually consists of the CPU registers, and

optionally some compiler-dependent ‘virtual’ registers. The CPU

regi sters are pushe d onto the st ack under ha rdwar e or software cont rol.

In the latter case the compiler generates a stack frame by means of

adding special sequences of machine instructions before the first

statement in the function.

Most co mpi ler s use fun ction m odi fier s ( like ‘ inter rupt’ ) t o ge nera te st ack

frames. In turn, the

ISR

keyword, specified in OSEK (see

Section 6.7.4 Conventions), is a macro for this modifier.

6.4 ISR Categories

In the OSEK Operating System three types of Interrupt Service Routines

are considered.

6.4.1 ISR Cate gory 1

ISRs of this type do not use any operating system service. These ISRs

do not use OS services

EnterISR

and

LeaveISR

, consequentl y, ISRs of

these type are executed on the current stack. In this case, if the ISR uses

NON-DISCLOSURE AGREEMENT REQUIRED

Interrup t Processing

User’s Manual OSEK Opera ting System — Re v 1.2

76 Interrupt Processing MOTOROLA

the stack space for its execution, the user is responsible for the

appropriate stack size. Moreover, if interrupts are re-enabled inside the

ISR, nested interrupts are possible, which will use the same task stack.

The gener al recomm enda ti on for ISRs catego ry 1 may be the following:

RULE:

ISR category 1 cannot use any OS services. These ISRs must disable

interrupts internally (at the beginning of the routine).

After the ISR is fin ished, pr ocessing con tinues exactly at the instruction

where the interrupt occurred, i.e. the interrupt has no influence on task

management.

ISR( ISR_handler )

{

...

/* the code without any OS service calls */

...

}

6.4.2 ISR Cate gory 2

In ISR category 2, the OSEK Operating System provides an automatic

EnterISR

call at the very beginning to switch to the ISR stack and save

the i nitial i n terr upt m ask. After tha t, an y user ’s rou t ine can be execute d,

including allowed OS calls (to activate a task, send a message or trigger

a counter). See Section 6.7.3 Run-time Services for the list of

services allowed for ISR. At the end of the ISR, the System automatically

executes

LeaveISR

servi ce to switch b ack to the ta sk stack and restore

the interrupt mask.

ISR( ISR_handler )

{

/* OS internal EnterISR() call */

...

/* the code with allowed OS calls */

...

/* OS internal LeaveISR() call */

}

Inside the ISR, no rescheduling will take place. Rescheduling m a y only

take place on term ination of the ISR if a preemptive task has been

interrupted.

Interrupt Processing

Interrupt Flag Manipul ation

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Interrupt Processing 77

NON-DISCLOSURE AGREEMENT REQUIRED

6.4.3 ISR Cate gory 3

In IS R categ ory 3 , the OS EK Ope rating S ystem provide s the IS R fram e

to execute more complicated user code. The ISR frame is instructions

betw een OS servi ces

EnterISR

and

LeaveISR

. Such ISRs ar e similar to

those of category 2, but the location of the ISR frame in the code

segment is application dependent and user defined. The code outside

the IS R frame can b e used, e.g., to access global variables or h ardware

registers. The user is responsible for operations outside the ISR frame,

since they could un properly modify stack fra me (see Section 6.6 Local

Variables Considerations), and interrupts may be enabled (see

Section 6.4.1 ISR Category 1). No OS service calls can be executed

outside the ISR frame.

ISR( ISR_handler )

{

/* user’s code */

...

EnterISR();

/* the code with allowed OS calls */

...

LeaveISR();

}

To avoid possible errors the following rule for ISR category 3 is

recommended:

RULE:

In ISR categor y 3, all opera tions using OS service s and/or wi th enabled

interrupts must be performed only inside the IS R frame.

The OSEK Operating System has no means to di stinguish ISR

categories 2 and 3 at run-time. Therefore, such distinction should be

made by the user at the stage of source code writing.

6.5 Interrupt Flag Manipulation

OSEK OS provides services to control the interrupt flag – to disable or

enabl e interr upts and get the curren t stat e of the interrupt mask. The se

services are implemented to allow the user to control interrupts of

several interrupt levels (for instance, Motorola MC68HC16 MCU has 8

interrupt levels). In this case, it is possible to set the desired interrupt

NON-DISCLOSURE AGREEMENT REQUIRED

Interrup t Processing

User’s Manual OSEK Opera ting System — Re v 1.2

78 Interrupt Processing MOTOROLA

mask which disables some interrupts and enables other ones. In the

interru pt de finition sta teme nt, th e user shou ld select interrupt masks for

all inter rup ts disabled, al l interr upts ena bled and som e desired medium

state (by default a task gets this interrupt mask when it is activated if it

does not have its own starting interrupt mask specified). The special

data type is defined within the OSEK Operating System to control

interrupt masks. The set of special OS attributes is introduced to

configure interrupt masks.

6.6 Local Variables Considerations

There are some peculiarities related to using local variables inside ISR

category 3. The follow ing considerations cover this subject.

The

EnterISR

and

LeaveISR

functions assume that the stack frame is

defined on entry. Moreover, the stack pointer may be changed during the

exec ution of these functions. Thus, the use of local variable s inside ISR

category 3 may lead to unpredictable behavior and a crash. Therefore,

the user is not permitted to use local variables inside ISR category 3.

Instead, the user may split the interrupt service routine into two

functions. The nested function should perform useful work, and may

have local variables. The outermost function should call the nested

function framed by the calls to

EnterISR

and

LeaveISR

services.

The exam ple of correct code:

int __SciHandler(void)

{ /* The inner function with local variables */

char status; /* local variable to hold SCI status*/

int num; /* local variable to byte counter*/

... /* useful user’s code*/

}

ISR( SciHandler ) /* Interrupt service routine*/

{ /* No local variables defined*/

EnterISR(); /* Switch to the ISR stack */

__SciHandler(); /* Perform useful work to handle interrupt*/

LeaveISR();

}

Interrupt Processing

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Interrupt Processing 79

NON-DISCLOSURE AGREEMENT REQUIRED

The exam ple of the wrong code – local variables are allocated on the

task stack, but the stack po inter is chang ed by

EnterISR

after , t here fore

references to the variables are invalid:

int __SciHandler(void)

{ /* The inner function without local variables */

... /* useful user’s code*/

}

ISR( SciHandler ) /* Interrupt service routine*/

{

char status; /* local variable to hold SCI status*/

int num; /* local variable to byte counter*/

EnterISR(); /* Stack Pointer is changed ! */

num = __SciHandler();/* Perform useful work to handle

interrupt*/

LeaveISR();

}

6.7 Programming Issues

6.7.1 Configuration Options

The following system configuration options affect the interrupt

management:

•EntryExitISR if the option is turned off, it is assumed

that there are no interrupts in the system

at all and the Opera ting Syste m does not

have any interrupt h andling m echanisms.

No interrupt management services are

implemented.

•InterruptMaskControl if the option is turned off (while the

EntryExitISR option is turned on),

interrupt masks are not controlled by the

operating system. Services

EnableInterrupt, DisableInterrupt,

GetInterruptDescriptor are not

implemented.

NON-DISCLOSURE AGREEMENT REQUIRED

Interrup t Processing

User’s Manual OSEK Opera ting System — Re v 1.2

80 Interrupt Processing MOTOROLA

•ISRCategory1 if the option is turned off, it is assumed

that there are no interrupts of category 1

in the system.

•ISRCategory2 if the option is turned off, it is assumed

that there are no interrupts of category 2

in the system.

•ISRCategory3 if the option is turned off, it is assumed

that there are no interrupts of category 3

in the system.

•UnorderedExceptionsif the option is turned on, it is possible to

handle unordered exceptions. This

attribute is intended for MPC only.

6.7.2 Data Types

The OSEK OS establishes the following data types for the task

management:

•IntDescriptorType The data type for logical interrupt

descriptors;

•IntDescriptorRefType The data type to refer variables of the

IntDescriptorType

data type.

The only data types must be used for operations with interrupt masks.

6.7.3 Run-t ime Services

OSEK OS provides the set of services for interrupt management. Also

some servic es may be used both on the task level and on the ISR level .

These services are shown in the Section 6-1 Interrupt Management

Services in the OSEK OS.

Interrupt Processing

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Interrupt Processing 81

NON-DISCLOSURE AGREEMENT REQUIRED

6.7.4 Conventions

Within the application, an Interrupt Service Routine category should be

defined according to the following pattern:

ISR( ISRName )

{

...

Table 6-1. Interrupt Management Services in the OSEK OS

Service Name Description

Interrupt Managem ent Services

EnterISR Registers the switching to the interrupt level and switch context to

the ISR stack

LeaveISR Registers the leaving of the ISR level

EnableInterrupt Enables interrupts in accordance with the given logical interrupt

descriptor

DisableInterrupt Disables interrupts in accordance with the given logical inte rrupt

descriptor

GetInterruptDescriptor Returns the current state of interrupts

Services allowed for use in ISR

Activate Task Activate s the specified task (puts it into the

ready

state)

Get TaskS tate Get s state of the task

SetE vent Sets even t for the t ask

Get Event Get s event of the task

SendMessage Send s an unqu eued me ssag e in

W ithCopy

configuration to the

specif ied task

ReceiveMessage Deli vers data of an unqueued message in

WithCopy

configuration to

the appl ication message c opy

GetMessageStatus Returns the current status of the mess age

Get AlarmBase Get s alarm base characteristics

SetRelAlarm Sets relative alarm

SetAbsAlarm Sets absolute alarm

CancelAlarm Cancels alarm

Get Alarm Gets value in ticks before the alarm expires

Counte rTrigge r Increm ents a counter value

Get ActiveA pplication Mod e Gets current application mo de

NON-DISCLOSURE AGREEMENT REQUIRED

Interrup t Processing

User’s Manual OSEK Opera ting System — Re v 1.2

82 Interrupt Processing MOTOROLA

}

The keyword

ISR

is the macro for compiler specific interrupt function

modifier, which is used to generate valid code to enter and exit ISR.

If the Interrupt Service Routine is defined by means of keyword

ISR

usage, then it should be declared according to the following pattern:

DeclareISR( ISRName )

The same name shall be used for corresponding ISR object definition

(see Section 13.11 ISR Definition).

6.7.5 ISR Definition

To define common ISR parame ters like ISR stack size and predefined

interru pt m asks the corr espon ding OS pr oper ties sh ould be specified in

the configuration file.

Definition of Interrupt related properties looks like:

OS <name> {

.....

IsrStackSize = <ISRStackSize>;

DisableInterruptMask = <DisableMask>;

EnableInterruptMask = <EnableMask>;

InitialMask = <InitialMask>;

TaskLevelMask = <TaskMask>;

.....

};

Definition of specific ISR object looks like:

ISR <ISRName>{

.....

CATEGORY = 2;

.....

};

See Section 13.3. 3 Interrupt Re la ted Proper ties and

Section 13.11 ISR Definition for the details.

Interrupt Processing

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Interrupt Processing 83

NON-DISCLOSURE AGREEMENT REQUIRED

6.7.6 Constants

For initial interrupt mask the special constant is provided by the

operating system:

•

INITIAL_INTERRUPT_DESCRIPTOR

– the interr upt level to be

used during system startup, after user’s

StartupHook

and before

the first user task is running (see Section 11.5 Start-up

Routine). It is the same as

InitialMask

value.

NON-DISCLOSURE AGREEMENT REQUIRED

Interrup t Processing

User’s Manual OSEK Opera ting System — Re v 1.2

84 Interrupt Processing MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Resourc e Management 85
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 7. Resource Management
7.1 Contents
7.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
7.3 Access to Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
7.4 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
7.2 General
The resource management is used to coordinate concurrent accesses of 
several tasks to shared resources, e.g. management entities 
(scheduler), program sequences (critical sections), memory or hardware 
areas. In general, the resource management is provided in all 
Conformance Classes, but it is fully supported only beginning from the 
BCC2
 Conformance Class. In the lower Conformance Classes only the 
scheduler  is tr eated  as th e specific system resou rce wh ich can  be u sed 
by tasks. 
Resource management ensures that
• two tasks cannot occupy the same r esource at the same time,
• priority inversion cannot arise while resources are used,
• deadlocks do  not occur by use of these resources,
• access to re sources never results in a 
waiting
 state.
The functionality of resource management is only required in the 
following cases:
• full-preemptive tasks,

NON-DISCLOSURE AGREEMENT REQUIRED

Resource Management

User’s Manual OSEK Opera ting System — Re v 1.2

86 Resource Management MOTOROLA

• non-preemptive scheduling, if resources are also to remain

occupied beyond a scheduling point (except the scheduler

resource);

• non-preemptive scheduling, if the user intends to have the

application code executed under other scheduling policies too.

Resources cannot be occupied by more than one task at a time. The

resource that is now occupied by a task must be released before other

tasks can get it. The OSEK operating system ensures that tasks are only

transferr ed from the

ready

state into the

running

state if all resources

which might be occupied by that task during its execution have been

released. Consequently, no situation occurs in which a task tries to

access an occupied resource. The special mechanism is used by the

OSEK Operating System to provide such behavior, see

Section 7.3.1 Priority Ceiling Protocol for details.

The

waiting

state is not admissible fo r Extende d Tasks wh ile a resource

is occupied. It means that the task occupying a resource is not allowed

to call the

WaitEvent

service.

In case of multiple resource occupation, the task must request and

release resources following the LIFO principle (stack). For example, if

the task needs to get the communication hardware and then the

scheduler to avoid possible preempts, the fol lowing code may be used:

GetResource( SCI_res ); /* occupy the SCI resource */

... /* user’s code */

GetResource( RES_SCHEDULER ); /* occupy the scheduler resource */

... /* user’s code */

ReleaseResource( RES_SCHEDULER ); /* release the scheduler */

ReleaseResource( SCI_res ); /* release the SCI resource */

OSEK OS resource management allows the user to prevent such

situations as priority inversion and deadlocks which are the typical

problems of common synchronization mechanisms in real-time

appl icati ons (e.g. , semaphor es).

Resource Managem ent

Access to Resources

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Resourc e Management 87

NON-DISCLOSURE AGREEMENT REQUIRED

7.3 Access to Resources

Before they are used, resources must be defined by the user at the

system configuration stage via the

RESOURCE

definition, see

Section 13.6 Resource Definition. Then the resource is declared in

the source file, where it will be used by means of a system declaration

statement

DeclareResource

(see Sectio n 17.5 Resource

Managem ent Services). After that, the task can occupy and release the

resour ce using the

GetResource

and

ReleaseResource

services. While

the resou rce i s occupied , i.e., w hile the cod e between these ser v ices is

executed, this resource cannot be requested by another task.

In the OSEK Operating System, resources are ranked by priority. Each

resource is assigned statically to a user defined priority, which is called

Ceiling Priority

. It is possible to have resources with the same

priorities, but the re source Ceiling Priority must be identical to or higher

than the h ighest task pri ority with access to th is r esource. This resou rce

feature supports the

Priority Ceiling Protocol

7.3.1 Priority Ceiling Protocol

The Priority Ceiling Protocol is implemented in the OSEK Operating

System as a resource management discipline.

The prio rity ceiling pro tocol elevate s th e task requesting a re source to a

priority level. This priority can simply be calculated during system

generation. As shown in Section 7.2 General the Ceiling Priority is:

• Identical to or higher than the highest task priority with access to

this resource (task T1 );

• Lower than all other tasks of higher priority than task T1 .

When a task occupies a resource, the system temporarily changes its

priority. It is automatically set to the Ceiling Priority by the resource

management. Any other task which might occupy the same resource

does not enter the

running

state due to its lower or equal priority. If the

resource occupied by the task is released, the task returns to its former

priority level. Other tasks which might occupy this resource can now

enter the

running

state.

NON-DISCLOSURE AGREEMENT REQUIRED

Resource Management

User’s Manual OSEK Opera ting System — Re v 1.2

88 Resource Management MOTOROLA

The exam ple shown in Figure 7-1 illustrates the mechanism of the

Priority Ceiling Protocol.

Figure 7-1. Priority Ceiling Protocol

In the figure above, Task 1 has the highest priority and Task 4 has the

lowest Priority. The resource has a priority greater than or equal to the

Task 1 p riority. Wh en Task 4 occupi es the resou rce, it gets a p riority not

less than Task 1, theref ore it cannot be preempt ed by

ready

Task 1 until

it releases the resource. Just after the resource is released, Task 4 is

retur ned to its lo w priority and b ecomes

ready

, and Task 1 b ecomes the

running

task. When Task 1, in its turn, occu pies the re source, its priority

is also changed to the Ceiling Priority.

7.3.2 Sc heduler as a Resource

The OS EK operating syste m treats th e scheduler a s a specific resou rce

which is a ccessible to all tasks. Therefo re, a standar d resource with the

predefined identifier

RES_SCHEDULER

is generated, and it is

supported in all Conformance Classes. If a task calls the services

GetResource

ReleaseResource

with this identifier as a parameter,

the task will occupy or release the scheduler in the manner of a simple

resource. See the code example in Section 7.2 General.

Ceiling

priority release

resource

suspended ready running

running running

running

suspended

running

release

resource

ready

running

suspended

request resource request resource

Resource Managem ent

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Resourc e Management 89

NON-DISCLOSURE AGREEMENT REQUIRED

If a task wants to protect itself against preemptions by all other tasks, it

can occupy the scheduler exclusively. When it is occupied, interrupts are

received and processed normally. However, it prevents the rescheduling

of tasks.

NOTE:

If a non-preemptive task gets the scheduler as a resource it must release

it before the point of rescheduling!

NOTE:

If task got t he scheduler and tri e s to yield C PU vi a th e Sc he dule service

then Schedule service returns immediately without doing anything.

7.4 Programming Issues

7.4.1 Configuration Options

The following system configuration options control the resource

management in the OSEK OS:

•

Resources

this option defines wh ether resource

management is provided by the OS or not.

•

FastResource

the option can be specified by the user to

increase the system performance. If it is turned

on, the system will work faster. But this option

may be used only for debugged applications,

because e rrors related to incorr ect access and

pri ority are not signa lle d. If this option is t urne d

on, less ROM and RAM ar e needed for

resources. But, if resource priorities have a

large difference (e.g. first resource has priority

1 and the seco nd resource has prior ity 20) this

option does not lead to RAM saving.

•

ResourceAccessCheck

the option defines whether E_OS_ACCESS

error code is returned by

GetResource

service

or not. If it is TRUE, then error code will be

returned in EXTENDED status based on task

definition in OIL-file. If the system has

NON-DISCLOSURE AGREEMENT REQUIRED

Resource Management

User’s Manual OSEK Opera ting System — Re v 1.2

90 Resource Management MOTOROLA

STANDARD status or FastResource option

turned on or more than 8 resources (including

Sched ul er) are defined in appl ica t ion, the n this

option should be set to FALSE.

7.4.2 Data Types

The OSEK OS establishes the following data type for the resource

management:

•

ResourceType

the abstract data type for referencing a

resource;

The only data type must be used for operations with resources.

7.4.3 Run-t ime Services

OSEK OS grants a set of services for the user to manage resources.

Detailed descriptions of these services are provided in

Section 17.5 Resource Management Services. Here only a brief list

of them is given.

7.4.4 Resource Definition

E_OS_ACCESS

error code is not returned by

GetResource

service if more than 8 resources (including

RES_SCHEDULER

) are defined in the application or

FastResource

configuration option is turned on or

Re-

sourceAccessCheck

configurati on option is turned off.

To define a resource, the following definition statement should be

specified in the generation file:

RESOURCE <ResourceID> {

PRIORITY = <ResourcePriority>;

};

Service Name Description

GetResource(1) This call serves to occupy the resource (critical section of the code, assigned

to the resource)

ReleaseResource Releases the resource assigned to the critical section (to leave the critical

section)

Resource Managem ent

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Resourc e Management 91

NON-DISCLOSURE AGREEMENT REQUIRED

For more details see Section 13.6 Resource Definition.

To refer to a resource, the declaration statement

DeclareResource

should be used to declare the resource before its use.

DeclareResource

looks like the following:

DeclareResource( ResourceType <ResourceID> )

This declaration is equivalent to the external declaration of variables.

NON-DISCLOSURE AGREEMENT REQUIRED

Resource Management

User’s Manual OSEK Opera ting System — Re v 1.2

92 Resource Management MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Counters and Alarms 93
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 8. Counters and Alarms
8.1 Contents
8.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
8.3 Counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
8.4 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
8.5 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
8.2 General
The OSEK ope rating system comprises a two level concept to make use 
of recurring events like periodic interrupt of timers, interrupt of the 
sensors on rotating angles, or any recurring software events. To manage 
such a situation, counters and alarms are provided by the OSEK 
Operati n g System . T he  recur ring  even ts ( source s) ca n b e r egister ed  by 
counter s. Based  on co unters, t he OSEK OS  offer s an a larm  mechani sm 
to the application software. Counters and alarms are provided by the 
OSEK OS in all Conformance Classes. Counter concept and counter 
management system services are based in the ‘OSEK Operating 
System, Concept’ v. 1.00, September 1995 and ‘OSEK Operating 
System, Application Program Interface’ v. 1.00, September 1995.

NON-DISCLOSURE AGREEMENT REQUIRED

Counters and Alarms

User’s Manual OSEK Opera ting System — Re v 1.2

94 Counters and Alarms MO TORO LA

F igure 8-1. Counters and alarms

8.3 Counters

Any event in the system can be linked with a counter, so that when the

event has occurred, the counter value is changed. A counter is identified

in the system via its symbolic name, which is assigned to the counter

statically at the configuration stage.

A counter is represented by a current counter value and some counter

specific parameters:

counter initial value

conversion

constant

and maximum

allowed counter value

. They are

defined by the user. The latter two parameters are constants and they

are defined at system generation time. The counter initial value is the

dynamic parameter. The user can initialize the counter with this value

and thereafter on task or on interrupt level advance it using the system

service

CounterTrigger

The ma ximum allowed counter value specifies the number after which

the counter rolls over. When a counter reaches its maximum allowed

possible value (or rolls over the predefined size - byte etc.), it starts

counting again from zero.

NOTE:

The maximum allowed counter value is never really reached by a

counter. It means that if, for instance, value 5 is specified as the

maximum al lowed one, 5 can never be r ead a s a cur ren t coun ter va l ue.

source

counter

source source source

counter counter counter

alarm alarm alarm alarm alarm alarm

TaskTask

1:1 n:1 1:n

ActivateTask SetEvent

Counters and Alarms

Counters

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Counters and Alarms 95

NON-DISCLOSURE AGREEMENT REQUIRED

If an alarm should be set for value 5, the maximum allowed counter value

must be 6.

The user also defines the ma xim a l size of all counters in the system -

they can be byte-, word- or longword-sized. This is defined via the

system properties

CounterSize

The conversion constant can be used to convert the counter value into

an appropriate user specific unit of measuremen t, e.g. seconds for

timers, angular degrees for rotating axles. The conversion is done by the

user’s code and this parameter can be treated as a counter-specific

reference value.

The oper ating system provides the standard service

GetCounterInfo

read these cou nter spe cific value s. Also the servi ce

GetCounterValue

designed to read the current counter value.

At least one counter always exists in the system. This counter is used as

system timer

(the internal system clock). The system timer is a

standard counter with the following additions:

• the user must always define the system timer in an application;

• special constants are defined to describe counter paramete rs and

to decrease access time;

• the user defines the source of hardware interrupts for the system

counter.

In the system definition statement for the system timer the user should

define one of possible hardware interrupt sources. Parameters to tune

the hardware can be also defined by the user in this statement. This

possibility allows the u ser to exactly tun e the syste m (see SECTION 15

Platform-Specific Features for details).

If hardware related parameters are defined, the code to initialize the

system timer hardware and the interrupt handler are automatically

provided for the user as a part of OSEK OS. In that case the user does

not have to care about handling of this interrupt and he/she can not

change the provided code. If the parameters are not defined the user

has to provide the code to initialize the hardware and handle the

NON-DISCLOSURE AGREEMENT REQUIRED

Counters and Alarms

User’s Manual OSEK Opera ting System — Re v 1.2

96 Counters and Alarms MO TORO LA

interrupt. In this case in ISR for the specified interr upt the service

CounterTrigger

must be used to advance the counter .

NOTE:

The system timer will not be triggered if the EntryExitISR property is

turned OFF!

The system timer has a predefined conversion constant that equals to

the number of ticks required to reach 10 m illiseconds.

Hardware interrupts which are used to trigger counters have to be

handled in usual manner. To perform any actions with the counter the

application software processing the event should call the system service

CounterTrigger

. This service must be called within the ISR frame

created b y t he

EnterISR

and

LeaveISR

services. It is no t allo wed to use

CounterTrigger

in ISR category 1 (see section Section 6.4 ISR

Categories).

The user is free to assign one source exactly to one counter (1:1

relationship), several sources to one counter (n:1 relationship), or one

source to several counters (1:n relationship), see Figure 8-1. Meaning

that it is possible to advance the same counter in different software

routines.

User can alternatively increment the value of a counter using

AdvanceCounter

service. This service advances the current value of the

counter by the number of ticks specified (CounterTrigge r increments

counter by 1). If alarms are linked to the counter, the system checks

whether they expired during a specified number of ticks and performs

appropriate actions (task activation and event setting).

NOTE:

AdvanceCounter service is not allowed to be used in ISR.

NOTE:

AdvanceCounter service is not defined in the OSEK OS v.2.0 rev.1

specification. This is an extension of OSEK OS.

8.4 Alarm s

The al arm m anage ment is built on to p of the cou nter man agem ent. The

alarm management allows the user to perform link task activation or

Counters and Alarms

Alarms

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Counters and Alarms 97

NON-DISCLOSURE AGREEMENT REQUIRED

event setting to a certain counter value. These

alarms

can be defined

as either single (one-shoot) or cyclic alarms.

The OSEK OS allows the user to set alarms (relative or absolute), cancel

alarms and read information out of alarms by means of system services.

Alarm is referenced via its symbolic name which is assigned to the alarm

statically at the configuration stage.

Examples of possible alarm usage are:

– ‘Activate a certain task, after the counter has been advanced

60 times’, or

– ‘Set a certain event, after the counter has reached a value of

90’.

The counter addressed in the first example might be derived from a timer

which is advanced every second. The task in the example is then

activated every minute. The counter addressed in the second example

might be derived from a rotating axle. The event is set on a 90 degree

angle.

The O SEK OS takes care of th e nece ssary actions o f managing alar ms

when a counter is advanced.

Alarms are defined statically as with all other system resources. The

ass ignmen t o f ala rms to counters, as wel l as the act io n t o b e p erformed

when an alarm expires (task and event), are also defined statically. An

application can use an alarm after it has been defined and assigned to a

counter. Alarms may be either in the stop state or running state. To run

an alarm, the special system services are used, which set dynamic

alarm parameters to start it.

Dynamic alarm parameters are

• the counter value when an alarm has to expire.

• the cycle value for cyclic alarms.

An alarm can be started at any moment by means of system services

SetAbsAlarm

SetRelAlarm

. An alarm will expire (and predefined

actions will take place) when a specified counter value is reached. This

counter value can be defined relative to the actual counter value or as

NON-DISCLOSURE AGREEMENT REQUIRED

Counters and Alarms

User’s Manual OSEK Opera ting System — Re v 1.2

98 Counters and Alarms MO TORO LA

an absol ute value. The di fference be tween relati ve and abso lute alarms

is the following:

• Relative alarm expires when the specified number of count er ticks

has elapsed, starting from the current counter value at the

moment the alarm was set.

• Absolute alarm expires when the counter reaches the specified

number of ticks, sta rting f rom zero co unter value no matter which

value the counter had at the moment the alarm was set. If the

specified number of ticks is less than the current counter value, the

counter wil l roll over and count until the specified value. If the

specified value is greater than the current value, the alarm will

expire just after the counter reaches the desired number. This is

illustrated by Figure 8-2. In the latter case, the total time until the

alarm expires is the sum of T1 and T2.

Figur e 8-2. Two cases for the absolute alarm

If a cycle value is specified for the alarm, it is logged on again

immediately after expiry with this relative value. Specified actions (task

activation or event setting) will occur when the counter counts this

number of ticks, starting from the current value. This behavior of the

cyclic alarm is the same both for relative and absolute alarms. If the cycle

valu e is not spe cified ( it equa ls zero) th e alar m is consider ed as a single

one.

curren t

counter value specified

absolute value maximum allowed

counter value

specified

absolute value current

counter value

Counters and Alarms

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Counters and Alarms 99

NON-DISCLOSURE AGREEMENT REQUIRED

8.5 Programming Issues

8.5.1 Configuration Options

The following syste m configu ration options affect the coun ter and alarm

management:

•

Counters

This option defines whether counters are

provided by the OS or not.

•

CounterSize

This option defines the size of all counters. The

valid values ar e 8, 1 6 and 32 w hich co nform to

the byte, word or long word size of counters.

•

Alarms

This option defines whether alarms are

provided by the OS or not.

•

AlarmList

If this option is turned on, the running alarms

are linked into a list which decreases the time

for alarm handling.

•

AlarmDeltaList

If this option is turned on, the running alarms

are linked into an ordered alarm delta-list which

significantly decreases the time for

CounterTrigger service if too many alarms are

connected with the same counter (more than

10). The time for alarm management services

will be increased. Note that this option will be

turned off if the AlarmList option is turned on.

•

CyclicAlarm

If this op tion is turne d on, the cyclic al arms are

supported. Otherwise, no one alarm may be

cyclic, which decreases RAM usage for alarm

control blocks as well as decreasing code

usage, and advances timing of alarms services.

This option is turned on by default.

•

MinAlarmRAM

If thi s o ption is turn ed o n, th e al ar m handling is

optimized for memory (RAM). Otherwise, alarm

handling is optimized for speed. When turned

NON-DISCLOSURE AGREEMENT REQUIRED

Counters and Alarms

User’s Manual OSEK Opera ting System — Re v 1.2

100 Counters and Alarms M OTOROLA

on, the alarm control block is significantly

decrease d, especially when AlarmList option is

turned off. This opti on is turned off by default.

8.5.2 Data Types

The following data types are established by OSEK OS to work with

counters:

•

CtrRefType

the data type references a counter

•

TickType

the data type represents a counter value in

system ticks

•

TickRefType

the dat a type referen ces data cor responding to

the data type TickType

•

CtrInfoType

this data type represents a structure for storage

of counter characteristics. This structure has

the following fields:

–

maxallowedvalue

maximum possible allowed count value;

–

ticksperbase

number of ticks required to reach a

counter-specific significant unit;

–

mincycle

minimum allowed number of ticks for a

cyclic alarm (only for system with

Extended Status).

All f iel ds have the data type

TickType

. The fol lowing code may illust rate

usage of this data type:

CtrInfoType CntData;

TickType maxV, minC, cons;

GetCounterInfo( CntID, &CntData );

maxV = CntData.maxallowedvalue;

minC = CntData.ticksperbase;

cons = CntData.mincycle;

•

CtrInfoRefType

this data type re ferences data corresponding to

the data type CtrInfoType.

The fol lowing data type is e s tablished by OS EK OS to wo rk wi th alar ms:

Counters and Alarms

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Counters and Alarms 10 1

NON-DISCLOSURE AGREEMENT REQUIRED

•

AlarmBaseType

this data type represents a structure for storage

of alarm characteristics. It is the same as

CtrInfoType;

•

AlarmBaseRefType

this data type re ferences data corresponding to

the data type AlarmBaseType;

•

AlarmType

the data type represents an alarm element.

8.5.3 Counters and Alarm Generation

To generate a counter in an application, the

COUNTER

definition is

used, it looks like the following:

COUNTER <CounterID> {

MINCYCLE = <mincycle>;

MAXALLOWEDVALUE = <maxallowedvalue>;

TICKSPERBASE = <ticksperbase>;

};

To define system timer hardware-specific parameters, the following

properties should be defined in the OS definition statement:

OS <name> {

.....

SysTimer = <SysTimerSupport>;

HardwareType = <TypeOfTimer>;

Prescaler = <PrescalerDefined>;

PrescalerValue = <PrescalerValue>;

TimerModulo = <TimerModuloDefined>;

TimerModuloValue = <TimerModuloValue>;

.....

};

The system timer har d ware parameters ar e described in detail in the

section Section 13.3.5 Counters and Alarms Related Attributes.

ALARM <AlarmID> {

ACTION = <Acion>;

COUNTER = <CounterID>;

TASK = <TaskID>;

[ EVENT = <Event>; ]

};

NON-DISCLOSURE AGREEMENT REQUIRED

Counters and Alarms

User’s Manual OSEK Opera ting System — Re v 1.2

102 Counters and Alarms M OTOROLA

Detailed counter and alarm generation statements are described in

Section 13.8 Counter Definition and Section 13.9 Alarm Definition.

The declaration statem ents

DeclareCounter

and

DeclareAlarm

should

be used to declare an element (counter or alarm) before it is used:

DeclareCounter( CtrRefType <CounterID> )

DeclareAlarm

looks like the following:

DeclareAlarm( AlarmType <AlarmID> )

These declarations are equivalent to the external declaration of

variables.

8.5.4 Run-t ime Services

OSEK OS gr ants a set o f servi ces for the use r to ma nage counter s and

alarms. Detailed descriptions of these services are provided in

Sect ion 17 Sys tem Serv ices. Here only a brief list is given.

1. Thi s ser vice is not defined in the OSEK OS v.2.0 r ev.1 specification. This is an extension

of OSE K OS.

Table 8-1. Counter and Alarm Management Run-time Services

Service Name Description

InitCounter Sets the initial value of the counter

C ounterTrigge r Increme nts the counter value

GetCounterV alue Gets the counter current value

GetCou nterInfo Gets counter parameters

AdvanceCounter(1) Alternatively increments the value of a counter

SetRelAlarm Sets the alarm with a relative start value

SetAbsAlarm Sets the alarm with an absolute start val ue

CancelAlarm Cancels the alarm: the alarm is tran sferred into the STOP

state

GetAlarm Gets the time left before the alarm expires

GetAlarmBase Gets alarm parameters

Counters and Alarms

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Counters and Alarms 10 3

NON-DISCLOSURE AGREEMENT REQUIRED

Examples of the run-time service usage are provided in

Section 17 System Services.

8.5.5 Constants

For the system counter, whi ch is always a time counter, special

constants are provided by the operating system:

•

OSMAXALLOWEDVALUE

maximum possible allowed value of the

system timer in ticks;

•

OSTICKSPERTIME,

number of ticks th at are re quired to reach

10 OSTICKPERBASE milliseconds in the

system coun ter;

•

OSTICKDURATION

duration of a tick of the syst em co unter in

nanoseconds;

•

OSMINCYCLE

minimum allowed number of ticks for a

cyclic alarm (only for system with

Extended Status).

NON-DISCLOSURE AGREEMENT REQUIRED

Counters and Alarms

User’s Manual OSEK Opera ting System — Re v 1.2

104 Counters and Alarms M OTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Events 105
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 9. Events
9.1 Contents
9.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
9.3 Events and Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
9.4 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
9.2 General
Within the OSEK operating system, tasks can be synchronized via 
occupation of a resource (see Section 7 Resource Management). 
Another means of synchronization is the event mechanism, which is 
provided for Extended Tasks only. Special fields in the task node of an 
Extended Task are provided for event management in the OSEK OS 
(see Section 4 .7.2 Task Control Block). Events are the only 
mechanism allowing a task to enter the 
waiting
 state. 
An 
event
 is  an object ma naged by th e OSE K Op erating S ystem, whi ch 
is able to store binary data. The interpretation of the event is up to the 
user. Examples are: the signalling of a timer’s expiry, the availability of a 
resource, the receipt of a message , etc. 
Within the operati ng system, events are not independent objects, but 
allocated to Extended Tasks. Each Extended T ask has a definite 
number of events – 8 or less (in fact, the byte size is used for event 
management in the current OSEK OS implementation.). Events are 
represented by two event masks – byte-sized fields in the task node 
(See Section 4.7.2 Task Control Block). One field is the mask of 
events the  task i s waiti ng f or. Thi s mask c an be se t and cle ared  only by 
the task-’owner’ (a ‘private’ mask). The second field (a ‘public’ mask) 
contains the mask of the events, which are set for the task by other 
tasks. When activating an Extended Task, all its events are cleared. 

NON-DISCLOSURE AGREEMENT REQUIRED

Events

User’s Manual OSEK Opera ting System — Re v 1.2

106 Events MOTOROLA

An Extended Task can wait for several events simultaneously and

setting at least one of them causes the task to be transferred into the

ready

state . When a task wan ts to wait for one event or several ones, the

corresponding bits in its ‘private’ event mask are set. The system service

WaitEvent

is designed to force a task to wait for an event. When another

task sets an event, it sets the specified bits of the ‘public’ event mask,

and if some bits in both ‘private’ and ‘public’ masks are the same, the

task is transferred into the

ready

state. The task can clear its own events

by clearing the ‘private’ event mask.

Var ious syste m services a re a vailable to m anipulat e eve nts, de pend ing

on whether the dedicated task is the ‘owner’ of the event or another task,

which does not nece ssarily have to be an Exte nded Task. All tasks can

set any events of any Extended Task. Only the appropriate Extended

Task (the owner of the particular event mask) is able to clear events and

to wait for the setting (receipt) of events. Basic Tasks must not use the

operating system services for clearing events or waiting for them.

An alarm can also be set for an Extended Task, which sets an event at

a certain time. Thus, the Extended Task can delay itself (see example in

Section 17.7.7 Examples of Using Events).

It is not possible for an interrupt service routine or a Basic Task to wait

for an event, since the receiver of an event is an Extended Task in any

case. On the other hand, any task or ISR can set an event for an

Extended Task, and thus inform the appropriate Extended Task (its

identification must be known) about any status change via this event.

To have events in the system, the configuration option

Events

must be

turned on.

9.3 Events and Scheduling

An eve nt is an excl usive signal which i s assign ed to an Exte nded T ask.

For the scheduler, events are the criteria for the transition of Extended

Tasks from the

waiting

state i nto the

ready

state. The op erat ing system

provides services for setting, clearing and interrogation of events, and

for waiting for events to occur.

Events

Events and Sch eduling

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Events 107

NON-DISCLOSURE AGREEMENT REQUIRED

Extended Tasks are in the

waiting

state if an event for which t he task is

waiting has not occurred. If an Extended Task tries to wait for an event

and this event has already occurred, the task remains in the

running

state.

Figure 9-1 illustrates the procedures which are effected by setting an

event: Extended Task 1 (with higher priority) waits for an event.

Extended Task 2 sets this event for Extended Task 1. The scheduler is

activated. Subsequently, Task 1 is transferred from the

waiting

state into

the

ready

state. Due to the higher priority of Tasks 1 this results in a task

switch, Task 2 being preempted by Task 1. Task 1 resets the event.

Thereafter Task 1 waits for this event again and the scheduler continues

execution of Task 2.

Figure 9-1. Synchronization by events in case of full-preemptive

scheduling

If non-preemptive scheduling is supposed, rescheduling does not take

pla ce im med iatel y a fter the eve nt has been set, as show n in Figure 9-2.

Scheduler

Event of

Extended task 1

Extended task 2

set

reset

waiting running reset event wai t for event waiting

running set event ready running

NON-DISCLOSURE AGREEMENT REQUIRED

Events

User’s Manual OSEK Opera ting System — Re v 1.2

108 Events MOTOROLA

Figure 9-2. Synchronization by events in case of full-preemptive

scheduling

9.4 Programming Issues

9.4.1 Configuration Options

The only system configuration option

Events

controls event

management in the system. If it is turned off events are not imp lemented.

9.4.2 Data Types

The OSEK Operating System establishes the following data types for the

event management:

•

EventMaskType

The data type of the event mask;

•

EventMaskRefType

The data type to refer to an event mask.

The only data types must be used for operations with events.

9.4.3 Events Definition

To gene rate a cou nter i n an appli cation the

EVENT

definition is used, it

looks like the following:

EVENT <Event> {

Scheduler

Event of

Extended task 1

Extended task 2

set

reset

waiting runningreset event wait for event wai ting

running set event ready running

rescheduling

ready

Events

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Events 109

NON-DISCLOSURE AGREEMENT REQUIRED

MASK = 0x01;

};

To refer to an event the declaration statement

DeclareEvent

should be

used to declare the event before it is used.

DeclareEvent

looks like the following:

DeclareEvent( EventMaskType <Event> )

9.4.4 Run-t ime Services

OSEK OS grants a set of services for the user to manage events. A

detailed description of these services is provided in Section 17.7 Event

Management Services. Here only a brief list is given.

Examples of the run-time services usage are provided in section

Section 17.7 Event Management Services.

9.4.5 Additional Usage

Note that it is possible to use bits in memory fields assigned for events

for som e internal task’s need s as bit flags. In case of usi ng events in the

system in every Extended task’s control block special fields are created.

If a task uses less than eight events, it is possible to use

SetEvent

and

ClearEvent

system services with appropr iate masks to manipulate the

internal task’s bit flags.

See the following example:

DeclareTask( TASK_A )

DeclareTask( TASK_C )

Table 9-1. Event Management Run-time Services

Service Name Description

SetEvent Sets events of the given task according to the event mask

ClearEvent Clears events of the calling task according to the event mask

GetEvent G ets th e current event setting of the given task

WaitEvent Trans fers the calling task into the waiting state until specified events are set

NON-DISCLOSURE AGREEMENT REQUIRED

Events

User’s Manual OSEK Opera ting System — Re v 1.2

110 Events MOTOROLA

/* event masks for internal flags */

/* (generated by SG tool) */

DeclareEvent( X_FLG ) /* 0x80 */

DeclareEvent( Y_FLG ) /* 0x40 */

DeclareEvent( Z1_FLG ) /* 0x20 */

DeclareEvent( Z2_FLG ) /* 0x10 */

TASK( TASK_A )

{

EventMaskType x, y, z1, z2;

z1 = Z1_FLG; z2 = Z2_FLG;

int speed;

...

if (speed == LIMIT)

{

x = X_FLG;

SetEvent( TASK_A, x );

}

GetEventMask( TASK_A, &x );

if ((x & X_FLG) != 0 ) ClearEvent( z1 );

else SetEvent( TASK_A, z2 );

if ((x & Y_FLG) == 0 ) ChainTask( TASK_C );

...

}

In the example the task uses four most signi ficant bits of the event field

as its internal bit flags. Least significant bits are free and they can be

used for ‘external’ OSEK OS events. But such approach requires more

attention from the user to avoid occasionally changing of ‘internal’ events

instead of ‘external’ ones and visa versa.

Note that access to that binary data is performed only via the system

services for event management.

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Communication 111
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 10. Communication
10.1 Contents
10.2 Message Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
10.3 Unqueued Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
10.4 Queued Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
10.5 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
10.2 Message Concept
In the OSEK Operating System, communication between application 
tasks takes  place via messa ges. Commu nication concept  and  message 
management system services are based on the ‘OSEK Communication’ 
v. 2.1, revision 1, June 1998. Messages are stored in 
Message 
Objects (MO)
  which are handled by the operating system. A 
distinction is made between the follow ing:
•
Unqueued Messages
  and
•
Queued
 
Messages
An Unqueued Message represents the current value of a system 
variable, e.g. engine temperature, wheel speed, etc. Unqueued 
Messages are not buffered but overwritten with their actual values. The 
receive operation reads the Unqueued Message value. Thereby the 
message data is not consumed.
In contrast, a Queued Message contains an event information, e.g. 
‘engine temperature exceeds a certain limit’. Queued Messages are 
buffered with the send operation and consumed with a receive 
operation.

NON-DISCLOSURE AGREEMENT REQUIRED

Communication

User’s Manual OSEK Opera ting System — Re v 1.2

112 Communication MOTOROLA

In OSEK OS, message objects are referenced by tasks via the unique

identifiers defined by the user at the configuration stage.

The OSEK Operating System ensures data consistency of message

data during task operation, uniform in all types of scheduling. The

received message data remains unchanged until a further receive

operation is performed, unless the task or function using the data

overwrites the data with a direct access operation.

OSEK supports two types of communication between tasks: 1:1 and 1:N

communication.

• 1:1 comm unication means that only one task receives the

message;

• 1:N communication means that N tasks receive the same

message.

Both types of messages, Unqueued and Queued Messages, can be

used for 1:1 and 1:N communication, for local (ECU-internal) and

network communication.

As an option ,

task activation

event signalling

can be d efined statically

to be performed at message arrival to notify a task. Task activation or

event signalling can be used to inform tasks that want to act immediately

on new message information. There is no special operating system

servi ce to wait for m essage s, but the nor mal eve nt mecha ni sm is used.

Only one notification method can be assigned for certain messages.

Alarms can be assigned statically to message objects (only one alarm

per message object). If the message does not arrive during the time

peri od specified vi a the

ALARMRESETTIME

property in the

MESSAGE

definition statement, the alarm counter expires and an associated task is

activated or an event is signalled. Whenever a message arrives, the

alarm is restarted. This feature can be used to supervise whether

Unqueued Messages are updated or Queued Messages arrive on time.

It is possible to assign both an alarm and task notification (task activation

or event signalling) to a particular message object.

Communication

Unqueued M es sages

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Communication 113

NON-DISCLOSURE AGREEMENT REQUIRED

OSEK OS communication ser vices provide all mea ns for local messag e

transfer within single ECU. To tra nsfer data over the network, the OSEK

Communication System (COM) will be used, which is designed to handle

all other types of communication through the network. And OSEK OS

communication services provide an interface fo r application tasks to

exchange data. Thus, messages serve as interface for both ECU

internal and network communication. Uniform services wi th identical

interfaces are offered (network transparency).

10.3 Unqueued Messages

Unqueued Messages represent the current value of a state variable.

Tasks can have three various access type to Unqueued Messages –

read only (receive), write only (send) and full read/write access. The

send operation overwrites the current value of a message, i.e.

Unq ueued Mes sages are not bu ffere d. T he r eceive o peration reads t he

current value of a Unqueued Message whereby the message data is not

consumed.

These services ensure:

• the consistent writing and reading of message data within the

send and receive operation (also in preemptive systems) and

• the consistency of data while tasks and functions (subprograms)

use the message data.

Table 10-1. Features of the Message Concept

Unqu eue d Message Qu eued Me ssage

N o buffering Buff ering in a FIFO-queue

No consum ption of messag e Consum ption of messa ges

Direct access possible in non-preemp tive

systems (no copies) No direct access possible (a lways copies)

Static definition of task activation or event signalling

Static definition of a message alarm

NON-DISCLOSURE AGREEMENT REQUIRED

Communication

User’s Manual OSEK Opera ting System — Re v 1.2

114 Communication MOTOROLA

An Unqueued Message can have a default value which is assigned

statically to the message at the configuration stage. This value is

returned when the message is received first time without prior send

operati on (see Section 13.10.1 Object Attributes and example in

Section 10.5.5 Usage of Messages for details regarding Unqueued

Message default value).

Unqueued Messages may be either with or without a local copy of a

message. It indicates statically with message property

WithCopy

set to

TRUE

or se t to

FALSE

respectivelly. Last case is called

WithoutCopy

for

convenience. The distinction between these kinds of Unqueued

Messages is the following:

• When the

WithCopy

confi guration is used, the Unqueued

Message item is copied from the task data space into the message

item for send operation, and from the message item to the task

data space for receive operation. The message body is copied

consistently, i.e. the operating system provides atomic behavior of

the send-receive operations. The defa ul t value is copied f rom the

user’s-defined area into the message body during system start-up.

• When the

WithoutCopy

configur ation is used, t he Unqueued

Message item is not copied from the task data space into the

message item. Instead, the task-sender updates the message

body di rectly via de-refer encing of th e pointer and wr iting the da ta

at the pointer address, and the task-receiver uses the message

body by means of de-referencing the pointer and reading the data.

The oper ating system doesn’t provide atomic behavior of the

send-receive operations, and this consistency is to be provided by

the user’s code.

Unqueued Messages are used similar to C-language variables (direct

access e.g. in a C-language assignment or in a C-language expression).

The access privileges (send, receive or send/receive) defined for a

message also determine which direct access operations are allowed.

1:N communication for Unqueued Messages does not have any

difference from 1:1 communication, since any task can read the

Unqueued Messages if its identifier is known.

Communication

Queued M es sages

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Communication 115

NON-DISCLOSURE AGREEMENT REQUIRED

To have Unqueued Messages in the system the configuration option

UnqueuedMessages

must be turned on.

10.4 Queued Messages

In contrast to Unqueued Messages, Queued Message objects can

tempor arily store severa l messages. The temp orary storage follow s the

FIFO principle, i.e. messages are received in the same order as they

were sent. During the send operation the message item is copied from

the task data space into the message FIFO area at the write pointer.

During the read operation the message item is copied from the FIFO

area at the read pointer into the receiving task space. The data is copied

consistently, i.e. the operating system provides atomic behavior of the

send-receive operations. The FIFO area is circular. It is illustrated in

Figure 10-1. Message “msg1” is consumed from the Queued Message

object by a task, and other message items are “moved” in the Queued

MO tow a rds the t op ( in fa ct, r ead and wri te p ointer s ar e cha nged ). After

the message item “msg1” was consumed, new message “msg5” is

wri tten by a task at the empty location (the last one). If an Queued

Message object has no memory ca pacity lef t to store t he new messag e,

the ol dest messag e is overwritten - in Figure 10-1 “msg2” i s overw ritten

by the message item “msg6” in spite that “msg2” has not been

consumed. The overwriting process is indicated both to sender and

receiver in systems with Extended Status by means of return codes

while send or receive services are executed by a task.

A Queued Messa ge is characteri zed by the le ngth of a single message

item an d by the d epth of a que ue. T hese par amete rs a re d efined by th e

user at the configuration stage.

NON-DISCLOSURE AGREEMENT REQUIRED

Communication

User’s Manual OSEK Opera ting System — Re v 1.2

116 Communication MOTOROLA

Figur e 10-1. Operations with Queued Messages

Event communication includes an implicit synchronization of the

communication partners since an Queued Message must be sent before

it can be received. When the re ceive operation is performed, an Queued

Message is removed from the message object and is thus consumed.

In case of multiple receivers (1:N communication) OSEK OS ensures

that no rece iver may receive a new message, until all receivers will

complete the reception of the current message. The last receiver

consumes the message.

To have Queued Messages in the system, the configuration option

QueuedMessages

must be turned on.

10.5 Programming Issues

10.5.1 Configuration Options

The following system configuration options ar e intended to control

communication features:

...

“msg2”

“msg3”

“msg4” ...

“msg2”

“msg3”

“msg4”

“msg2”

“msg3”

“msg4”

“msg5”

“msg1” is consumed

by a task “msg1”

“msg5” “msg6”

read

pointer

write

pointer

read

pointer

write

pointer

read

pointer

write

pointer

123

New message “msg5”

is written by a task into

the Queued MO

New message “msg6”

will overwrite “msg2” of

the Queued MO

Communication

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Communication 117

NON-DISCLOSURE AGREEMENT REQUIRED

•

UnqueuedMessages

This option allows Unqueued Messages

in the system;

•

UnqueuedMsgDefaultValue

This option allows Unqueued Messages

to have default values;

•

QueuedMessages

This option allows Queued Messages in

the system;

•

QueuedMsgOneToN

If this option is turned on, 1:N Queued

Messages are allowed;

•

ActivateOnMsg

If this option is turned on task activation

on message arrival is supported;

•

AlarmOnMsg

If this opt ion is turned on an ala rm can be

linked to message arrival;

•

SetEventOnMsg

If this option is turned on event setting is

allowed on message arrival.

10.5.2 Identifiers

The following names are used in the OSEK Operating System for work

with messages:

•

SymbolicName

This is an unique name representing a

message. It only can be used in

conjunction with calls of the message

service. A SymbolicName need not be a

data type. Variables or constants of

SymbolicName can be declared or used.

•

AccessName

This is a unique name defining access to

a message object. Depending on the

chosen configuration, a distinction is

made between the following

AccessName

scheme:

WithCopy

configuration:

A application variable exists as a local

copy of the message. The name of the

NON-DISCLOSURE AGREEMENT REQUIRED

Communication

User’s Manual OSEK Opera ting System — Re v 1.2

118 Communication MOTOROLA

variable is the

AccessName

. This variable

contains a copy of the corresponding

message object.

WithoutCopy

configuration:

The me ssage object data is a ccessed via

the

AccessName

. This

AccessName

is a

static link: it refers directly to the message

object data. The

AccessName

refers to

the same data (RAM) as the message

object.

10.5.3 Mess age Definition

Each message in an application is generated by means of using

statements like the following :

MESSAGE <MsgName> {

ACTION = <MessageAction>;

TYPE = <MessageType>;

ITEMTYPE = <type>;

ITEMS = <BufferSize>;

ALARMRESETTIME = <TimeOut>;

ALARMRESET = <AlarmId>;

StartupAlarm = <Start>;

TASK = <TaskId>;

EVENT = <EventMask>;

ReceiverNum = <NumberOfReceivers>;

DefaultValue = <InitialValue>;

};

The

MESSAGE

definition statement defines either Unqueued or Queued

message according to

TYPE

property setting. The

TASK

and

EVENT

refer ences are designed to link the acti on with the message arr ival. The

ALARMRESET

at tribute is used to li nk an alarm with message arriva l –

when the message arrives the alarm is restarted. In detail message

configuration statements is described in Section 12 System

Configuration.

There is no constructional elements defined for messages.

Communication

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Communication 119

NON-DISCLOSURE AGREEMENT REQUIRED

10.5.4 Run-t ime Services

OSEK OS grants a set of services for the user to manage tasks. Detailed

descriptions of these services are provided in section

Section 17.8 Comm unication Management Services. Here only a

brief list is presented.

Examples of the run-time services usage are provided in

Section 17 System Services.

10.5.5 Usage of Messages

Messages are identified via a symbolic name. This identifier is used for

references to the message when the system service is used.

If the message is used in the

WithCopy

configuration, then the variable

to hold message data is defined within the user’s code by means of using

the regular C-language definitions. Because system generator always

create

typedef

decl aration for every message , it is recommen ded to u se

this declaration for definition of variables which hold message data. By

conv entio n, this

typedef

consists of prefix

OSMSG

and name of the

message <MsgName >, defined in

MESSAGE

description in OIL file.

For example, if t he user defines the message

MsgA

having type

int,

then

user’s code may access message using the following statements:

OSMSGMsgA _MsgA;

ReceiveMessage( MsgA, _MsgA );

Table 10-2. Task Management Run-time Services

Serv ice Name Description

SendM essage Updates the unqu eued m essag e

Receive Message Gets the unqueued me ssag e

GetMessageResource Sets the given message object status as busy if it is

not already so

ReleaseMessageResource Sets off the mes sage object from busy

GetM essageS tatus Returns the current status of the message

NON-DISCLOSURE AGREEMENT REQUIRED

Communication

User’s Manual OSEK Opera ting System — Re v 1.2

120 Communication MOTOROLA

if( _MsgA == 2 ) { _MsgA = 1; }

SendMessage( MsgA, _MsgA );

If the message is configured without

WithCopy

property, then the pointer

to the message body should be defined within the user’s code using

regular C-language statements. Again, because system generator

creates

typedef

declarati on for m essage item, it is recommend ed to use

this declaration for definition of pointer, which is used access message

data.

For example, if the user defines the

WithoutCopy

message

MsgB

, having

the type

int

, then user’s code may access message using the following

statements:

OSMSGMsgB*_MsgB = (OSMSGMsgB*)&OSMsgB->msg;

ReceiveMessage( MsgB, _MsgB );

if( *_MsgB == 2 ) { *_MsgB = 1; }

SendMessage( MsgB, _MsgB );

The fol lowing exampl e demon strate s Unqu eued Message defau lt valu e

definition.

/* Source C-file */

const int myMsgADefValue = 0; /* MsgA default value */

/* Configuration OIL-file */

MESSAGE MsgA {

TYPE = UNQUEUEDMESSAGE;

ITEMTYPE = "int";

ITEMS = 1;

DefaultValue = "&myMsgADefValue";

};

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Error Handling and Special Routines 121
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 11. Error  Handling and Special Routines
11.1 Contents
11.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
11.3 Hook Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
11.4 Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
11.5 Start-up Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
11.6 Application Modes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
11.7 System Shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
11.8 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
11.2 General
The OSEK Operating System provides the user with tools for error 
handling and simple debugging at run time. These are special hook 
routi nes  with names sp ecified  by OSEK OS  that  ar e t o b e d evelope d by 
the user. In this section, error handling at the system configuration stage 
is  not  co nsidere d; it is  d escribed  in  S ection 12 System  Configuration .
11.3 Hook Rou tin es
The OSEK Operating System supports system specific  
hook 
routines
  to allow user-defined actions within the OS internal 
processing.
These hook routines in OSEK OS are:
• Called by the operating system, in a special context depending on 
the implementation of the operating system;

NON-DISCLOSURE AGREEMENT REQUIRED

Error Handling and Special Routines

User’s Manual OSEK Opera ting System — Re v 1.2

122 Error Handling and Special Routines MO TORO LA

• Higher priority than all tasks;

• Using an implementation-dependent calling interface;

• Part of the operating system, but user defined;

• Implemented by the user;

• Standardized in interface per OSEK OS implementation, but not

standardized in functionality (envi ronment and behavior of the

hook routine itself), therefore usually hook routines are not

portable;

• Only allowed to use a subset of API functions;

• Optional.

In the OSEK OS hook routines are intended for

• System startup. The cor responding h ook routi ne (

StartupHook

) is

called after the operating system startup and before the scheduler

is running;

• Tracing or application dependent debugging purposes as well as

user defined extensions of the context switch;

• Error handling. The corresponding hook routine (

ErrorHook

) is

called if a system call returns a value not equal to

E_OK

;

• System shutdown. The corresponding hook routine

(

ShutdownHook

) is called.

The OSEK OS provides the following hook routines –

ErrorHook

PreTask

Hook,

PostTaskHook

StartupHook

ShutdownHook

IdleLoopHook

1. The u ser must crea te the cod e of these routines, OSEK

OS only provides description of function prototypes.

•

ErrorHook

– this hook is called by the Operating System at the end

of a system service which has a return value not equal to

E_OK

(see Section 11.4.1 Error Interface). It is called before returning

to the task level or the ISR level.

IdleLoopHook

hook r outine is not introduce d in OSEK OS standar d. It is an extension o f OSEK

OS.

Error Handling and Special Routines

Hook Routines

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Error Handling and Special Routines 123

NON-DISCLOSURE AGREEMENT REQUIRED

•

PreTaskHook

– this hook is called before the operating system

enters the context of the task. This hook is called from the

scheduler when it passes control to the given task. It may be used

by the application to trace the seq uences an d timing of the tasks’

exec ution.

•

PostTaskHook

– This hook is called after the operating system

leaves the context of the task. It is called from the scheduler when

it switches fro m the current task to anoth er. It may be used by the

application to trace the sequences and timing of tasks’ execution.

•

StartupHook

– This hook is called after the operating system

startup and befo re the sc heduler i s runn ing. It may be used by the

application to perform initialization actions, task activation, alarm

setting.

•

Shutdo wnHook

– This hook is called when the service ShutdownOS

has been called. It is called before the Operating System shuts

down itself.

•

IdleLoopHook

– This hook is called from scheduler idle loop (see

Section 5.2 General). It is not possible to call any OSEK OS

directives from this hook. Hardware dependent code (like

manipulation with COP registers) may be placed here.

Time stam ps can be integrate d individually into the applicati on software

with the help of hook routines

OSPreTask

and

OSPostTask

. The user

can set time stamps enabling him to trace the program execution at the

following locations before calling operating system services:

• When activating or terminating tasks;

• At explicit points of rescheduling (

ChainTask

Schedule

);

The Operating System does not need to include a time monitoring

feature which ensures that each task or a specific task, e.g. with the

lowest priority, has been activated after a defined maximum time period.

The user can optionally use the hook routines or establish a watchdog

task that takes ‘one-shot displays’ of the operating system status.

See examples of programming techniques using the hook routines in

Section 17.9 Operating System Execution Control.

NON-DISCLOSURE AGREEMENT REQUIRED

Error Handling and Special Routines

User’s Manual OSEK Opera ting System — Re v 1.2

124 Error Handling and Special Routines MO TORO LA

Some system services may be called by the hook routines:

Table 11-1. OSEK OS system services for hook r outines

Service

Hook routines

Error

Hook PreTask

Hook PostTask

Hook Startup

Hook Shutdown

Hook

DeclareTask allowed allowed allowed allowed allowed

ActivateTask -- -- -- allowed --

TerminateTask -- -- -- -- --

ChainTask -- -- -- -- --

Schedule -- -- -- -- --

GetTaskId allowed(1) allowed allowed -- --

GetTaskState allowed allowed allowed -- --

GetTCBInfo allowed(2) allowed allowed -- --

EnterISR -- -- -- -- --

LeaveISR -- -- -- -- --

EnableInterrupt -- -- -- -- --

DisableInterrupt -- -- -- -- --

GetInterruptDescriptor allowed allowed allowed -- --

DeclareResource -- -- -- -- --

GetResource -- -- -- -- --

ReleaseResource -- -- -- -- --

DeclareEvent allowed allowed allowed -- --

SetEvent -- -- -- -- --

ClearEvent -- -- -- -- --

GetEvent allowed allowed allowed -- --

WaitEvent -- -- -- -- --

InitCounter -- -- -- -- --

CounterTrigger -- -- -- -- --

AdvanceCounter -- -- -- -- --

GetCounterValue ----------

Error Handling and Special Routines

Hook Routines

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Error Handling and Special Routines 125

NON-DISCLOSURE AGREEMENT REQUIRED

1. It may happen that currently no tas k is

running

. In this case the service returns the task Id

INVALID_TASK

2. It may happen that currently no task is

running.

In this case the serv ice returns E_NOFUNC re turn value if OSEK

OS has the

Extended Status

GetCounterInfo -- -- -- -- --

DeclareAlarm allowed allowed allowed -- --

GetAlarmBase allowed allowed allowed -- --

GetAlarm allowed allowed allowed -- --

SetRelAlarm -- -- -- -- --

SetAbsAlarm -- -- -- -- --

CancelAlarm -- -- -- -- --

SendMessage -- -- -- -- --

ReceiveMessage allowed for

unqueued

messages -- -- -- --

GetMessageResource -- -- -- -- --

ReleaseMessageResource -- -- -- -- --

GetMessageStatus allowed -- -- -- --

GetActiviveApplicationMode allowed allowed allowed allowed allowed

StartOS ----------

ShutdownOS -- -- -- -- --

Table 11-1. OSEK OS system services for hook r outines

Service

Hook routines

Error

Hook PreTask

Hook PostTask

Hook Startup

Hook Shutdown

Hook

NON-DISCLOSURE AGREEMENT REQUIRED

Error Handling and Special Routines

User’s Manual OSEK Opera ting System — Re v 1.2

126 Error Handling and Special Routines MO TORO LA

NOTE:

It i s not po ssible to cal l any OSEK OS se rvices from IdleL oopHook ho ok

routine.

11.4 Error Handling

11.4.1 Error Interface

The hook routine

ErrorHook

is provided to handle temporarily and

permanently occurring errors within the OSEK Operating System. Its

basi c frame work is predefi ned and must be compl eted by the user. Th is

gives the user a choice of efficient centra lized or decentralized error

handling.

Three different kinds of errors are distinguished in OSEK OS:

• Application errors – the Operating System could not execute the

requested service correctly, but assumes the correctness of its

internal data. In this case, centralized error treatment is called.

Additionally, the Opera ting S ystem retu rns the error by the st atus

information for decentralized error treatment.

• Fatal errors – the Operating System can no longer assume

correctness of its internal data. In this case OSEK OS calls the

centralized system shutdown.

The special system routine

ShutdownOS

is intended to shut down the

system in case of the fatal error. S

hutdownOS

may be called both by the

user and by the system on experiencing a fatal error. These service

routines are provided by the OSEK Operating System as opposed to the

ErrorHook

routi ne, which should be written by the user. User hook

Shutdo wnHook

is called by S

hutdownOS.

The OS EK OS error service is ca lle d with a param eter that spec ifies the

error . It i s u p t o th e use r to d ecide w hat to d o, d epend ing on whic h er ror

has occurred. The OSEK Operating System specifies the following

errors:

Error Handling and Special Routines

Error Handling

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Error Handling and Special Routines 127

NON-DISCLOSURE AGREEMENT REQUIRED

Errors committed by the user in direct conjunction with the Operating

System can be intercepted to a large extent via the Extended Status of

the Operating System, and displayed. This results in an extended

plausibility check on calling OS services.

11.4.2 Extended Status

The OSEK Operating System version with

Extended Status

requires

more execution time and memory space than the run time version, due

to the additional plausibility checks it offers. However, many erro rs can

be found in a test phase. After they have all been eliminated, the system

can be recompiled with the run time version.

The following example can illustrate Extended Status usage:

Table 11-2. OSEK OS Error codes

Erro r N ame Value De scri ptio n

Comm on Error Codes

E_OK 0 No error, successful completion

E_OS_A CCESS 1 A ccess to the service/object denied

E_OS_CA LLEV EL 2 Access to the service from the ISR is not permitt ed

E_OS_ID 3 The object ID is invalid

E_OS_LI MIT 4 The limit of services/objects exceeded

E_OS_NOFUNC 5 The object is not used, the service is rejected

E_OS_RESOURCE 6 The task still occupies the resource

E_OS_STATE 7 The state of the object is not correct for the required service

E_OS_VALUE 8 A value outside of the admissible limit

E_OS_SYS_STACK 10 Internal stack overflow

E_COM_BUSY 1 Message in use by application task/function

E_COM_ID 3 Invalid message name passed as parameter

E_COM_LI MIT 4 Overflow of FIFO associated with queued messages

E_COM_LOCKED 7 Rejected service call, me ssag e object locked due to a pending

operation

E_COM_NOM S G 9 No message available

NON-DISCLOSURE AGREEMENT REQUIRED

Error Handling and Special Routines

User’s Manual OSEK Opera ting System — Re v 1.2

128 Error Handling and Special Routines MO TORO LA

• If a task is activated in the run time, either ‘OK’ or ‘Task already

activated’ is returned. Moreover, in the Extended Status version,

the addi tion al status l ike ‘Task no t defined ’ , ‘Maximu m numb er of

tasks already activated’ or ‘Stack overflow’, etc. can be returned.

These extended messages must no longer occur in the target

appl ication a t the time of executio n, i .e., the cor resp onding err ors

are not intercepted in the operating system’s run time version.

11.4.3 Possible Error Reasons

Errors in the application software are typically caused by:

• Errors on handling the operating system, i.e. incorrect

configuration / initialization / dimensioning of the operating system

or non-observance of restrictions regarding the OS service.

• Error in software design, i.e. unwise choice of task priorities,

generation of deadlocks, unprotected critical sections, incorrect

dimensioning of time, inefficient conceptual design of task

organization, etc.

11.5 Start-up Routine

The special system routine

StartOS

is implemented in the OSEK

Operating System to allocate and initialize all dynamic system and

application resources in RAM. These routines are called from the main()

function of the application with the application mode as parameter (see

Section 11.6 Application Modes) and pass the control to the

scheduler to schedule the first task to be running. User hook

StartupHook

is called after operating system startup and before the

schedul er is r unning

See Appendix A Sample App lication for details .

The figure below shows system startup.

Error Handling and Special Routines

Start-up Routine

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Error Handling and Special Routines 129

NON-DISCLOSURE AGREEMENT REQUIRED

Figure 11-1. System startup in the OSEK OS

After returning from th e

StartupHook

hook routine, the operating system

enables interrupts according to

INITIAL_INTERRUPT_DESCRIPTOR

(see Section 6.7.6 Constants), and starts the scheduler.

O S executes

system

operation

initia l iz a ti on code

(Re-)Start

hardware-

specific call to OS executes

StartupHook OS kernel

is running

first user

task is

running

During StartupHook all

user interrupts are

disabled

initia l iz a ti on code StartOS

NON-DISCLOSURE AGREEMENT REQUIRED

Error Handling and Special Routines

User’s Manual OSEK Opera ting System — Re v 1.2

130 Error Handling and Special Routines MO TORO LA

11.6 Application Modes

Application modes are supported to allow OSEK OS to come under

different modes of operation. The minimum number of application

modes is one (SG tool generates an application mode with name “Mode“

by default). Once the operating system has been started, it is not allowed

to change the application mode. Each application mode consists of its

own set of tasks. There is no limitation to having a task or ISR running in

different modes. Sharing a task/ISR between different modes is

recommended if the same functionality is needed again.

NOTE:

If the system is running i n a specifi c application mode, then it is not

possible to affect a task from another application mode (it may lead to

inappropriate application behavior).

Special OIL statements should be used to define different application

modes (see Section 13.12 Different Application Modes Definition).

After system shutdown, it is possible to start an application in another

application mode (with another set of tasks), therefore run-time

reconfiguration is supported.

NOTE:

After application re-start either in the same or in another application

mode internal OSEK OS data will only be initialized. The user is

responsib le for pro per i niti alizatio n of user’s dat a on applic ation re-sta rt.

NOTE:

Application mode consists of own set of tasks. All other OSEK OS

system objects like Alarms, Messages, Stack Pools etc. are shared

between different application modes.

11.7 Sys tem Sh utdown

The special

ShutdownOS

service exits in OSEK OS to shut down the

operatin g syste m. This se rvice could b e r equest ed b y the applicat io n or

requested by the operating system due to a fatal error.

When

ShutdownOS

service is called with a defined error code, the

operating system will shut down and call the hook routine

ShutdownHook

. The user is free to define any system behavior in

ShutdownHook

e.g. not to return from the routine. If

ShutdownHook

Error Handling and Special Routines

Programming Issues

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Error Handling and Special Routines 131

NON-DISCLOSURE AGREEMENT REQUIRED

retur ns, the oper ating system jumps to the next statem ent following the

initial call to

StartOS

. After thi s, the OSEK OS may be started agai n in a

specified application mode.

NOTE:

After the retur n from ShutdownOS service all interrupts will be disa bled.

11.8 Programming Issues

11.8.1 Configuration Options

The following configuration options affect error handling and hook

routines:

•

ErrorHook

If this option is turned on, the ErrorHook is

called by the system for error handling

•

PreTaskHook

If this option is turned on, the

PreTaskHook is called by the system

before context switching

•

PostTaskHook

If this option is turned on, the

PostTaskHook is called by the system

before context switching

•

StartupHook

If this option is turned on, the StartupHook

is called by the system at the end of the

system initialization

•

ShutdownHook

If this option is turned on, the

ShutdownHook is called by the system

when the OS service ShutdownOS has

been called

•

IdleLoopHook

If this option is turned on, the

IdleLoopHook is called from scheduler

idle loop

NON-DISCLOSURE AGREEMENT REQUIRED

Error Handling and Special Routines

User’s Manual OSEK Opera ting System — Re v 1.2

132 Error Handling and Special Routines MO TORO LA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA System Configuration 133
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 12. System Configuration
12.1 Contents
12.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
12.3 Application Configuration File. . . . . . . . . . . . . . . . . . . . . . . . .134
12.4 OIL Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
12.2 General
The OSEK Operating System is fully statically configured one. All 
system properties, the number of system objects and their parameters 
(character istics of tasks, counters, alarms, messages, etc.), run time 
behavior are defined by the user. Such approach allows the user to 
create various range of applications with exactly defined characteristics. 
Diffe rent me mory and  pe rformanc e requir ements can  be ea sily satisfi ed 
with such modular approach. 
All application parameters are defined in the special configuration file. 
This file must conform some grammar rules. It is processed by the 
separate 
System Generator utility (SG) 
1. The System 
Generator analyzes statements in the configuration file and builds output 
C-l anguage files needed to compile and link an application with the 
spec ified feature s. Durin g its execution S G repor ts to the u ser about t he 
errors. The System Generator produces header and source code files 
that defines all properties and objects in terms of the C language. These 
files a re to  be com piled an d li nked to gethe r with the  user’ s so urce co de.
1. One version of SG i s delivered -  the 32-bit version (‘ sysgen.exe ’)  for Windows NT and Win-
dows 95.

NON-DISCLOSURE AGREEMENT REQUIRED

System Configuration

User’s Manual OSEK Opera ting System — Re v 1.2

134 System Configuration MOTOROLA

12.3 Application Configuration File

Application configuration file

contains the statements which

define the system properties and objects. Such file can have any

extension an d the extension ‘.oil’ is suggested by de fault. The file of this

format is processed by the SG uti lity.

As a result of application configuration file processing SG produces

three types of standard C-language files as it is described in

Section 14.3.1 Application Configuration. SG produces two header

files and one source file. These files provides the code for all system

tables, descriptors, arrays etc. both in ROM and RAM according to the

user specified application configuration.

12.4 OI L Concept

OSEK Implementation Language (OIL)

is the specially designed

language for development of embedded applications based on OSEK

concept. OIL is used to describe the application structure (application

configuration) as a set of system objects with defined links. OIL allows

the user to write an application configuration as a text file. These files

have predefined structure and special (standard) grammar rules.

All system objects specified by OSEK and relationships between them

can be described using OIL. OIL defines standard types for system

objects. Each object is described by a set of attributes and references.

All keywords, attributes, object names, and other identifiers are case-

sensitive.

12.4.1 OIL File

The OIL fil e contains two parts - one for the defin it ion of im plementation

specific features (Implementation Definition) and another one for the

definition of the structure of the application located on the particular CPU

(Application Definition).

In the very beginning of an OIL file the number of the version of OIL is

indicated. The keyword OIL_VERSION is used for this purpose. Two OIL

System Configur ation

OIL Concept

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Configuration 135

NON-DISCLOSURE AGREEMENT REQUIRED

versions are supported at the moment - version 2.0 corresponds to the

Stand ard OIL for mat and ve rsion 2.0e co rresponds to the Exte nded OIL

format. For example:

OIL_VERSION = "2.0e";

12.4.2 Standard OIL Format

The S tandard OIL is inte nded to configur e OSEK OS Opera ting System

(OS) with single application mode (SG generates single application

mode wi th name ‘Mode’ by default). The Standard OIL is considered to

be a part of OSEK OS specification v.2.0. It strictly defined by the

“OSEK/VDX System Generation OIL: OSEK Implementation

Language”, version 2.0, OSE K grou p, 16.12.19 97.

12.4.3 Extended OIL Format

Extended OIL format includes extensions needed to control additional

feature s like Object Li brary, mult ipl e applicatio n configuration de finition,

and C onstant Tables . For d etails r egarding Ex tended OIL forma t please

refer to OSEK Builder User’s Manual. To establish different application

modes in OSEK OS application it is necessary to use Extended OIl

format in application configuration file.

12.4.4 Implementation Definit ion

The Im plemen tati on Def ini tion defin es implem entati o n specific features

for the particular OSEK implementation for which this application is

developed.

The user can limit the given set of values for object attributes (e.g.

restrict the possible OS confor m a nce classes).

It is not allowed to exclude any standard attributes from the particular

OSEK implementation. Additional non-standard attributes can be

defined for the objects for the particular OSEK implem entation.

If no implementation definition is i ncluded in the OIL file then the

complete set of standard attributes and standard attribute values is

NON-DISCLOSURE AGREEMENT REQUIRED

System Configuration

User’s Manual OSEK Opera ting System — Re v 1.2

136 System Configuration MOTOROLA

considered to be defined for the application. Otherwise it defines value

ranges for the attributes allowed by the OSEK implementation.

If some standard attributes have no restrictions for a particular

implementation then the description of this attribute can be omitted in the

corresponding implementation definition.

The i nclud e mecha nis m (se e Se ctio n 12.4.5.2 Inc lud e Dire ctive) can

be used to define the i mple menta tion defini tion as a separate file. Thu s

corresponding implementation definition files can be developed and

delivered with particular OSEK implementations and then included in

user’s OIL files. The Mo torola OSEK OS implementa tion is descr ibed in

the “mot20.oil” file which are delivered in the package.

12.4.4.1 Implementation Definition Grammar

Implementation Definition part starts with keyword IMPLEMENTATION

and implementation name.

The stru cture for Implementation Definition part is shown using the

following syntax:

IMPLEMENTATION <name> {

<object_descriptions>

};

All obj ects withi n Implement ation Definit io n part are descri bed using the

same syntax.

<object_type> {

<property_definitions>

};

Object type is defined by the object keyword. For Motorola OSEK OS

implementation the following object types are implemented:

OS, TASK, ISR, STACK, RESOURCE, EVENT, COUNTER, ALARM, MESSAGE

The set of object properties are to be defined within the object

description. Both implementation specific attribute and re ference shall

be defined before it is used.

The attribute definition has the following structure:

System Configur ation

OIL Concept

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Configuration 137

NON-DISCLOSURE AGREEMENT REQUIRED

<attr_type> [ WITH_AUTO ] [ <attr_range> ] <attr_name> [ = <default_value>

] ;

The at tribute type and attr ibute value ra nge (if it exists) shal l be defined.

The range of attribute values can be defined in two ways: either the

mi nimum and maximum allowed attribu te values ar e defined (the [0..1 2]

style) or the list of possible attribute values are presented (like C

enumeration type).

The WITH_AUTO specifier can be combined with any type. If

WITH_AUTO can be specified it means that this attribute can have the

value AUTO and the possibility of automatic assignment.

Data types defined for OIL are listed below. Note that these data types

are not necessarily the same as the corresponding C data types.

• INT – Any integer number.

• ENUM – The li st of possible values sha ll be presente d. Any value

from the list can be assigned to this attribute.

• BOOLEAN – The attribute of this type can have either TRUE or

FALSE value.

• STRING – Any 8-bit character sequence enclosed in double-

quotes, but not containing double-quotes can be assigned to this

attribute. If the ‘\’ symbol is placed before the EOL symbol (End-

Of-Line) in the string then the next line is the continuation of the

previous one. This is identical to the same rule for long text strings

in the C language.

A reference is a special type of value intended to define links between

system objects. The reference definition has the following structure:

<object_type> <reference_name> [ <multiple_specifier> ];

The re ference type is ta ken from the referenced object (e.g. a r eference

to a task shall use the TASK keyword as reference type). A reference

can ‘point to’ any system object.

Multiple reference is the possibility to refer to several objects of the same

type with one OIL statement. For example the task can refer to several

events. If the reference shall be defined as a 'multiple' reference then the

'[]' brackets shall be present after the reference name.

NON-DISCLOSURE AGREEMENT REQUIRED

System Configuration

User’s Manual OSEK Opera ting System — Re v 1.2

138 System Configuration MOTOROLA

12.4.5 Application Definition

In the application definition the OSEK application is composed from a set

of system o bjects. In gener al th e ap plication can conta in m ore than on e

system object of the same type.

Since an application is performed on CPU the entity called

CPU

introduced as the top of the description. This entity encompasses all

local objects such as tasks, messages, etc. Therefore,

CPU

can be

considered as a container for application objects. This concept is

introduc ed to prov ide futur e OIL evolutio n towards to distribut ed system

support. This entity is identified by the keyword CPU.

12.4.5.1 Object Definition

All objects are described using the same syntax.

<object_type> <object_name> {

<property_definitions>

};

Objects are labeled by keywords which shall be written in upper case.

Obj ect attribu tes and refe rence s are also l abeled by the keywor ds. The

keywords are introduced in Section 13 System Objects Definition.

After an object keyword the object name must follow. Name is combined

from any symbols up to 32 symbols long.

A set of attributes and references belonging to an object is enclosed in

curly brackets, like in C language.

All assignments are made via the ‘=’ opera tor. Each statement ends with

semicolon - ‘;’ like in the C language. A reference is represented as a

refer ence type keyword assi g ned with a na me of th e object re fere nced.

If multiple reference pointed to the set of object the object names are

listed via comma in side the curly bracke ts, for example task r eferencing

to own events:

EVENT = { MyEvent1, MyEvent2};

System Configur ation

OIL Concept

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Configuration 139

NON-DISCLOSURE AGREEMENT REQUIRED

12.4.5.2 Include Directive

The preprocessing directive to include other OIL files is allowed in any

place of the OIL fil e. This statement has the same syntax as in ANSI-C:

#include <filename.oil>

#include "[path]filename.oil"

The filename can be optionally preceded by a directory specification.

The quoted form means that a header file is being looked for in the

curren t directory fi rst, the n along the p ath specified by the “/I” com mand-

line option, then along paths specified by the special environment

variable. The angle-bracket form means that a header file is being

loo ked for first alo ng the path sp eci fied by t he “/I ” com mand -line op ti on,

then along paths specified by the special environment variable.

12.4.5.3 Comments

An OIL file may contai n commen ts. The ’/*’ a nd ’//’ character s define the

start of a comment. Any characters after ’//’ are considered as a

comment and the end of line (EOL) terminates the comment. Any

characters after ’/*’ are considered as comments and the end of the

comment is defined by ’*/’. Nested comments are no t allowed in OIL.

12.4.5.4 File Structure

Any file i n the Standar d OIL form at de scri bes a n app licati on fo r a single

CPU and, in general, must have the following structure:

OIL_VERSION = <version>;

IMPLEMENTATION <name> { // Implementation definition

<OBJECT_TYPE> {

...list of implementation specific object attributes...

};

...

};

CPU <name> { // Definition of the application on CPU

<OBJECT_TYPE> <object_name>

{ // System object definition

<ATTRIBUTE> = <value>;

<REFERENCE> = <object_name>;

<REFERENCE> = { <object_name>, ... };

... list of object attributes and references ...

NON-DISCLOSURE AGREEMENT REQUIRED

System Configuration

User’s Manual OSEK Opera ting System — Re v 1.2

140 System Configuration MOTOROLA

};

... list of objects ...

}

12.4.6 Configuration File Rules

The application configuration files must conform some simple rules to be

successfully processed. The rules are:

• Each object has the unique name;

• An object can have a set of attributes which define object

properties;

• An object can have a set of references to other system objects;

• Each object shall be described only once, any type of redefinitions

is not allowed;

• All statements must be written without errors;

• It is recommended to avoid conflicting statements (e.g., the

system p rop erty

TaskOwnStack

is not set, but the own task stack

is defined for a task) since it leads to error or warning messages.

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTO ROLA System Objec ts Definition 141
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section  13. System Objects Definition
13.1 Contents
13.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
13.3 OS Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
13.4 Task Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
13.5 Stack Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
13.6 Resource Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
13.7 Event Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
13.8 Counter Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
13.9 Alarm Definition  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
13.10 Message Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
13.11 ISR Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
13.12 Different Application Modes Definition . . . . . . . . . . . . . . . . . .168
13.2 General
All objects that are contr o lled by the Operating System - tasks, 
resources, alarms, messages, counters, ISRs and even the OS itself - 
are considered as system objects. Each of them has its unique 
characteristics defined by the user. To specify parameters for each 
system object the special statements are used for each object. All 
statements are described below in detail.
Some parameters represents memory addresses. They are defined 
either automa tically or by the user. If the user does not need to control 
memory address such parameters should be omitted in definition 
statements. In this case SG automatically creates the code to allocate 

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

142 Syste m Objects Definition MO TORO LA

memory areas. If the user explicitly specifies the address then the

symbolic name (e.g. MyTaskStack) should be provided in the

corresponded position. This name must be defined in a user’s file (e.g.

an array can be defined for memory area) and declared as external

name before the generated source files will be used. Such techniques is

demonstrated in sample application, see Apppendix A Sample

Application.

13.3 OS Defin iti on

Description:

The object

Operating System

is the mandatory one for any

application. It defines OS and its properties for the application. The

keyw ord OS is used for this object type. See Section 3 Operating

System Architecture for more detailed information about OS. The

sample of Operating System definition is:

OS sampleOS {

CC = BCC2;

STATUS = STANDARD;

};

Below the list of all additional attributes which can be defined for an

object of the

type follows. Brief explanations are provided. This list is

divided into parts which correspond to appropriate system objects.

13.3.1 Global System Attributes

This group of attributes represents system features which are common

for the whole system.

• OSVERSION (ENUM)

Defines the version of OSEK OS specification which OS supports.

This attribute can have values 1 or 2. In the current OSEK OS

im plementation it is necessary to specify 2 as

OSVERSION

value.

• TargetMCU (ENUM)

Specifies the CPU type. Possible values are

HC08

HC12,

CPU32, MPC, MCORE

and

WINNT

Syste m Obje cts De fi n it ion

OS Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 14 3

NON-DISCLOSURE AGREEMENT REQUIRED

• DEBUG_LEVEL (ENUM)

Specifies the ORTI support in OS. The attribute can have values

0 or 1. If the system has the DEBUG_LEVEL = 0 the static ORTI

support is switched off. If the system has the DEBUG_LE VEL = 1

this mode is considererd to be a debudding mode (see

Section 18 ORTI Implementation for the details).

• ORTIR unnin gTask (BOOLE AN)

Specifies that the running task identi fication in run-time support

will be used. This attribute will be ignored if DEBUG_LEVEL = 0

(see Section 18 ORTI Implementation for the details).

• ORTICurrentService (BOOLEAN)

Specifie s that the OSEK OS system calls identificat ion in ru n-time

support will be used. This attribute will be ignored if

DEBUG_LEVEL = 0 (see Section 18 ORTI Implementation for

the detail s).

• HCBasePage (BOOLEAN)

Defi nes that the base memory page will be used for system

vari ables. This option may reduce the OS code size by means of

the di r ect ad dressing mo de usa ge whe n po ssi ble. T his is a target

specific attribute.

• HCBank Code (BOOLEAN)

Specifies that the banked memory model support will be used.

This is a target specific attribute. Defines that memory bank

switching is supported by the system.

• HCAltRegISR (BOOLEAN)

This attribute is only appli cable if

TargetMCU

MCORE

. It

specifies that Alternative Register File will be used for ISR

processing.

• CC (ENUM )

The CC attribute specifies the Conformance Class which is

supported by the OS. This attribute has the type ENUM. The

possible values are the following:

– BCC1

– BCC2

– ECC1

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

144 Syste m Objects Definition MO TORO LA

– ECC2

–AUTO

• STATUS (ENUM )

The

STATUS

attri bute specifie s the de bugging a bility of OS. I f the

system has the

EXTENDED

status some additional checks are

performed to detect run-time errors. This mode is considered to be

a debugging mode. Standard status OS performs only very limited

set of checks, the performance is increased and the amount of

consumed memory is decreased. Th is attribute has the type

ENUM. The possible values are the following:

– STANDARD

– EXTENDED

• SimpleS cheduler (BOOLEAN)

If the a ttribute is TRUE the simplified schedu le r will be u sed in the

system, if ea ch task has an unique priority and task multiply

activation mechanism is not used. It reduces the OS code and

increases system performan ce.

• UseMainStack (BOOLEAN)

If the attribute is TRUE the same stack area is used for the

main()

functi on (d uring start -up) , for the sched uler stack and for

the ISR stack, e.g. the effective top of stack is the top of stack

when OS startup is called within main(). Therefore, user should

avoid using of local variables in main() to keep top of stack as high

as possible.

• HCLowPower (BOOLEAN)

If the attri but e is TRUE an i nstruct ion that puts CP U in low power

mode is used instead of the scheduler’s idle loop.

•

HCLowPowerMode

(ENUM)

This attribute defines

LowPowerMode

which will be used by the

scheduler (for some targets) (see Section 15 HC12 Platform-

Specific Features for more information).

Syste m Obje cts De fi n it ion

OS Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 14 5

NON-DISCLOSURE AGREEMENT REQUIRED

• EntryExitISR (BOOLEAN)

If the attribute is FALSE it is assumed that there are no interrupt

service routines in the system at all and the Operating System

does not have any interrupt handling mechanisms. Interrupt

management services are not supported.

• InterruptMaskControl (BOOLEAN)

If the attribute is FALSE (while the EntryExitISR attribute is TRUE)

interrupt masks are not controlled by the operating system.

Services EnableInterrupt, DisableInterrupt, GetInterruptDescriptor

are not supported.

• NodeNumber (INT)

The attribute of the type INT specifies the maximum number of

tasks in the non- suspended state , available in the syste m. In fact,

this parameter specifies the number of task control blocks,

allocated in the system.

• Sched StackSize (INT)

The attribute of the type INT specifies the si ze (in bytes) of the

schedul er’s idle lo op stack. It should not b e less than the interr upt

stack frame. If the system property

UseMainStack

is set this

attribute (and

SchedStackAddress

also) is ignored.

• SchedStackAddress (STRING)

The attribute of the type STRING

specifies the bottom of the

schedul er stack. Th is addr ess ca n be def in ed e xplic itly to provid e

a way to optimize stack allocation. In this case it is pr esented as

an array of characters named by SchedStackAddress attribute

value. This array should be defined in a user’s source file and

declared in a user’s header which is to be included into the system

configuration source file (see Section 14.3.2 Source Files).

• MaxPrio (INT)

The attribute of the type INT specifies the number of task priorities

in the system. This parameter is ignored if the attribute

SimpleScheduler

is TRUE, since in this case it must be equal to

the number of tasks.

• NodeStackSize (INT)

The attribute of the type INT specifies the si ze of the stack (in

bytes) per each task node. The total size of the memory area for

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

146 Syste m Objects Definition MO TORO LA

task nodes’ stacks is defined as multiplication of this parameter by

the

NodeNumber

value. This parameter is ignored if the attribute

NodeStack

is FALSE.

• NodeStackAddress (STRING)

The attribute of the type STRING

specifies the bottom of task

nodes’ stacks. This ad dress ca n be de fined e xplicitly to pro vide a

way to op timize stacks allocation. In this case it is presente d as an

array o f char acters n amed by N odeStackA dd ress att ribute value.

This array should be defined in a user’s source file and declared

in a user’s header which is to be included into the system

configuration source file (see Section 14.3.2 Source Files). This

parameter is ignored if the attribute

NodeStack

is FALSE.

• UseCommonArea (BOOLEAN)

This attribute, if turned TRUE, causes system to reduce stack

usage for certain services (those ones requiring more stack

space). This leads to static memory objects (‘common area’) using

prior to stack space and could significantly reduce RAM space

overhead (see Section 15 HC12 Platform-Specific Features

for more information).

• CopyrightNotice (BOOLEAN)

The attribute specifies whether copyright notice should be

incorporated into OS ROM code.

• Reconfig (BOOLEAN)

If the option is turned on, the number of different application

modes (d ifferent sets of tasks) may be established in the same

OSEK OS application (see Section 11.6 Application Modes). In

this case it is possible to change application mode afte r system

shutdow n. If

Reconfig

option is set, then Extended OIL format

should be used to define application modes. If it is not necessary

to have a number of application modes in the same application,

then it is recommended to turn this property off. It decreases the

needed amount of RAM and increases execution speed.

Syste m Obje cts De fi n it ion

OS Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 14 7

NON-DISCLOSURE AGREEMENT REQUIRED

• ExtendedContext (BOOLEAN)

Def ines wh ether OS h as to sup port task conte xt e x tension or not .

Valid only if the target MCU has the corresponding hardware

support (MPC505) or it is necessary due to specific compiler

behavior (HC08).

• UseMoveBlockInstruction (BOOLEAN)

Defines whether OS has to use CPU memory move block

instructions or not. This attribute is intended for MPC only.

13.3.2 Task Related Attributes

This group of attributes controls task features.

• SCHEDULE

(ENUM)

The

SCHEDULE

attri bute specifie s the ki nds of schedu ling w h ich

are supported by the OS. This attribute allows for a cross-check of

the requirements of the tasks and the capabilities offered by the

operat ing system. Th e possibility of aut omatic assignment for this

attribute is supported. The possible values are the following:

–NON

–FULL

–MIXED

–AUTO

• MultiplyActivation (BOOLEAN)

The attribute controls the multiply activation ability for

Conformance Classes. I f the attribute is FALSE multiply activation

is disabled for tasks.

• TaskIndexMethod (BOOLEAN)

If the attribute is TRUE then the intermediate vector of the pointers

to tasks control blocks is used (fast and deterministic access to

task nodes).

• NodeStack (BOOLEAN)

The attr ibute defines the presence of task node stacks in the

system. If it is FALSE ther e are no task node stacks impl emented.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

148 Syste m Objects Definition MO TORO LA

• StackPool (BOOLEAN)

The attribu te d efines the prese nce o f sta ck poo ls in the system. If

it is FALSE there are no stack pools implem ented.

• PersistentNode (BOOLEAN)

If the attribute is TRUE a persistent task control block may be

assigned to the task.

• PersistentStack (BOOLEAN)

If the attribute is TR UE a per sistent stack b uffer ma y be assigne d

to the task.

• TaskOwnStack (BOOLEAN)

The attribute defines that a task may have its own stack.

• UseSameContext (BOOLEAN)

If the attribute is TRUE the same run time context fram e is used

both for non-preemptive and preemptive tasks in mixed-

preemptive systems.

• TaskBasePage (BOOLEAN)

If the a ttribute is TRUE, th e task control blocks are place d into the

base page memory. It increases the system performance since

CPU accesses the base page faster than extended memory. In

this case the user is responsible for the needed amount of RAM in

the base page for the desi red number of task nodes.

• ChainTaskItself (BOOLEAN)

The attr ibute can be set as F ALSE if no tasks that chain itself. It

decreases the task control block size.

• NonPreemptCtxRegNum (INT)

The attribute specifies the number of extended registers to be

included into non-preemptive task context. It should contain value

from 1 till 18. Intended for MPC505 only. Valid only if

ExtendedContext

= TRUE.

• SaveNonPreemptCtxExt (STRING)

The attribute specifies the assembler macro for saving extended

registers into non-preemptive task context. It should be a STRING

which contains inline assembler statements for saving extended

registers. Intended for MPC505 only. Valid only if

ExtendedContext

= TRUE.

Syste m Obje cts De fi n it ion

OS Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 14 9

NON-DISCLOSURE AGREEMENT REQUIRED

• RestoreNonPreemptCtxExt (STRING)

The attribute specifies the assembler macro for restoring

extended registers from non-preemptive task context. It should be

a STRING which contains inline assembler statements for

restoring extended registers. Intended for MPC505 only. V alid

only if

ExtendedContext

= TRUE.

• PreemptCtxRegNum (INT)

The attribute specifies the number of extended registers to be

included into preemptive task context. It should contain value from

1 ti ll 1 8. Intended f or MPC50 5 only. Vali d only if

ExtendedContext

= TRUE.

• SavePreemptCtxExt (STRING)

The attribute specifies the assembler macro for saving extended

registers into pr eemptive task context. It should be a STRING

which contains inline assembler statements for saving extended

registers. Intended for MPC505 only. Valid only if

ExtendedContext

= TRUE.

• RestorePreemptCtxExt (STRING)

The attribute specifies the assembler macro for restoring

extended registers from preemptive task context. It should be a

STRING which co ntains inl ine assemble r stateme nts for r estoring

extended registers. Intended for MPC505 only. Valid only if

ExtendedContext

= TRUE.

13.3.3 Interrupt Related Properties

This group of attributes defines parameters of ISR execution.

• IsrStackSize (INT)

The attribute of the type INT specifies the size (in bytes) of the ISR

stack. If the attribute

UseMainStack

is TRUE this attribute (and

ISRStackAddress

also) can be omitted.

• IsrStackAddress (STRING)

The attribute of the type STRING specifies the bottom of the ISR

stack. This address can be defined explicitly to provide a way to

optimize stack allocation. In this case it is present ed as an array of

characters named by IsrStackAddress attribute value. This array

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

150 Syste m Objects Definition MO TORO LA

should be defined in a user’s source file and declared in a user’s

header which is to be included into the system configuration

source file (see Section 14.3.2 Source Files).

• DisableInterruptMask (INT)

The attribute of the type INT specifies the value of the interrupt

mask, which corresponds to all interrupts disabled.

• EnableInterruptMask (INT)

The attribute of the type INT specifies the value of the interrupt

mask, which corresponds to all interrupts enabled.

• TaskLevelMask (INT)

The attribute of the type INT specifies the value of the interrupt

mask, whi ch, typicall y, corre sponds to the middle l evel of enab led

interrupts in the system.

• InitialMask (INT)

The attribute of the type INT specifies the value of the interrupt

mask, which, typically, corresponds to the initial level of enabled

interrupts during the system startup.

• ISRCateg ory1 (BOOLE AN)

The a ttribute spe cifies wheth er the IS R of categ ory 1 is support ed

by OS or not. Currently this attribute does not affect OS code.

• ISRCateg ory2 (BOOLE AN)

The a ttribute spe cifies wheth er the IS R of categ ory 2 is support ed

by OS or not. Currently this attribute does not affect OS code.

• ISRCateg ory3 (BOOLE AN)

The a ttribute spe cifies wheth er the IS R of categ ory 3 is support ed

by OS or not.

• ISRCtxRegNum (INT)

The attribute specifies the number of extended registers to be

saved into ISR stack frame. It should contain value from 1 till 18.

Intended for MPC505 only, not implemented yet. Valid only if

ExtendedContext

= TRUE.

• SaveISRCtxExt (STRING)

The attribute specifies the assembler macro for saving extended

registers into ISR stack frame. It should be a STRING which

Syste m Obje cts De fi n it ion

OS Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 15 1

NON-DISCLOSURE AGREEMENT REQUIRED

contains inline assembler statements for saving extended

registers. Intended for MPC505 only, not implemented yet. Valid

only if

ExtendedContext

= TRUE.

• RestoreISRCtxExt (STRING)

The attribute specifies the assembler macro for restoring

extended registers from ISR stack frame. It should be a STRING

which contains inline assembler statements for restoring extended

registers. Intended for MPC505 only, not implemented yet. Valid

only if

ExtendedContext

= TRUE.

• UnorderedExceptions (BOOLEAN)

The attribute allows handling of unordered exceptions. Intended

for MPC only.

13.3.4 Resource s and Events Related Attributes

The attributes control resources and events.

• Reso urces (BOOLE AN)

This attribute defines whether resource management is provided

by OS or not.

• FastResource (BOOLEAN)

The attr ibute can be specified by the user to increase the system

performance. If it is TRUE the system will work faster. But this

attribute may be used only for debugged applications, because

errors related to incorrect access and priority are not signalled. If

this attribute is TRUE less amount of ROM and RAM is needed for

resources. But, if resource priorities have a big difference (e.g. first

resource has priori ty 1 and the second resource has priority 20)

this attribute does not lead to RAM saving.

• ResourceAccessCheck (BOOLEAN)

Defines whether E_OS_ACCESS error code is returned by

GetResource

service or not. If it is TRUE, then error code will be

returned in EXTENDED status based on task definition in OIL-file.

If the system has STANDARD status or FastResource pr operty

turned on or more than 8 resources (including Scheduler) are

defined in application, then this attribute should be set to FALSE.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

152 Syste m Objects Definition MO TORO LA

• Events (BOOLE AN)

This attribute defines whether event management is provided by

OS or not.

13.3.5 Counters and Alarms Related Attrib utes

This group of attributes controls counters and alarms features.

• Counters (BOOLEAN)

Thi s attribute defines whether cou nters are provi ded by OS or not.

• CounterSize (ENUM)

This attribute d efines the size o f all count ers. The va lid values are

8, 16 and 32 which conform to byte, word and long word size of

counters.

• Alarms (BOOLEAN)

This attribute defines whether alarms are provided by OS or not.

• AlarmList (BOOLEAN)

If the attribute is TRUE the running alarms are linked into a list

which decreases the time for alarm handling.

• AlarmDeltaList (BOOLEAN)

If the option is turned on the running alarms are linked into ordered

alarm delta-list which significantly decreases the time for

CounterTrigger

servi ce if too m uch alarms are connect ed with t he

same counter (more than 10). The time for alarm management

services like

SetAbsAlarm

SetRelAlarm

GetAlarm

will be

increased.

•

CyclicAlarm

(BOOLEAN)

If the option is turned on, the cyclic alarms are supported.

Otherwise, no one alarm may be cyclic, which decreases RAM

usage for alarm control blocks, as well as decreases code usag e

and advances timing of alarms services. This option is turned on

by default .

Syste m Obje cts De fi n it ion

OS Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 15 3

NON-DISCLOSURE AGREEMENT REQUIRED

•

MinAlarmRAM

(BOOLEAN)

If the option is turned on, the alarm handling is optimized for

memory (RAM). Otherwise, alarm handling is optimized for speed.

When turned on, the alarm control block is significantly decreased,

especially when

AlarmList

option is turned off.

• TimerHard ware (ENUM)

This attribute is i ntended to select the hardware interrupt source

for the system counter (among the acce ssible MCU devices). See

Section 15 HC12 Platfo rm-Specific Features and

Apppendix E Quick Reference for details about possible

meanings of these parameters.

• SysTimer (BOOLEAN), Prescaler (BOOLEAN), PrescalerValue

(INT), TimerModulo (BOOLEAN), TimerModuloValue (INT)

The set of parameters to tune the selected hardware interrupt

source is introduced:

SysTimer

Prescaler

PrescalerValue

TimerModulo

TimerModuloValue

. One or more parameters can be here in

accordance with the hardware features. For more details see

Section 15 HC12 Platfo rm-Specific Features. This

parameter(s) can be omitted.

13.3.6 Messages Related Attributes

These ar e additional attributes to control local messages.

• UnqueuedMessages (BOOLEAN)

The attribute allows Unqueued Messages in the system.

• UnqueuedMsgDefaultValue (BOOLEAN)

The attribute allows Unqueued Messages to have default values.

• QueuedMessages (BOOLEAN)

The attribute allows Queued Messages in the system.

• QueuedMsgOneToN (BOOLEAN)

If the attribute is TRUE, 1:N Queued Messages are allowed.

• Activate OnMsg (B OOLEAN)

If the attribute is TRUE task activation on message arrival is

supported.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

154 Syste m Objects Definition MO TORO LA

• AlarmOnMsg (BOOLEAN)

If the attribute i s TRUE a n a larm can be l inked to m essage ar rival.

• SetEv entO nMsg (B OOLEAN)

If the attribute is TRUE event setting is allowed on message

arrival.

13.3.7 Hook Rout ine s Relate d Attr ibutes

These attributes define hook r outines support in the system .

• ErrorHook (BOOLEAN)

If the attribute is TRUE the user’s hook for error handling is

supported by the system (the

ErrorHook

hook routine).

• PreTaskHook (BOOLEAN)

If the attribute is TRUE the user’s hook for context switching is

supported by the system (the

PreTaskHook

hook routine).

• PostTaskHook (BOOLEAN)

If the attribute is TRUE the user’s hook for context switching is

supported by the system (the

PostTaskHook

hook routine).

• StartupHook (BOOLEAN)

If the attribute is TRUE the user’s hook is called by the system at

the en d of the system initializa tion (the

StartupHook

hook routin e).

• ShutdownHook (BOOLEAN)

If the attribute is TRUE the user’s hook is called by the system

when the OS service ShutdownOS has been called (the

ShutdownHook

hook routine).

• IdleLoopHook (BOOLEAN)

If the attribute is TRUE the user’s hook to be called from scheduler

idle loop is supported by the system (the

IdleLoopHook

hook

routine).

• InternalErrorHandler (BOOLEAN)

The attribute defines whether the internal error handler is

implemented.

Syste m Obje cts De fi n it ion

OS Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 15 5

NON-DISCLOSURE AGREEMENT REQUIRED

• UserCommand1 (STRING)

The attr ibute defi nes entry point of th e user's hook #1 to be called

from the OS Dispatcher thread (for OS/NT with interrupt emulation

only).

• UserCommand2 (STRING)

The attr ibute defi nes entry point of th e user's hook #2 to be called

from the OS Dispatcher thread (for OS/NT with interrupt emulation

only).

• UserCommand3 (STRING)

The attr ibute defi nes entry point of th e user's hook #3 to be called

from the OS Dispatcher thread (for OS/NT with interrupt emulation

only).

13.3.8 OS Service Relate d Attribut es

The group of attributes is designed to exclude pa rticular OS services. All

these attributes has the BOOLEAN type. If an attribute is FALSE the

corresponded service is excluded from the OS code. Names of these

at tributes are t he same as corr espondi ng OS service names. E.g ., if the

at tribute

InitCounter

is set as FALSE it means that this service will be

unavailable in an application. This is the list of such attributes:

• Task management services:

ActivateTask, TerminateTask,ChainTask,

ChainTaskItself, Schedule, GetTaskId, GetTaskState,

GetTCBInfo

• Resource management services:

GetResource, ReleaseResource

• Event management services:

SetEvent, ClearEvent, GetEvent, WaitEvent

• ISR management services:

EnterISR, LeaveISR, EnableInterrupt, DisableInterrupt,

GetInterruptDecsriptor

• Counter related services:

InitCounter, CounterTrigger, AdvanceCounter,

GetCounterValue, GetCounterInfo

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

156 Syste m Objects Definition MO TORO LA

• Alarm related services:

SetRelAlarm, SetAbsAlarm,CancelAlarm, GetAlarm,

GetAlarmBase

• Communication services:

SendMessage, ReceiveMessage, GetMessageResource,

Rele aseMe ssageReso urce, GetMe ssageS tatu s

• Execution contro l:

GetActiveApplicationMode, ShutdownOS

13.4 Task Definit ion

Description:

This statement is used to define task data. Several statements can be in

the configuration file, each statement defines one task.

This object presents a task. Attributes of this object type define task

properties. Links with other system objects are defined via references.

The keyword TASK is used for this object type. See Section 4 Task

Management for more detailed informati on about OSEK tasks. The

sample of a task definition is:

TASK TaskA {

TYPE = EXTENDED;

PRIORITY = 2;

SCHEDULE = NON;

ACTIVATION = 5;

STACKSIZE = 64;

AUTOSTART = TRUE;

EVENTS = { event1, event2, event3 };

};

13.4.1 Ob ject Attribu tes

The object has the following attributes:

• TYPE (ENUM)

This attri bute h as the type EN UM. The OS E K task may be on e of

the following types:

– BASIC

Syste m Obje cts De fi n it ion

Task Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 15 7

NON-DISCLOSURE AGREEMENT REQUIRED

– EXTENDED

• PRIORITY (INT)

The priority of the task is defined by the value of the

PRIORITY

attribute. The bigge r value of the

PRIORITY

attribute corresponds

to the higher priority. This attribute has the INT type. The default

value range is from 0 to 255.

• SCHE DULE (ENUM)

The r un-time be havior of th e task is d efined by this a ttribute. If the

task may be preempted by another one at any point of execution

- this task attribute shall have the

FULL

valu e (preempti ve task) . If

the task can be preempted only at specific points of execution

(explicit rescheduling points) the attribute shall have the

NON

value (non-preemptive task). This attribute has the type ENUM

with the values:

–FULL

–NON

• ACTIVATION (INT)

The ma ximum number of registered activation requests for the

task. This attribute has the INT type. The default value range is

from 1 to 255. The maximum number can be constrained in the

implementation specific definition part. The value 1 means that a

task cann ot be m ultiple activated, on ly single activatio n is all owed.

• STACKSIZE (INT)

This attri bute d efines t he size o f the ta sk stack. It depe nds on the

CPU family and functionality of the t ask. The attribute has the type

INT. No default value range is defined. The maximum stack size

can be constrained by the implementation.

• AUTOSTART (BOOLEAN)

This attribute determines whether the task is activated during the

system start-up procedure or not. It has the BOOLEAN type, so

the possible values are TRUE and FALSE.

• StackMethod (ENUM)

This attribute specifies the stack allocation method. The attribute

(the ENUM type) has three available values.

NODESTACK

means

that task node stack is implicitly assigned to be used by the task

(during the task activation).

POOLSTACK

means that a stack

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

158 Syste m Objects Definition MO TORO LA

should be dynamically allocated to the task from the stack pool

during task activation.

OWNSTACK

(the default attribute value)

means that a stack is explicitly assigned to the task (in this case

the address of the top of the stack will be calculated by the sy stem

generation utility). Note that to get a correct OIL file the value must

correspond to the appropriate OS attribute (

NodeStack

StackPool

and

TaskOwnStack

• StackAddress (STRING)

The attribute of the type STRING

speci fies the bott om of the task

stack. This address can be defined explicitly to provide a way to

optimize stack allocation. In this case it is present ed as an array of

characters named by StackAddress attribute value. This array

should be defined in a user’s source file and declared in a user’s

header which is to be included into the system configuration

source file (see Section 14.3.2 Source Files).

• MemoryBank (INT)

The attribute (INT type) defines the memory bank for the task

code.

• InterruptMask (INT)

The attri bu te (I NT type) define s the star ting task’s interrup t m ask.

If this par amete r is omitted, then the val ue of the

TaskLevelMask

attribute is used

• PersistentNode (BOOLEAN)

If the attribute is TRUE a persistent task node is assigned to the

task.

• PersistentStack (BOOLEAN)

If the a ttribut e is TRUE a p ersisten t stack buffer is assigned to the

task.

13.4.2 Object References

A task in OSEK OS has the set of allowed references. A reference is

presented as the symbolic name of an obje ct that is referenced to by the

task. The following references are allowed:

Syste m Obje cts De fi n it ion

Stack Defi n it ion

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 15 9

NON-DISCLOSURE AGREEMENT REQUIRED

• RESOURCE (multiple)

If the task accesses a resource at run-time this re source shall be

poi nted. Th e resource Ce iling priori ty is calcul ated as the highe st

priority of tasks accessing this resource (or higher one).

• EVENT (multiple)

An exten ded task can have a set of events. The se events can be

cleared and waited for by the task. All task events shall be pointed

to defi n e the event mask in case of a uto-a ssi gnme nt ( see sec tion

Section 13.7 Event Definition).

• MESSAGESENT (multiple)

If a task sends a message (has wr ite access to a message) this

message shall be sp ecified a s the r efer ence. T he sym bolic na me

of the message shall be pointed.

• MESSAGERECEIVED (multiple)

If a task rece ives a message (has rea d access to a message) this

message shall be sp ecified a s the r efer ence. T he sym bolic na me

of the message shall be pointed.

NOTE:

It is not mandatory to reference message s which are sent or received by

the ta sk. But it is r ecommended to do to simplify a pplication consistency

verification and to eliminate possible errors, especially in case of 1:N

communication.

• StackPool (single)

If a task uses the stack from a stack pool the reference to the

dedi cated stack pool mu st be pr ovided. T he symbolic name o f the

stack pool shall be pointed.

NOTE:

If a task uses a stack from the stack pool the value of the task attribute

STACKSIZE is ignored.

13.5 Stack Definition

Description:

This statement is used to define stack pool data. Several statements can

be in the configuration file, each statement defines one pool. The

keyw ord for this ob ject is STACK. See Section 4.7.4 Task Stack for

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

160 Syste m Objects Definition MO TORO LA

more information about the task stack. The sample of a stack definition

is:

STACK StackTaskA {

StackSize = 128;

NumberOfStacks = 5;

StackAreaAddress = 0x400;

};

13.5.1 Ob ject Attribu tes

The attri bu tes o f the STA CK obj ect reflect these physica l par amet ers of

a pool. They are:

• StackSize (INT)

The attribute represents the size of a stack buffer, it has the type

INT.

• NumberOfStacks (INT)

The attribute corresponds the number of buffers in the pool, it also

has the type INT.

• StackAre aAddress (STRING)

The attrib ute speci fies the start address of the pool mem ory area

and it has the type STRING. This optional parameter serves for

explicit memory allocation for the task stack pool.

13.6 Resource Definition

Description:

This object is intended for the resource management. The resource

object has no standard attributes and references. The resource

Ceiling

priority

is calculated automatically on the basis of information about

priorities of tasks using the resource. The keyword RESOURCE is u sed

for this object type. Section Section 7 Resource Management

describes r e source concept in OSEK. The sample of a resource

definition is:

RESOURCE ResAccess {

};

Syste m Obje cts De fi n it ion

Event Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 16 1

NON-DISCLOSURE AGREEMENT REQUIRED

13.6.1 Ob ject Attribu tes

The object has the following attributes:

• PRIORITY (INT)

The priority of the resource is defined by the value of the

PRIORITY

attribute. The bigger value of the

PRIORITY

attribute

corresp onds to the higher priority. Th is attribute has the INT type.

This attribute has the possibility of automatically assignment. In

this case the resource

Ceiling priority

is calculated automatically

on the basis of information about priorities of tasks using the

resource.

13.7 Event Definition

Description:

Thi s object i s intended for the eve nt managem ent. The event object has

no ref erenc es. The keywo rd EVENT is used for thi s object type. Section

Section 9 Events describes events in OSEK. The sample of an event

definition is:

EVENT event1 {

MASK = 0x01;

};

13.7.1 Ob ject Attribu tes

• MASK (INT)

The event is represented by its mask. The attribute has the type

INT. The event mask is the number which range can be defined in

the implementation specific definition part. The other way to

assign event mask is to declare it as

AUTO

. In this case event

masks will be assigned automatically accord ing to their

distribution among the tasks.

13.8 Counter Definition

Description:

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

162 Syste m Objects Definition MO TORO LA

This object presents OSEK Operating system counters. Attributes of this

obj ect type define coun ter pr oper ties. A counter has no refer ences, it is

referenced to by other object. The keyword COUNTER is used for this

object type. OSEK counters are described in section

Section 8.3 Counters. The sample of a counter definition is:

COUNTER Timer {

MINCYCLE = 16;

MAXALLOWEDVALUE = 128;

TICKSPERBASE = 90;

};

13.8.1 Ob ject Attribu tes

The object has the following standard attributes:

• MAXALLOWEDVALUE (I NT)

The attribute defines the maximum allowed counter value. When

the counter reaches this value it rolls over and starts count again

from zero. The attribute has the type INT.

• MINCYCL E (INT)

The attribute specifies the minimum allowed number of counter

ticks for a cyclic alarm linked to the counter. (In fact, this parameter

has a sense only for systems with extended OS status since it is

checked in this case only.) The attribute has the type INT.

• TICKSPERBASE (INT)

For the system timer (if specified) this is the number of ticks that

are required to reach 10 milliseconds. This value cannot be

derived automatically from other counter related attributes (see

also

PrescalerValue

TimerModuloValue

Sect ion 13.3 . 5 Count er s and Al arms Relat e d Att ribut es

). For

the rest counters this attribute specifies the number of ticks

requi red to reach a counter- specific value (th e interp retation is up

to the user). The attribute has the type INT.

• TICKDURATION (INT)

For the system timer (if specified) this is the duration of a tick in

nanoseconds. The attribute has the type INT.

Syste m Obje cts De fi n it ion

Alarm Definiti on

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 16 3

NON-DISCLOSURE AGREEMENT REQUIRED

• SystemTimer (BOOLEAN)

This attribute specifies whether the counter is the system timer. By

default this attribute has the value FALSE. Note, however, that

only one counter must be defined as the system timer.

13.9 Alarm Definition

Description:

This object presents OS alarms. An al arm has no standard attributes.

Links with other system objects are defined via re fer ences. The

referenced counter and task must be already defined.The keyword

ALARM is used for this object type. See section Section 8.4 Alarms for

information about alarms. The sample of an alarm definition is:

ALARM WakeTaskA {

ACTION = SETEVENT;

COUNTER = Timer;

TASK = TaskA;

EVENT = event1;

};

13.9.1 Object References

An alarm has the following allowed references :

• ACTIO N (single)

This attribute has the type ENUM. The

ACTION

may b e one of the

following types:

– ACTIVATETASK

– SETEVENT

• COUNTER (single)

An alarm shall be assigned to a particular counter to have an

ability to operate.

• TASK (single)

The reference points to a task which is to be notified via activation

or event setting when the alarm expires.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

164 Syste m Objects Definition MO TORO LA

• EVENT (single)

An event which is to be set when the alarm expires is pointed here.

The event is considered as an inseparable pair of the task and the

event belonging to this task, so the reference to the task which

owns the events shall be also defined for this alarm.

13.10 Message Definitio n

Description:

This object is intended to present either a Unqueued or an Queued

message. Attributes of this object type de fine message prop erties. Links

with other system objects are defined via references. The keyword

MESSAGE is used for this object type. Messages concept is described

in section Section 10 Communication. The sample of a message

definition is:

MESSAGE Msg4TaskA {

TYPE = UNQUEUEDMESSAGE;

ITEMTYPE = "int";

ITEMS = 1;

ALARMRESETTIME = 20;

ALARMRESET = DrvAlarm;

ACTION = SETEVENT;

TASK = TaskA;

EVENT = event1;

};

13.10.1 Object Attribu tes

The object has the following attributes:

• ACTION (ENUM)

This attribute has the type ENUM. The

ACTION

may b e one of the

following types:

– ACTIVATETASK

– SETEVENT

–NONE

Syste m Obje cts De fi n it ion

Message Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 16 5

NON-DISCLOSURE AGREEMENT REQUIRED

• TYPE (ENUM)

In accord ance w ith t he OS EK spe cifica tion the re ar e two typ es of

message s:

Unqueued

and

Queued

. The possible value of this

attribute are the following:

–

UNQUEUEDMESSAGE

–

QUEUEDMESSAGE

• ITEMTYPE (STRING)

The message item can have the own type which has to be any C

data type. Any ANSI-C type speci fier is a llo wed. I t i s th e sta ndar d

C type identifier -

char

int

float

double

with any type

modifiers (

signed, unsigned, short, long

) and also

structure or union specifier (starting

struct

union

), enum

specifier (starting

enum

typedef

name (any valid C-language

identifier) enclosed in the double quotas. To use an array of

standard C-language type the user must define the new type via

typedef

operator. In case of user’s defined data types or

enumerations such definitions must be in the user’s code before

using files produced by SG

• ITEMS (INT)

The queued message can have more than one item. This attribute

specifies the capacity of the FIFO queue, i.e. the number of

message items into the FIFO queue. The unqueued message

always has only one item.

• ALARMRESETTIME (INT )

Alarm can be assigned to a message which is restarted at

message arrival (alarm restart wil l happen as a result of

SendMessage

service execution). The time period for this alarm is

defined by this attribute. The units are ticks of the counter

assigned for the alarm.

• StartupAlarm (BOOLEAN)

This attribute specifies whether the alarm referenced by the

message must be restarted during system start-up. By default this

attribute has the value

FALSE, it means that the alarm is not

restarted during start-up. Restarting of the alarm may be used to

trap the loss of the first message.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

166 Syste m Objects Definition MO TORO LA

• DefaultValue (STRING)

This attribute presents the address of the ROM-based variable,

which holds the default value of the unqueued message. This

variable must have the typ e

, and must be located in

the user’s code. The parameter may be omitted.This attribute is

intended for unqueued messages only.

• ReceiverNum (INT)

The attribute defines the number of local task-receivers of the

message . If it has a value gre ater tha n 1, then it is assumed, that

several tasks may receive a message item from the message

queue.

• WithCopy (BOOLEAN)

The attribute defines that unqueued message is used with copy

(TRUE) or without copy (FALSE).

13.10.2 Object References

A me ssage in OS EK OS has the set of a llow ed re fere nces. A re fere nce

is presented as the symbolic name of an object that is referenced to by

the message. The following references are allowed (identified via

keywords):

• ALA RMRE SET (si ngle)

The reference points to an alarm which is to be resta rted when the

message arrives (alarm restart will happen as a result of

SendMessage

service execution).

• TASK (single)

The reference points to a task which is to be notified via activation

or event setting when the message arrives.

• EVENT (single)

An event which is to be set when the alarm expires is pointed here.

The event is considered as an inseparable pair of the task and the

event belonging to this task, so the reference to the task which

owns the events shall be also defined for this message.

Syste m Obje cts De fi n it ion

ISR Definiti on

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 16 7

NON-DISCLOSURE AGREEMENT REQUIRED

13.11 ISR Definition

Description:

This object presents an Interrupt Service Routine. The keyword ISR is

used for this object type. The sample of an Interrupt Service Routine

definition is:

ISR TimerISR{

CATEGORY = 2;

}

13.11.1 Object Attribu tes

This object has the following attributes:

• CATEGORY (ENUM)

Specifies category of the Interrupt Service Routine. Possible

values are: 1, 2 or 3 (see Section 6.4 ISR Categories for

Interrupt Service Routine Categories details).

• TYPE (ENUM)

This attribute is only valid if

TargetMCU

global system attr ibute is

MCORE

and

HCAltRegISR

global system attribute is TRUE. It

chooses between Fast Interrupt exception and all other

exceptions. The possible values of this attribute are the following:

–FAST

–NORMAL

13.11.2 Object References

• MESSAGESENT (multiple)

Only a message which is sent by ISR can be referenced. If ISR

sends a m essage (has write access to a message) this one shall

be specified as the reference. The symbolic name of the

appropriate message object shall be pointed.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

168 Syste m Objects Definition MO TORO LA

13.12 Diff erent Applicati on Modes Definitio n

Description:

It is possible to introduce different application modes inside one CPU

container by means of additional container object named

CFG

(confi gu ration ). This object is introd uced in Extended OIL format (see

Section 12.4.3 Extended OIL Format).

A set of CFG statements can be represented inside one CPU to

establish different application modes. The CFG statement contains a set

of objects. To define application mode it is necessary to collect

application mode dependent tasks inside correspond ing CFG

statement. It is possible to share a task between different application

modes. In this case it is necessary to include corresponding task

definition into all affected CFG objects. The CFG statement has the

syntax similar to CPU syntax.

All application modes should be enumerated in special

CFGACTIVE

statement located inside the scope of corresponding CPU.

The following is the OIL example of CPU description with two application

modes and five tasks. Task

code is shared between application

modes.

OIL_VERSION = "2.0e"; /* Force SG to use Extended */

/* OIL format */

INCLUDE “mot20.oil”

CPU cpu1 {

CFGACTIVE = { ModeA, ModeB }; /* Two application modes */

/* “ModeA”, “ModeB” are */

/* defined */

....

CFG ModeA { /* Application mode “ModeA” */

TASK TC { ... }; /* TC code is shared between both modes */

TASK TA1 { ... }; /* ModeA specific task TA1 */

TASK TA2 { ... }; /* ModeA specific task TA2 */

};

CFG ModeB { /* Application mode “ModeB” */

TASK TB1 { ... }; /* ModeB specific task TB1 */

TASK TC { ... }; /* TC code is shared between both modes */

TASK TB2 { ... }; /* ModeB specific task TB2 */

};

STACK POOL { ... }; /* Stack pool definition */

COUNTER Timer { ... };/* Counter definition */

Syste m Obje cts De fi n it ion

Dif ferent Application Modes Definition

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA S ys tem Obj ects Definition 16 9

NON-DISCLOSURE AGREEMENT REQUIRED

ALARM Alarm { ... }; /* Alarm definition */

....

};

A task may have different properties in different application modes. Only

TASK stateme nts may be used insi de CFG object in case of appli cation

mode definition. See Section 17.9.5 Examples of Application Modes

Usage for details regarding different application modes definition.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Objects Definition

User’s Manual OSEK Opera ting System — Re v 1.2

170 Syste m Objects Definition MO TORO LA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTO ROLA Building of Application 171
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 14. Building of Application
14.1 Contents
14.2 Application Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
14.3 Action Se quence to Bu ild an Application . . . . . . . . . . . . . . . .172
14.4 Sample Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
14.2 Application Structure
An application developed on the OSEK Operating System basis has a 
defined structure. An application consists of the Operating System 
kernel a nd se veral u ser’s t asks and  ISRs, which in teract with th e ker nel 
by means of system services and internal mechanisms. ISRs receive 
control from hardware interrupt sources via the vector table. Ta sks ar e 
controlled by the scheduler. They may use all means for intertask 
communications granted by OSEK OS to pass data and synchronize 
each other.
Tasks and ISRs are considered as system objects. Resources, 
Unqueued and Queued messages, counters, and alarms are also 
considered as system objects, because they are controlled by the 
Operati ng System.  An app lica tion typicall y also has con figurati on tables 
for different system objects, stack buffer pools and other entities. To 
create an application, the user should develop the desired application 
structure with all necessary objects and define interactions between 
them. 
All global Operating System properties, system objects and their 
param eters ar e defi ned b y the u ser stati cally  and can not be  redefined  at  
run time. Special application configuration file is designed to perform 
such definition and the special tool that processes this file. See 
Sect ion 12 Sys tem Co nfigurat ion. After  processing,  files with system  

NON-DISCLOSURE AGREEMENT REQUIRED

Building of Application

User’s Manual OSEK Opera ting System — Re v 1.2

172 Building of Application MOTORO LA

object descriptors are created automatically. These files provide the

code for all required ROM and RAM structures, arrays, tables, variables,

etc. for all system objects defined in the configuration fi le. Memory

allocation is performed during start-up procedure.

14.3 Action Sequen ce to Bui ld an App licat ion

To build an application using the OSEK Operating System the user

should perform a set of actions. These actions are relatively simple since

the most important requirement is a clear understanding of the

application’s algorithm. The actions include creating the application

configuration file, processing this fi le by the System Generator, writing

the user’s source code, compiling all files and linking the application files

togethe r with th e OSEK OS code . This proce ss is shown in Figure 14-1.

Building of Application

Act ion Sequence to Build an Application

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA Building of Application 173

NON-DISCLOSURE AGREEMENT REQUIRED

Figure 14-1. Application building process

14.3.1 Application Configuration

Applications built using OSEK OS are configured statically via the

special configuration file written in OIL. Section 12 System

Configuration describes the structure of such file and

Section 13 System Objects Definition describes all possible

statements in detail. This configuration file defines system specific

parameters as well as system objects. Such a file can have any

extension and the extension “.oil” is suggested by default.

The configuration file has to be processed by the special utility named

System Generator (SG). This utility is delivered as one of the parts of the

Application

configuration

file

System

Generator

User’s source

code

OSEK

OS kernel

Compiler

Linker

Executable file

Files produced by SG

– user def ined files

– OSEK Op erating

System components

– files pr oduced by SG

– developmen t software

NON-DISCLOSURE AGREEMENT REQUIRED

Building of Application

User’s Manual OSEK Opera ting System — Re v 1.2

174 Building of Application MOTORO LA

OSEK Operating System. This tool runs as a simple MS-DOS

application and produces header and source files.

The following command is used to run SG:

sysgen [-options] oil_file

The following command line options are intended to control SG:

The location of the property template file can be pointed either in

command line or via the SYSGEN_TEMPLATE environment variable.

In addition to command line op tion the OSB_INCLUDE_DIR

environment variable can be used to specify the set of directories to

search for include files.

The SG utility produces three types of standard C-language files which

are to be compiled and linked together with OS kernel code and user’s

source code:

1. The header file which describes the current configuration of the

operating system, in other words, system properties. This file

contai ns the preprocesso r directi ves

#define

and

#undef

. This

file is used at compile time to build the OS kernel with the specified

properties. The default filename is “osprop.h” but the user can

Table 14-1. System Generator command line options

Option Description Default value

-c* Defines * as the data file name Input file name with “. c” extension

-h* Defines the header file name Input file name with “.h”

extension

-i* D efines the path for include files No

-n* Defines * as the name of CPU for which output files are

generated Fi rst CP U in th e file

-o For su pporting back ward compatibi lity previous version of

SG utility which treats the lesser value as the higher priority No

-p* Defines the property file name “ osprop. h”

-t* Defines the pathname for property template file “osprop.tpl”

-v For verification mode only. When this option is defined the

generation is not performed No

Building of Application

Act ion Sequence to Build an Application

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA Building of Application 175

NON-DISCLOSURE AGREEMENT REQUIRED

assign another name (see Section 14.3.2 Source Files).

2. The header file which contains definitions of data types and

constants, and external declara tions of variab les which are

needed to describe system objects. This file is used to compile

application files. By default, System Generator uses the input file

name for this output file with “.h” extension.

3. The sour ce file which contains initialized data and memory

allocation fo r system objects. This file is compiled with “osprop. h”

and other header files and then linked together with other

application and OS files. By default, System Generator uses the

input file name for this output file with “c” extension.

NOTE:

As a ru le, the user is not allowed to edit files produced by the System

Generator. It may lead to data inconsistency, compilation errors or

unpredictable application behavior.

14.3.2 Source Files

OSEK Operating System is delivered to the user as a set of source files.

Header and source files of the Operating System are located in the

predefined directories after OSEK OS installation, as i t is described in

Section 2.5.2 Installation. Paths to these directories have to be

provided by the user.

The OS source code is compiled and linked togethe r with other

application’s files. The header file “osprop.h” describing system

properties defines which functionality will have the OS kernel in run time.

This file must be included in all user’s and OS’ source files. Since the

user can specify another name for this file the special macro

OSPROPH

is designed to substitute the name. The following code can be used in all

user’s files (it is used in all OS source files):

#if !defined (OSPROPH)

#include <osprop.h>

#else /* !defined (OSPROPH) */

#include OSPROPH

#endif /* !defined (OSPROPH) */

The compiler command line (see Section 14.3.3 Compiling and

Linking) in thi s case should have the option like this:

NON-DISCLOSURE AGREEMENT REQUIRED

Building of Application

User’s Manual OSEK Opera ting System — Re v 1.2

176 Building of Application MOTORO LA

-dOSPROPH="<filename>".

is the name of the file with system pr operties definitions.

But the user is allowed to use some other method to include t he property

definition header file in his/her source code.

Among other files SG generates configuration C-file containing

definitions and initialization of OSEK OS configuration data and

corresp onding header H -file. Configu rati on C-file is a separate module,

however, in some particular OSEK OS configurations, it could contain

references to user defined data and structures (e.g. user’s message

structure types). This requires a method to provide SG generated

confi gur ation C-fil e with such user defined type s and data declar ations.

Thus SG generates the following code in configuration C-file:

#if defined(APPTYPESH)

#include APPTYPESH /* user’s header file */

#endif /* defined(APPTYPESH) */

The compiler command line (see Section 14.3.3 Compiling and

Linking) in thi s case should have the option like this:

-dAPPTYPESH="<filename>".

is the name of the file wi th user defined structures and

data declarations.

In the example below two variables and one data type are defined by the

user which are referenced in files generated by SG. Variables are

defined in the user’s file “user.c” and referenced in the produced file

“cfg.c”. The data type is defined in the user’s file “user.h” and referenced

in the produced file “cfg.c”. The user’s code can be the following:

USER.H file:

typedef struct tagMSG MSGTYPE;

struct tagMSG

{

TickType timeStamp;

int x;

};

extern MSGTYPE MsgA;

Building of Application

Act ion Sequence to Build an Application

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA Building of Application 177

NON-DISCLOSURE AGREEMENT REQUIRED

#define MYISRSTACKSIZE100

extern char MyIsrStack[MYISRSTACKSIZE];

USER.C file:

#include "user.h" /* include user defined data type */

...

char MyIsrStack[MYISRSTACKSIZE];

...

int varA = 22; /* user defined variables */

int varB = 0;

...

CFG.C file (generated by SG):

...

#if defined(APPTYPESH)

#include APPTYPESH /* user’s header file */

#endif /* defined(APPTYPESH) */

...

/* SG generated code referring to user’s type and data */

...

The compiler command line has the following option:

-dAPPTYPESH="USER.H".

Other variants are also possible.

The code of user’s tasks and functions should be developed according

to common rules of the C language. But some exceptions exist:

• The keyword

TASK

and

ISR

should be used to define a task and

ISR correspondingly;

• For ob jects controlled by the OSEK Operating System the data

types defined by the system must be used. The data types are

described at the end of previous sections and in

Section 17 System Services.

NON-DISCLOSURE AGREEMENT REQUIRED

Building of Application

User’s Manual OSEK Opera ting System — Re v 1.2

178 Building of Application MOTORO LA

14.3.3 Compiling and Linking

When all needed header and source files are created or produced by the

System Generator an application can be compiled and linked (for details

see Appendix 15 HC12 Platform-Specific Features).

Linking process is controlled by the typical linker directive file.

14.4 Samp le Applicati on

In App end ix A Sample A ppl ication the code of an OSEK OS based

application is provided. This code is a simple demonstration of Operating

System mechanisms. It also demonstrates how to write the configuration

file and source code.

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA HC 12 Platform-Speci fic Features 179
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 15 . HC12 Platform-S pecific Features
15.1 Contents
15.2 Compiler-Specific Features  . . . . . . . . . . . . . . . . . . . . . . . . . .179
15.3 Interrupt Flag Manipulation Specific Features . . . . . . . . . . . .180
15.4 HC12 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
15.5 Task Stack Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
15.2 Compiler-Specific Features
To use OSEK OS after installation the Cosmic C-compiler for 
MC68HC12 should be installed on the computer. It is necessary to call 
the DOS prompt under Windows NT to run the NMAKE utility. 
15.2.1 OSEK OS Environment Variables
It is recommended to add environment variables and paths to access 
compiler directories and OSEK directory. Installation procedure 
suggests the user to set these variables automatically and place it into 
OSEK OS Environment Configuration file (MAKE.BAT by default). If they 
were not set during installation the user should do it manually.These 
variables are the following:
OSEKDIR = [...]\OSEK – path to the OSEK directory
For t he Cosmic compiler:
CXPATH = [...]\H6812 – path to the Cosmic header files directory
CXLIB = [...]\LIB – path to the Cosmic library files directory

NON-DISCLOSURE AGREEMENT REQUIRED

HC12 Platf orm- Sp e cific Feat ures

User’s Manual OSEK Opera ting System — Re v 1.2

180 HC12 Platform-Speci fic Features MOTOROLA

See the file "makefile" in the OSEK\SAMPLE directory for additional

information.

15.2.2 Cosmic Soft ware

In case of optimization-related errors in the compiler’s code generation

It is recommended to switch off optimizer by use “-no” option for

compiler. (The “-no” option is used in the sample makefile for debug

version of the executable code).

Definitions for Cosmic C-compiler

The user should set the next compiler definitions to provide the selection

of the Cosmic platform and the selection of the board being used:

• OSCOSMIC12 for the selection of the Cosmic platform.

• OSHC12A4 for selection of the board HC812A4EVB.

• OSHC12B32 for selection of the board M68HC12B32EVB.

• OSHC12D60 for selection of the board M68EVB912D60.

• OSHC12D128 for selection of the board M68EVB912D60 with

DA128 chip.

15.3 Interrupt Flag Man ipu lati on Specific Features

CPU12 exceptions include resets, an unimplemented opcode trap, a

software interrupt instruction, X-bit interrupts and I-bit interrupts.

Exceptions can be classified by the effect of the X and I interrupt mask

bits in Condition Code Register (CCR) on recognition of a pending

request. Resets, the unimplemented opcode trap, and the SWI

instruction are not affected by the X and I mask bits. COP resets have

XIRQ pin are inhibited when X = 1, bu t are not affected by the I bit. All

other interrupts are inhibited when I = 1.

This version of the OSEK Operating System manipulates with CCR X-bit

and I-bit only (external interrup t registers are not affected), therefore it is

not possible to use OS EK services from interrupts below XIRQ.

HC12 Platform-Specific Features

Interrupt Flag Manipulation Specific Features

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA HC 12 Platform-Speci fic Features 181

NON-DISCLOSURE AGREEMENT REQUIRED

HC12 OS services for interrupt flag manipulation simply disable and

enable interrupts and inquire the current status of the interrupt flags

(C CR X-bi t and I-bit) . If a ta sk is pre empte d by other task or suspend ed

its inter rupt mask is saved. Wh en the ta sk is resumed its saved interrupt

mask is restored. When a task is activated it has either the interrupt

mask specified in the task definition statement (attribute InterruptMask

in OIL-file) or the interrupt mask specified in the interrupt definition

statement (attribute TaskLevelMask in OIL-file - common mask value for

all tasks which have undefined InterruptMask attribute)

In OSEK OS v.2.0 it is necessary to use logical interrupt

descriptors(logicmask).

For OS/12 the following logicmask values are valid:

0x10 – I-bit interrupts are enabled (CCR I-bit is cleared, X-bit is set);

0x40 – X-bit interrupts are enabled (CCR X-bit is cleared, I-bit is set);

0x50 – I-bit and X-bit interrupts are enabled (CCR I-bit and X-bit are

cleared);

0x00 – internal interrupts are disabled (CCR I-bit and X-bit ar e set).

Physical interrupt mask (value of CCR I-bit and X-bit) is ( ~logicmask

)&0x50.

All other bits of CCR are not affected in OSEK system services.

Notice, that system services (EnableInterrupt, DisableInterrupt,

GetInterruptMask) proceeds their parameter as full mask (8-bit) to be

applied to CCR but affected on X-bit and I-bit only. GetInterruptMask

returns mask that can be safely provided to other system services.

DisableInterrupt inverts mask argument before set it. E.g. call

DisableInterr upt( 0x00) sets interrupt mask 0x10 (logicmask).

NOTE:

It is possible to use EnterISR()/ExitISR() services from internal interrupts

only (as mentioned above).

NON-DISCLOSURE AGREEMENT REQUIRED

HC12 Platf orm- Sp e cific Feat ures

User’s Manual OSEK Opera ting System — Re v 1.2

182 HC12 Platform-Speci fic Features MOTOROLA

15.4 HC12 Features

15.4.1 Base Page Memory Usage

In general, the system configuration option

HCBasePage

is of

considerable importance for the OSEK Operating System for HC12

MCU . The average size of the OSEK OS kernel version with

HCBasePage

turned on is significantly smaller than the size of the

version with extended addressing (

HCBasePage

is turned off). Exact

characteristics are provided in Appendix C Memory Requirements.

This feature can be important for applications with exacting

requirements for memory and performance. Also the task control blocks

can be placed into the base page memory, if the system configuration

option

TaskBasePage

is turned on. In this case the user is responsible

for the nee ded amo unt of RAM in the base pag e for the de sired number

of task control blocks (the Cosmic linker option to contr ol the segment

size “-m##” can be used for this purpose). This system property

increases the overall system performance.

However, it should be kept in mind that not all MCUs ba sed on CPU12

core have base page available for data. For example, MC68HC812A4

uses base page for registers, and using of base page for OSEK OS

should be avoided (i.e. both opt ions described above must be turned off)

NOTE:

The current OSEK Operating System for HC12 has this feature

implemented for Cosmic software only.

15.4.1.1 Mapping RAM and REGISTERS

In MCUs based on CPU12, RAM and REGISTERS areas may be

mapped to any 2K sp ace. T his fe ature i s espe ciall y impo rtant for MCU s

like HC12D60, where RAM and register areas by default start from

address 0, and 512 bytes of RAM are lost therefore.

The following compilation-time variables are used for start addresses:

•

_BASE

defines the start address of the REGISTERS area,

•

_BASERAM

defines the start address of the RAM area.

HC12 Platform-Specific Features

HC12 Features

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA HC 12 Platform-Speci fic Features 183

NON-DISCLOSURE AGREEMENT REQUIRED

Any of these variables or both should be set in compiler options, and

memory allocation should be adjusted in linker directives. As very first

step of reset handling the INITRM register should be set equal to bits

15:11 of the

_BASERAM

value, and INITRG register should be set equal

to bits 15:11 of the

_BASE

value.

These technique is demonstrated in the sample for Cosmic software.

Two variables are defined in makefile:

•

basereg

defines the start address of the REGISTERS area (i.e.

value of

_BASE

variable),

•

baseram

defi nes the start address of the RAM area (i.e. value

_BASERAM

variable).

basereg

baseram

are set in makefile, the compiler options and linker

directives are adjusted, and initialization of INITRM and INITRG

registers is made automatically (corresponding procedure is defined in

“vector.c” file).

15.4.2 Interrupt Vector Table

The interrupt vector table is defined in the file “vector.c” which is

delivered with the OSEK Operating System and located in the

[...]\OSEK\SAMPLE directory. This file is the example of the interr upt

vector table coding. The user should copy this file into the project

directory and there modify it as needed.

If D-Bug12 monitor is used for development (l ike for

MC68HC812A4EVB), the vector table is arranged according to the

logical vector numbers used by the D-Bug12 v1.0.2 monitor. The real

setting of the vectors is performed in

main()

function via D-Bug12

SetVector function. The sample contains the code needed to set vectors

properly for the MC68HC812A4EVB. If the application will be started

without D-Bug12, it may be necessary to re-arrange the vector table

according to the physical order of the interrupts vectors in the vector

table. For example, if SDI is used for development (like for

M68EVB912D60), the vector table is arranged according to physical

location of the vector numbers.

NON-DISCLOSURE AGREEMENT REQUIRED

HC12 Platf orm- Sp e cific Feat ures

User’s Manual OSEK Opera ting System — Re v 1.2

184 HC12 Platform-Speci fic Features MOTOROLA

15.4.3 The Bank ed Memory Model Support

15.4.3.1 Banked Memory Model Overview

In gener al, the system con figura t ion option

HCBankCode

specifies that

memory bank switching is supported by the OSEK OS. This property is

hardware-dependent and compiler-dependent. The hardware-

dependent means that it can be applied only to some micro controllers

of the M68HC12 family (MC68HC912DA128/DG128/DT128) which

have the ability to extend the address range of the CPU beyond the

64KB l im it given by the 1 6 CP U add ress lin es. The compiler-dep ende nt

means that the mechanism of the near and far functions must be

supported by compiler.

In case of

HCBankCode

is set to TRUE the user’s application part of

code (the task code) will be placed into expanded memory (into the

memory banks) and OSEK OS will provide task bank valu e

savi ng/restoring while OSEK OS manipulates with TASKs allocated to

the different banks. OSEK OS code and data will be allocated to non-

banked memory together with interrupt handlers.

In current version of OSEK OS these properties are implemented for

Cosmic C-compilers and the board M68EVB912D60 with DA128 chip

(the user should set OSHC12D128 compiler definition).

The following diagram illustrates the memory paging scheme:

HC12 Platform-Specific Features

HC12 Features

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA HC 12 Platform-Speci fic Features 185

NON-DISCLOSURE AGREEMENT REQUIRED

Figure 15-1. Banked Memory Model

15.4.3.2 Configuration of the Application for Banked Memory

In general, the following steps should be performed to configure

application for banked memory:

1. Identify application code to be allocated in various banks.

Typically, task code as well as application library code may be

located in the banked memory;

2. Emphasize the banked code in the source files. Compiler

#pragma directive is used to start banked section, which is

identified by the section name. Alternative way is to do not

explicitly identify banks in the code, and allow linker to do re-

location of the code into the banks;

3. Turn on the

HCBankCode

prope rty i n th e conf igurat ion fi le. ( Note

that

MemoryBank

property of the tasks is ignored, and ma y have

any value therefore. It is designed for future extensions);

Non-banked

memory

Bank 0

Bank 1

Bank 6

– start-up code

– OSEK OS code

–ISR

– task code

– any function s called

from the task/ISR

– other application code

•••

Address (hex)

$0000

$FFFF

$08000

$0BFFF

$18000

$1BFFF

$68000

$6BFFF

NON-DISCLOSURE AGREEMENT REQUIRED

HC12 Platf orm- Sp e cific Feat ures

User’s Manual OSEK Opera ting System — Re v 1.2

186 HC12 Platform-Speci fic Features MOTOROLA

4. Alter compiler op tions to make all the function s banked by default.

The non-banked functions should have near modifier;

5. In the linker directive file locate banked sections into the physical

banks.

More details may be found in the sample code and makefile, as well in

the compiler User’s manuals.

15.4.3.3 Cosmic Compiler Issue

The comp iler supports bank switching for code only, using the internal

window mechanism provided by the MC68HC12 processor, or using any

external user provided mechanism. Bank switching is supported via:

@far type qualifier to describe a function relocated in a different bank.

Calling such a function implies a special calling sequence, and a special

return sequence. Such a function has to be defined @far and referenced

as @far in all the files using it. The compiler also provides a specific

option +modf to automatically consider all the functions to be @far.

Linker options are required to ensure proper physical and logical

addresses computations. The linker is also able to automatically fill

banks without any need to take care of the page boundaries.

Compiler pragma for banked memory

The following #pragma directive is used to start banked section bank1:

#pragma section (bank1)

Compiler options for banked memory

The following compiler option is used to make all functions banked by

default (except implicitly defined as near):

-m modf:hmodf.h

+modf

Linker di rectives for banked memory

The f ollowing dir ective is used to locate the banke d sectio n bank1 in t he

physical bank #1:

HC12 Platform-Specific Features

HC12 Features

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA HC 12 Platform-Speci fic Features 187

NON-DISCLOSURE AGREEMENT REQUIRED

+seg .bank1 -b 0x18000 -p1

15.4.4 Recom me ndations on System Properties

15.4.4.1 UseMainStack property

It is recommended to turn ON this property. It reduces the needed

amount of RAM for sta cks, since the same m emor y are a is used du ring

start-up (for

main()

program), for the interrupt stack and for the

scheduler stack. Moreover, the size of the OS code is also reduced

(ROM for the Operating System).

However, the user is responsible for allocation appropriate stack in the

linker directive file. (This fi le is used as an inline text in the sample

makefile).

15.4.4.2 UseSameContext Property

It is recommended to turn ON this property to use only preemptive

context for all tasks. It is important for CPU12 so the code to process the

non-pr eem pti ve conte xt is qu ite bi g, and it leads to addi tion al ROM and

RAM con s uming and r educes sy stem pe rfor mance. When thi s prop erty

is ON, ta sk switch ing is per formed faste r and the requi red ROM am ount

is reduced. Use of different contexts (preemptive and non-preemptive)

have a sense for CPUs with many registers if some of them are not

included into the non-pr eemptive context.

15.4.4.3 InterruptMaskControl Property

It is better to keep this property turned OFF, if it is not absolutely

necessar y to con trol “ I” b it of th e Conditi o n Code Register . U sing o f this

property increases the amount of ROM for the OS code and requires

additional time for all system services. Generally, this property is

intended for CPUs with several interrupt priority levels, e.g. CPU16.

NON-DISCLOSURE AGREEMENT REQUIRED

HC12 Platf orm- Sp e cific Feat ures

User’s Manual OSEK Opera ting System — Re v 1.2

188 HC12 Platform-Speci fic Features MOTOROLA

15.4.4.4 CounterSize Property

In spite that CPU12 processes 16-bits variables, the best performance

is achieved when operands are byte-sized. Therefore, it is

recommended to use 8-bit counters (

CounterSize

= 8) to increase

overall performance and reduce the needed amount of RAM. Of course,

it is possible to use 16-bit and 32-bit counters, but it leads to additional

RAM and time consuming, especially in case of 32-bit counters!

15.4.4.5 Unused Services

To reduce ROM consuming it i s recommended to exclude OS services

which are not used in the application from the OS code with the help of

“excluding” system properties. It helps to save m e mory.

15.4.5 Syste m Timer Hardware

The special OS attri butes are introduced to define hardware interrupt

source and desired parameters for counter considered to be system

timer.

In the table below all possible values to define these parameters are

listed.

HC12 Platform-Specific Features

HC12 Features

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA HC 12 Platform-Speci fic Features 189

NON-DISCLOSURE AGREEMENT REQUIRED

The bits 7:6:5 of the prescaler contain the values to be set in the base

clock select bits BCSC:BCSB:BCSA of the clock control register

CLKCTL . The bits 4: 3 of th e prescale r contain the values to be set in the

module clock select bits MCSB:MCSA of the clock control register

CLKCTL. The bits 2:1:0 of the prescaler contain the values to be set

either in the timer prescaler select bits PR2:PR1:PR0 of the timer

interrupt mask 2 register TMSK2 or in the base clock select bits

Table 15-1. Parameters to define System Timer hardware

TimerHardware PrescalerValue TimerModuloValue

bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0

MC68HC812A4

TIMTOI BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 N/A

TIMOC0 BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 0...65535

TIMOC1 BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 0...65535

TIMOC2 BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 0...65535

TIMOC3 BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 0...65535

TIMOC4 BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 0...65535

TIMOC5 BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 0...65535

TIMOC6 BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 0...65535

TIMOC7 BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 0...65535

RTI BCSC BCSB BCSA MCSB MCSA RTR2 RTR1 RTR0 N/A

MC68HC912B32, MC6 8HC912D6 0, MC68HC912DA128

TIMTOI N/A N/A N/A N/A N/A PR2 PR1 PR0 N/A

TIMOC0 N/A N/A N/A N/A N/A PR2 PR1 PR0 0...65535

TIMOC1 N/A N/A N/A N/A N/A PR2 PR1 PR0 0...65535

TIMOC2 N/A N/A N/A N/A N/A PR2 PR1 PR0 0...65535

TIMOC3 N/A N/A N/A N/A N/A PR2 PR1 PR0 0...65535

TIMOC4 N/A N/A N/A N/A N/A PR2 PR1 PR0 0...65535

TIMOC5 N/A N/A N/A N/A N/A PR2 PR1 PR0 0...65535

TIMOC6 N/A N/A N/A N/A N/A PR2 PR1 PR0 0...65535

TIMOC7 N/A N/A N/A N/A N/A PR2 PR1 PR0 0...65535

RTI N/A N/A N/A N/A N/A RTR2 RTR1 RTR0 N/A

additionally for MC6 8HC912D6 0, MC68HC912 DA1 28

MDC N/A N/A N/A N/A N/A N/A MCPR1 MCPR0 0...65535

NON-DISCLOSURE AGREEMENT REQUIRED

HC12 Platf orm- Sp e cific Feat ures

User’s Manual OSEK Opera ting System — Re v 1.2

190 HC12 Platform-Speci fic Features MOTOROLA

RTR2:RTR1:RTR0 of the real-time interrupt control register RTICTL.

The bits 1:0 of prescaler can also contain the values to be set in the

Modulus Counter Prescaler select bits MCPR1:MCPR0 of the MCCTL

NOTE:

MC68HC912B32 MCU does not allow the following values of prescaler

bits PR2:PR1:PR0: 1:1:0 and 1:1:1.

Thus, the system def inition stateme nts for the OSEK Operatin g System

for HC12 MCU family has the following form:

OS <name> {

... SysTimer = <SysTimerDefined>;

TimerHardware = <HardwareType>;

Prescaler = <PrescalerDefined>;

PrescalerValue = <HardwarePrescaler>;

TimerModulo = <ModuloDefined>;

TimerModuloValue = <HardwareModulo>;

...

};

For example, the system timer is based on the Output Compare channel

5 interrupt, with no Prescaler and Modulo Counter value equals 1024. In

this case the definition statement can be the foll owing:

OS <name> {

... SysTimer = TRUE;

TimerHardware = TIMTOI;

Prescaler = FALSE;

...

};

Another example, the system timer based on the Real-Ti me Interrupt,

with Prescaler value equals 1 and no Modulo value. In this case the

definition statement can be the following:

OS <name> {

... SysTimer = TRUE;

TimerHardware = RTI;

Prescaler = TRUE;

PrescalerValue = 0x01;

HC12 Platform-Specific Features

HC12 Features

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA HC 12 Platform-Speci fic Features 191

NON-DISCLOSURE AGREEMENT REQUIRED

TimerModulo = FALSE;

...

};

NOTE:

The system timer will not be triggered if the EntryExitISR property is

turned OFF!

15.4.6 Sc heduler Arch it ect ur e

If an application does not use resources, it is strongly recom men ded to

use si mplifi ed sc heduler (th e pro perty

SimpleScheduler

must be tur ned

ON). In this case all tasks running concurrently must have different

priorities. That is, two ta sks may have th e sam e priority if t hey ar e neve r

both in

ready

state and they must have different priorities o therwise. Th e

simple scheduler uses prioritized table of task nodes and works faster. It

requires less amount of ROM and RAM than the standard scheduler.

If an appl ication uses resour ces or clai m s to have more than on e ready

task per priority, the

SimpleScheduler

option shou ld be turned off. In this

case the POSIX-like scheduler is used. To reduce RAM consuming the

number of priorities should be kept as small as possible.

15.4.7 Alarms Configuration

If the application does not use cyclic alarms, it is recommended to turn

CyclicAlarm

property OFF. In this case the cyclic field is excluded from

the alarm control block, which decreases RAM usage. In addition, the

code to handle cyclic alarms is also excluded from the system,

decreasing ROM usage and improving performance of the alarm

services. As a side effect, stack usage is also decreased, because there

is no need to pass

cycle

parameter for

SetAbsAlarm

and

SetRelAlarm

services, and less stack space is required for internal computations.

To de crease RAM usage, the

AlarmLi st

property may b e turned O FF. In

this case, the alarms are collected together in one table, and linked to

the counter. Therefore, the fields, which are required for list handling, are

elim inated f rom t he alar m contr ol block. H oweve r, to kee p per form ance

the numb er of alar ms attached to one cou nter, should be mi nimized. To

NON-DISCLOSURE AGREEMENT REQUIRED

HC12 Platf orm- Sp e cific Feat ures

User’s Manual OSEK Opera ting System — Re v 1.2

192 HC12 Platform-Speci fic Features MOTOROLA

reach that, additional counters may be added, and alarms may be

rearranged.

If the RAM size is limited, it is highly recommended to turn

MinAlarmRAM

property ON. In this case alarm control block size is

significantly decreased, especially when

AlarmList

property may be

turned OFF. However, the performance is slightly decreased, because

some static data are not mirrored in RAM. It should be also kept in mind,

that in this case alarms ar e referenced differently than in case when

MinAlarmRAM

property is turned OFF.

15.5 Task Stack Size

Generall y, the recommended minimal task stack size equals:

• 24 bytes for extended tasks if no task activation, messages, and

there are no interrupts in the system;

• 32 bytes for extended tasks if no task activation, messages and

interrupts are supported in the system;

• 48 bytes for other cases.

In order to reduce amount of memory, needed for task stacks,

UseCommonArea

property may be turned ON. In this case the global

data area is used for parameters and local variables for most internal

system functions. (For operating system calls convenient compiler

generated calls are used).

In particular,

UseCommonArea

property allows to save stack space

while calling the following services:

•

ActivateTask

- up to 4 bytes;

•

CounterTrigger

- up to 12 bytes;

•

SetRelAlarm

SetAbsAlarm

- up to 4 bytes.

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA Application Troubleshooting 193
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 16. Application Troubleshooting
16.1 Contents
16.2 System Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
16.3 Using OS Extended Status for Debugging . . . . . . . . . . . . . . .193
16.4 Context Switch Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
16.5 Stack Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
16.6 Known Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
In this section  some advi ce is g iven wh ich may be useful for deve loper s 
working with the OSEK Operating System.
16.2 System Gen era tion
The System Generator is used to generate the code for the OSEK 
Operating System kernel and all application objects (tasks, messages, 
etc.). This tool processed the configuration file created by the user and 
repor ts about inconsi stencies and er rors in it. Most of possib le mistakes 
in application configuration process can be eliminated with the help of 
SG. See Section 12 System Configuration and Section 14 Building 
of Application about system generation process.
If an undocumented problem arises please provide us with the detailed 
description of it and we will h elp to resolve the problem. See 
Section 2.6 Technical Support Information for contact information.
16.3 Using OS Exten ded Status for Debuggin g
It is strongly recommended to use Operating System Extended Status 
when you develop an application to analyze return codes of system 

NON-DISCLOSURE AGREEMENT REQUIRED

Applicat ion Troubleshooting

User’s Manual OSEK Opera ting System — Re v 1.2

194 Application Troubleshooting MOTOROLA

services. Such method is more memory and time consuming but it

allo ws the user to save ti me fo r err ors e liminati ng . Error codes r etur ned

by the OSEK OS servic es covers most of possible err ors that can arise

during development. Therefore it is useful to check these codes after a

service call to avoid error that can lead to the system crash. For

example, a task can perform the

TerminateTask

service while it is still

occupying a resource. This service will not be performed and the task will

remain active (

running

). In case of Extended Status the

E_OS_RESOURCE

error code is returned and it is possible to detect

this situation. But in the system without Extended Status there is no

additional check and this error is not indicated and the application

behavior will be unpredictable!

When all errors in an application will be eliminated you may turn off the

Extended Status and remove additional status checks from the

application to get the reliable application of the smaller size.

16.4 Context Switc h Routines

Breakpoints, traces and time stamps can be integrated individually into

the application software with the help of context switch hook routines

PreTaskHook

and

PostTask

Hook.

Example: The user can set time stamps enabling him to trace the

program execution at the following locations before calling operating

system services:

• When activating or terminating tasks;

• When setting or clearing events in the case of Extended Tasks;

• At explicit points of the schedule (

ChainTask

Schedule

);

• At the beginning or the end of ISR;

• When occupying and releasing resources or at critical locations.

The Operating System needs not include a time monitoring feature

which ensures that each or only, e.g. the lowest-priority task has been

activated in any case after a defined maximum time period.

Application Troubleshooting

Stack Errors

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Application Troubleshooting 195

NON-DISCLOSURE AGREEMENT REQUIRED

The user can option al ly use hook r outines or establi sh a watch dog task

that takes “one-shot displays” of the operating system status.

16.5 Stack Errors

Stack err ors may be due to the stack pointer being incorr ect or to stack

contents being incorrect. Stack content problems are possible when

using pointers into stack variables, but stack pointer problems seem to

be more common. The symptom of either problem is usually a task or

ISR executing normally, but then when a return is performed, the

program executes at some incorrect address.

Problems with a program running wild may sometim es be caught by

always filling the unused program memory with $00, which the HC12

‘

test

’ opcode does, and setting a brea kpoint at the illegal opcode vector

address.

ISRs using OS services or reenabling interrupts should begin with the

EnterISR service and end via the LeaveISR service (see

Section 6 Interrupt Processing). If the number of EnterISR and

LeaveISR invocations do not match (e.g., in case of nested interrupts),

the stack will be incorrect. See also Section 6 Interrupt Processing

about using variables in ISRs.

Tasks should have enough stack for their execution, therefore it is

recommended to pay attention on task de finition statements to provide

each task with a needed amount of stack. See Section 15 HC12

Platform-Specific Features.

16.6 Known Problems

None.

NON-DISCLOSURE AGREEMENT REQUIRED

Applicat ion Troubleshooting

User’s Manual OSEK Opera ting System — Re v 1.2

196 Application Troubleshooting MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA System Services 197
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Section 17. System Services
17.1 Contents
17.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
17.3 Task Management Services. . . . . . . . . . . . . . . . . . . . . . . . . .199
17.4 ISR Management Services. . . . . . . . . . . . . . . . . . . . . . . . . . .210
17.5 Resource Management Services . . . . . . . . . . . . . . . . . . . . . .220
17.6 Counters and Alarms Management Services. . . . . . . . . . . . .225
17.7 Event Management Services . . . . . . . . . . . . . . . . . . . . . . . . .242
17.8 Communication Management Services . . . . . . . . . . . . . . . . .249
17.9 Operating System Execution Control . . . . . . . . . . . . . . . . . . .259
17.2 General
This section provides detailed description of all OSEK OS run-time 
services including hook ro utines. Also declarations of system objects – 
the constructional elements – are described here. The services are 
arranged in logical groups – for the task management, the interrupt 
management, etc. 
Examples of code are also provided for every logical group. These 
examples have no practical meaning, they only show how it is possible 
to use OS calls in an application.
The following scheme is used for service description:
Declaration element:
Syntax: Operating System interface in ANSI-C syntax.
Input List of all input parameters.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

198 System Services MOTOROLA

Description: Explanation of the constructional element.

Particularities: Explanation of restrictions relating to the utilization.

Conformance: Specifies the lowest Conformance Class where the

declaration element is provided.

Ser vice desc rip tio n:

Syntax: Operating System interface in ANSI-C syntax. The

return value of the service is always of data type

StatusType

Input: List of all input parameters.

Output: List of all output parameters. Transfers via the

memory use the memory reference as input

parameter and the memory contents as output

parameter. To clarify the description, the reference is

already specified among the output parameters.

Description: Explanation of the functionality of the operating

system service.

Particularities: Explanations of restrictions relating to the utilization

of the service.

Status: List of possible return values.

Standard: List of return values provided in the operating

system’s standard version. Special case – service

does not return.

Extended: List of additional return values in the operating

system’s extended version.

Conformance: Specifies the lowest Conformance Class where the

service is provided.

The specification of operating system services uses the following

naming conventions for data types:

...Type

: describes the values of individual data.

System Services

Task Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 199

NON-DISCLOSURE AGREEMENT REQUIRED

...RefType

: describes the identifier referencing an object1.

It is also possible to see all predefined OSEK OS data types in system

header files.

1. E.g. , a point er or an index

17.3 Task Management Services

17.3.1 Data types

The OSEK OS establishes the following data types for the task

management:

•

TaskType

The ab stract d ata typ e for task identif ication;

•

TaskRefType

The data type to refer variables of the

TaskType

data type;

•

TaskStateType

The data type fo r variables to sto re the state

of a task;

•

TaskStateRefType

The data type to refer variables of the

TaskStateType

data type.

17.3.2 Constants

The fol lowing constants are use d wi th in th e O SEK Ope rating System to

indicate task states:

•

RUNNING

Constant of data type

TaskStateType

for

task state

running

•

WAITING

Constant of data type

TaskStateType

for

task state

waiting

•

READY

Constant of data type

TaskStateType

for

task state

ready

•

SUSPENDED

Constant of data type

TaskStateType

for

task state

suspended

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

200 System Services MOTOROLA

The following constant is used within the OSEK OS to indicate task:

•

INVALID_TASK

Constant of data type

TaskType

for a not

defined task

17.3.3 Conventions

Within the application of the OSEK OS a task should be defined

according to the following pattern:

TASK ( TaskName )

{

...

}

The name of the task function will be generated from

TaskName

macro

TASK

The only data types must be used for operations with tasks.

17.3.4 Task Declaration

To refer to a task the constructional element should be used to declare

the task before references to it:

Syntax:

DeclareTask( TaskType <TaskName> )

Input:

•

– a reference to the task

Description:

DeclareTask

serves as an external declaration of a task. The function

and use of this service are similar to that of the external declaration of

variables.

Particularities: none

Conformance: BCC1 , BCC2, ECC1, ECC2

System Services

Task Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 201

NON-DISCLOSURE AGREEMENT REQUIRED

17.3.5 ActivateTask

Syntax:

StatusType ActivateTask( TaskType <TaskName> );

Input:

•

– a reference to the task.

Output:

• None.

Description:

The specified task

TaskName

is transferr ed from the

suspended

state

into the

ready

state. All needed actions for task ini tialization are

accomplished by the system according to information from the task

configuration table (e.g., dyna mic stack and node allocation).

Particularities:

The service may be called both on the task level (from a task) and the

interrupt level (from ISR). This service may be called also by

StartupHook

hook routine.

In the case “ call from ISR”, the operating system will reschedule tasks

only after the ISR completion.

If the system configuration option

ActivateTask

is turned off the service

is excluded from the OSEK OS code.

Status:

• Standard:

–

E_OK

– no error;

• Extended:

–

E_OS_ID

– the task identifier

TaskName

invalid;

–

E_OS_LIMIT

– too many task activations of the

specified task or there is no enough

resources to activate the task.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

202 System Services MOTOROLA

Conformance: BCC1 , BCC2, ECC1, ECC2

17.3.6 TerminateTask

Syntax:

StatusType TerminateTask( void );

Input:

• None.

Output:

• None.

Description:

This service causes the termination of the calling task. The calling task

is transferred from the

running

state into the

suspended

state and

releases all occupied system resources (that is, the stack, the task node,

etc.) except task has multiply activation requests.

Particularities:

The re sources occupied by the task must have been released before.

If the call was successful,

TerminateTask

does not return to the call le vel

and the status can not be evaluated. If the service

TerminateTask

called successfully, it enforces a rescheduling.

If the system with extended status is used, the service returns in case of

error, and provides a status which can be evaluated in the application.

If the system configuration option

TerminateTask

is turned off the

service is excluded from the OSEK OS code.

Status:

• Standard:

– No return to the caller.

• Extended:

–

E_OS_RESOURCE

– the task still occupies resources;

System Services

Task Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 203

NON-DISCLOSURE AGREEMENT REQUIRED

–

E_OS_CALLEVEL

– a call at the interrupt level.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.3.7 ChainTask

Syntax:

StatusType ChainTask( TaskType <TaskName> );

Input:

•

– a reference to the sequential succeeding

task to be activated.

Output:

• None.

Description:

This service causes the termina tion of the calling task. After term ination

of the calling task a succeeding task <

TaskName>

is activated

sequenti ally. Us ing this ser vice, it ensures th at the succe eding task o nly

starts to run after the calling task has been terminated.

Particularities:

If the succeeding task is identical with the current task, this does not

result in multiple requests. In this case the task will be terminated and

after that activated again. It can be used, e.g. if multiple activation is

disabled but it is needed to restart a task. If it is not needed to have such

tricks the system property

ChainTaskItself

can be turned off to decrease

the task contr ol block size.

The re sources occupied by the calling task must have been released

before.

If called successfully,

ChainTask

does not return to the call level and the

status can not be evaluated. In this case a rescheduling is enforced.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

204 System Services MOTOROLA

If the version with Extended Status is used, the service returns in case

of error to the calling task, and provides a status which can be evaluated

by the application.

If the system configuration option

ChainTask

is turned off the service is

excluded from the OSEK OS code.

Status:

• Standard:

– If t he service is cal led successfully , then no re turn to the c aller;

• Extended:

–

E_OS_ID

– the task identifier is invalid;

–

E_OS_LIMIT

– too many activations of

TaskName>

or there is not enough

resources to activate the task.

–

E_OS_RESOURCE

– the calling task still occupies

resources;

–

E_OS_CALLEVEL

– a call at the interrupt level.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.3.8 Schedule

Syntax:

StatusType Schedule( void );

Input:

• None.

Output:

• None.

Description:

If a higher-priority task is

ready

, the curr ent task is put into the

ready

state an d a hig her-prior ity task is execute d. Otherw ise the call ing task is

System Services

Task Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 205

NON-DISCLOSURE AGREEMENT REQUIRED

continued without delay. By means of using this service the task

explicitly yields control to a higher-priority ready task (if any exists).

Particularities:

In not full-preemptive systems

Schedule

enables a processor

assi gnment to other tasks in application-specific locations.

Schedule

does not cause rescheduling if task owns

RES_SCHEDULER

resource (See Section 17.5.4 GetResource).

If the system configuration option

Schedule

is turned off the service is

excluded from the OSEK OS code.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_CALLEVEL

– a call at the interrupt level.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.3.9 GetTaskId

Syntax:

StatusType GetTaskId( TaskRefType <TaskName> );

Input:

• None.

Output:

•

– a reference to the task which is currently

active . Th e system saves th e task reference

into the variable <

TaskName

Description:

This system service returns the name (<

TaskName

>) of the task which

is currently active.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

206 System Services MOTOROLA

Particularities:

This service is useful, for instance, in the case if two or more tasks

shares the same piece of code and in some point of the code the coming

actions depend on which task is executed in the moment. This service

may be called by

ErrorHook

PreTaskHook

and

PostTaskHook

hook

routi nes . If the name of th e task ca n not b e evalu ated ( no ta sk curr ently

active), the value

INVALID_TASK

will be returned.

If the system configuration option

GetTaskId

is turned off the service is

excluded from the OSEK OS code.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_CALLEVEL

– a call at the interrupt level.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.3.10 GetTaskState

Syntax:

StatusType GetTaskState( TaskType <TaskName>,

TaskStateRefType <State> );

Input:

•

– a reference to the task.

Output:

•

<State>

– a reference to the state of task

Description:

Returns the state of the specified task

(

running

ready

waiting

suspended

) at the time of calling

GetTaskState

System Services

Task Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 207

NON-DISCLOSURE AGREEMENT REQUIRED

Particularities:

The service may be called both on the task level (from a task) and the

interrupt level (from ISR). This service may be called by

ErrorHook

PreTaskHook

and

PostTaskHook

hook routines .

Within a full-preemptive system, calling this operating system service

only provides a meaning ful result if the task runs in an interrupt disabling

state at the tim e of calling. When a call is made from a task in a full-

preemptive system, the resul t may already be incorrect at the time of

evaluation.

If the syste m configura tion option

GetTaskState

is turn ed off the se rvice

is excluded from the OSEK OS code.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the task identifier is invalid.

Conformance: BCC1, BCC2, ECC1, ECC2

17.3.11 GetTCBInfo

Syntax:

StatusType GetTCBInfo( TaskControlBlockRefType

<TaskControlBlock>);

Input:

• None.

Output:

•<TaskControlBlock> – a reference to a memory block

where contents of the running task

control block are to be copied.

Description:

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

208 System Services MOTOROLA

Copies contents of the running task control block by the address

specified in <TaskControlBlock> parameter.

This service is not defined in the OSEK OS v.2.0 rev. 1 specification.

This is an extension of OSEK OS.

Particularities:

The service may be called both on the task level (from a task) and the

interrupt level (from ISR). This service may be called by

ErrorHook

PreTaskHook

and

PostTaskHook

hook routines .

If called by

PreTaskHook

hook routi ne this servi ce copies conte nts of a

control block of a task transiting to the

running

state, that is task being

started or resumed.

If called by

PostTaskHook

hoo k routi ne this ser vice co pies contents of a

control block of a task transiting to the

waiting

ready

suspended

state,

that is task being terminated or preempted.

There is no memory control performed. User is responsible to ensure

that <TaskControlBlock> parameter points to appropriate memory block.

The system configuration option

GetTCBInfo

must be turned on to

include this service in the OSEK OS code.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_NOFUNC

– no running task, nothing done.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.3.12 Exam ples for Task Management Services

The example below assumes three tasks

TaskA

TaskB

and

TaskC

These tasks use all OSEK OS task man agement services to coordinate

each other.

System Services

Task Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 209

NON-DISCLOSURE AGREEMENT REQUIRED

The following definitions can be made in the definition file (for HC08):

...

TASK TaskA {

TYPE = BASIC;

SCHEDULE = FULL;

AUTOSTART = TRUE;

PRIORITY = 3;

StackMethod = OWNSTACK;

STACKSIZE = 64;

};

TASK TaskB {

TYPE = EXTENDED;

SCHEDULE = FULL;

AUTOSTART = FALSE;

PRIORITY = 2;

StackMethod = POOLSTACK;

StackPool = POOL1;

};

TASK TaskC {

TYPE = EXTENDED;

SCHEDULE = FULL;

AUTOSTART = TRUE;

PRIORITY = 1;

StackMethod = NODESTACK;

};

...

The C-language file:

DeclareTask( TaskA )

DeclareTask( TaskB )

DeclareTask( TaskC )

TASK( TaskA )

{

TaskType task;

TaskControlBlockType tcb;

... /* any user’s code */

ActivateTask( TaskB ); /* activate TaskB */

Schedule(); /* yields CPU to a higher-priority task */

GetTaskId( &task ); /* copies contents of TaskA control */

GetTCBInfo( &tcb ); /* block to tcb variable */

if( task == TaskA ) ActivateTask( TaskC );

else ChainTask( TaskB );

... /* any user’s code */

TerminateTask();

}

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

210 System Services MOTOROLA

TASK( TaskB )

{

TaskStateType state;

EventMaskType cc = 0x4;

... /* any user’s code */

GetTaskState( TaskC, &state ); /* check the state of TaskC */

switch( state ) /* and perform appropriate actions */

{

case READY: break;

case WAITING: SetEvent( TaskC, cc );

break;

case SUSPENDED: ChainTask( TaskC );

break;

}

... /* any user’s code */

}

TASK( TaskC )

{

TaskStateType stateA, stateB;

... /* any user’s code */

while( 1 )

{

GetTaskState( TaskA, &stateA );

GetTaskState( TaskB, &stateB );

if( stateA == READY && stateB == SUSPENDED ) ChainTask( TaskB );

if( stateB == READY && stateA == SUSPENDED ) ChainTask( TaskA );

if( stateA == READY && stateB == READY ) Schedule();

... /* any user’s code */

}

17.4 ISR Management Services

17.4.1 Data Types

The OSEK OS establishes the following data types for the interrupt

management:

•

IntDescriptorType

– the data type for logical interrupt

descriptors;

System Services

ISR Man agem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 211

NON-DISCLOSURE AGREEMENT REQUIRED

•

IntDescriptorRefType

– the data type to refer variables of the

IntDescriptorType

data type.

17.4.2 Constants

•

INITIAL_INTERRUPT_DESCRIPTOR

– constant of data type

IntDescriptorType

for

initial interrupt level (see

Section 11.5 Start-up Routine).

17.4.3 Conventions

Within the application an Interrupt Service Routine should be defined

according to the following pattern:

ISR( IsrName )

{

...

}

The keyword

ISR

is the macro for compiler specific interrupt function

modifier, which is used to generate valid code to enter and exit ISR.

If Interr upt S ervice R out ine is defi ned b y means of keywo rd

ISR

usage,

then it should be declared according to the following pattern:

DeclareISR1( IsrName )

1. Thi s servic e is not established by OSEK OS v.2.0 Spec. This is an extensi on of OSEK OS.

The same name shall be used for corresponding ISR object definition

(see Section 13.11 ISR Definition).

17.4.4 EnterISR

Syntax:

StatusType EnterISR( void );

Input:

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

212 System Services MOTOROLA

• None.

Output:

• None.

Description:

EnterISR

establishes conditions needed to request OS services within

an interrupt service routine. Inside

EnterISR

the following activities are

exec uted if needed:

• Registration of the switching to the interrupt level inside the

operating system;

• A switch of the current context (to the ISR stack).

This function is called from the begin of the interrupt service routine,

when hardware registers are pushed onto the current stack either by

hardware or by compiler generated code. This way, the context of the

running task, or ISR, or scheduler idle loop is known on the function

entry. This context is named interrupt stack frame.

If the task is interrupted, then the pointer to the interrupt stack frame is

stored in the stack pointer field of the running task. After that the top of

the ISR stack is loaded into the CPU stack pointer, and value of the

nested interrupts counter is incremented.

If the ISR is interrupted, then the value of the system counter of nested

interrupts is advanced by one, and function returns to the caller.

If the scheduler idle loop is interrupted, then interrupt stack frame is

ignored, because

LeaveISR

function returns directly to the scheduler

idle loop. The top of the ISR stack is loaded into the CPU stack pointer,

and value of the system counter of nested interrupts is changed to one.

Particularities:

EnterISR

establishes t he p ossibility to use op eratin g syste m services in

an ISR. It is necessary to place

EnterISR

before the first call of an

operating system service.

System Services

ISR Man agem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 213

NON-DISCLOSURE AGREEMENT REQUIRED

See description of interrupt categories in section Section 6.4 ISR

Categories.

This service is not implemented if the system configuration option

EntryExitISR

EnterISR

are turned off in the configuration file.

Status:

• Standard:

– None.

• Extended:

– None.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.4.5 LeaveISR

Syntax:

StatusType LeaveISR( void );

Input:

• None.

Output:

• None.

Description:

LeaveISR

is the counterpart of

EnterISR

and resets the conditions to

request operating system services in an ISR. Inside

LeaveISR

the

following functions are executed if needed:

• Registration of the switching back from the interrupt level inside

the opera ting system;

• A switch of th e current con text (for exam ple a switch fr om the ISR

stack back to the OS context or to the context of the task running

before).

In case of an error the function returns to the call level.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

214 System Services MOTOROLA

This function is called in the end of the interrupt service routine.

If the ISR was interrupted by the corresponding

EnterISR

, then the value

of the system counter of nested interrupts is decremented by one, and

the fun c tion r etur ns to the ca ller, b ecause the curre nt IS R is co nsider ed

as nested one.

If the caller is the outermost ISR (task or scheduler idle loop was

interrupted), then the function calls the scheduler to update the pointer

to the running task. After this call the function loads the task stack pointer

into the CPU stack pointer in assumption, that task stack pointer

contai ns the addr ess of valid interr upt stack fram e. If there is n o runni ng

task, then functi ons goes directly to t he schedul er idle loop. In any ca se

the value of the nested interrupts counter is decre mented by one.

Particularities:

LeaveISR eliminates the possibility of using OS services in an ISR. It is

highly recommended to place LeaveISR at the end of the ISR.

See description of interrupt categories in section Section 6.4 ISR

Categories.

This service is not implemented if the system configuration option

EntryExitISR

LeaveISR

are turned off in the configuration file.

Status:

• Standard:

– None.

• Extended:

– None.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.4.6 EnableInterrupt

Syntax:

StatusType EnableInterrupt( IntDescriptorType <Mask> );

System Services

ISR Man agem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 215

NON-DISCLOSURE AGREEMENT REQUIRED

Input:

•

<Mask>

– a mask of interr upts to be enabled. In the

mask, a “1” means “enable”.

Output:

• None.

Description:

This service enables interrupts specified by

<Mask>

. In the case if

several interrupts can be controlled simultaneously, this service allows

enabling of several interrupts.

Particularities:

The service may be called from an ISR and from the task level.

For HC12 this service is intended to control only the “I” bit in the

Condition Code Register.

This service should only be used with care. It destroys the contents of

CCR according to C language conventions. In case of use it is highly

recommended to know the reaction upon system behavior!

To save the current state of interrupts the application must use

GetInterruptDescriptor

before.

This service is executed also in case of return of the state is not equal

E_OK

This service is not implemented if the system configuration option

EntryExitISR

EnableInterrupt

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_NOFUNC

– at least one of the interrupts was not

disabled.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

216 System Services MOTOROLA

Conformance: BCC1 , BCC2, ECC1, ECC2

17.4.7 DisableInterrupt

Syntax:

StatusType DisableInterrupt( IntDescriptorType <Mask> );

Input:

•

<Mask>

– a mask of interr upts to be disabled. In the

mask, a “1” means “disable”.

Output:

• None.

Description:

This service disables interrupts specified by

<Mask>

. In the case if

several interrupts can be controlled simultaneously, this service allows

disabling of several interrupts.

Particularities:

The service may be called from an ISR and from the task level.

For HC12 this service is intended to control only the “I” bit in the

Condition Code Register.

This service should only be used with care. It destroys the contents of

CCR according to C language conventions. In case of use it is highly

recommended to know the reaction upon system behavior!

To save the current state of interrupts the application must use

GetInterruptDescriptor

before.

This service is executed also in case of return of the state is not equal

E_OK

This service is not implemented if the system configuration option

EntryExitISR

DisableInterrupt

are turned off in the configuration file.

Status:

System Services

ISR Man agem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 217

NON-DISCLOSURE AGREEMENT REQUIRED

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_NOFUNC

– at least one of the interrupts was not

enabled.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.4.8 GetInterruptDescriptor

Syntax:

StatusType GetInterruptDescriptor( IntDescriptorRefType <Mask> );

Input:

• None.

Output:

•

<Mask>

– a reference to the interrupt mask to be

filled. In the mask, a “1” means (Group of)

Interrupt is enabled”.

Description:

Query of interrupt status and returns the current CPU interrupt mask.

Particularities:

The service may be called from an ISR and from the task level.

For HC12 th is service i s intended to get only t he value o f the “I” bit in th e

Condition Code Register.

This service is not implemented if the system configuration option

EntryExitISR

GetInterruptDescriptor

are turned off in the configuration

file.

Status:

• Standard:

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

218 System Services MOTOROLA

–

E_OK

– no error.

• Extended:

– None.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.4.9 Examples for Interrup t Managemen t Services

Below examples for ISR category 1, 2 and 3 are presented.

The following definitions can be made in the definition file (for HC08):

...

OS myOS {

...

IsrStackSize = 64;

InterruptMaskControl = TRUE;

DisableInterruptMask = 0x0;

EnableInterruptMask = 0x8;

TaskLevelMask = 0x8;

...

};

TASK TaskB {

TYPE = EXTENDED;

SCHEDULE = FULL;

PRIORITY = 2;

AUTOSTART = FALSE;

StackMethod = POOLSTACK;

StackPool = POOL1;

};

TASK IndTask {

TYPE = BASIC;

SCHEDULE = FULL;

AUTOSTART = TRUE;

PRIORITY = 1;

StackMethod = OWNSTACK;

STACKSIZE = 64;

};

COUNTER Ctr1 {

MAXALLOWEDVALUE = 24;

TICKSPERBASE = 1;

};

MESSAGE Temp {

TYPE = UNQUEUEDMESSAGE;

ITEMTYPE = "char";

ITEMS = 1;

WithCopy = TRUE;

System Services

ISR Man agem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 219

NON-DISCLOSURE AGREEMENT REQUIRED

};

MESSAGE Wrn {

TYPE = QUEUEDMESSAGE;

ITEMTYPE = "MSGCTYPE";

ITEMS = 6;

ReceiverNum = 3;

};

ISR ISR1_handler {

CATEGORY = 1;

};

ISR ISR2_handler {

CATEGORY = 2;

};

ISR ISR3_handler {

CATEGORY = 3;

};

...

The C-language code can be the following (for HC08):

ISR category 1:

char CREG, DREG;

char data1;

DeclareISR( ISR1_handler )

...

ISR( ISR1_handler )

{

if( CREG != 0xC0 ) CREG |= 0x40;

else CREG |= 0x03;

DREG = data1;

}

ISR category 2:

TaskStateType stateB;

DeclareCounter( Ctr1 )

DeclareTask( TaskB )

DeclareISR( ISR2_handler )

...

ISR( ISR2_handler )

{

CounterTrigger( Ctr1 );

GetTaskState( TaskB, &stateB );

if( stateB == SUSPENDED ) ActivateTask( TaskB );

}

ISR category 3:

DeclareTask( IndTask )

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

220 System Services MOTOROLA

DeclareISR( ISR3_handler )

OSMSGTemp _Temp;

OSMSGWrn _Wrn;

int temp;

ISR( ISR3_handler )

{/* normal temperature, do nothing */

if( (temp >= LIMIT_L ) && (temp <= LIMIT_H) ) goto exit;

/* temperature is below critical value: */

if( LIMIT_L >= temp )

{ EnterISR();

SendMessage( Temp, _Temp ); /* send msg to notify */

goto leave;

}

/* temperature is higher critical value: */

if( (temp >= LIMIT_H) )

{ EnterISR();

SendMessage( Wrn, _Wrn ); /* send alarm message */

ActivateTask( IndTask );

leave: LeaveISR();

}

exit: ;

}

17.5 Resource Managemen t Services

17.5.1 Data types

The OSEK OS establishes the following data type for the resource

management:

•

ResourceType

– the abstract data type for referencing a

resource;

The only data type must be used for operations with tasks.

17.5.2 Constants

•

RES_SCHEDULER

– constant of data type

ResourceType

(see

Section 7.3.2 Scheduler as a Resource).

System Services

Resource Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 221

NON-DISCLOSURE AGREEMENT REQUIRED

17.5.3 Resource Declaration

To refer to a resource the constructional element should be used to

declare the resource before its using:

Syntax:

DeclareResource( ResourceType <ResName> )

Input:

•

– a reference to the resource.

Description:

DeclareResource

serves as an external declaration of a resource. The

function and use of this service are similar to that of the external

declaration of variables.

Particularities: none

Conformance: BCC1 , BCC2, ECC1, ECC2

17.5.4 GetResource

Syntax:

StatusType GetResource( ResourceType <ResName> );

Input:

•

– a reference to the resource.

Output:

• None.

Description:

This call serves to enter a critical section in the code tha t is assigned to

the referenced resource. A critical section must always be left using

ReleaseResource

The

E_OS_LIMIT

error code is not processed yet.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

222 System Services MOTOROLA

Particularities:

This function is fully supported only beginning from the Conformance

Class BCC2. In the lower Conformance Classes only the standard

resource scheduler can be occupied via the constant

RES_SCHEDULER

Corresponding calls to

GetResource

and

ReleaseResource

should

appear within the same function on the same function level. Generally,

critical sections should be short. Nested resource occupation is only

allowed if the inner critical sections are executed completely within the

surrounding critical section.

Regarding Extended T asks, please note that

WaitEvent

within a critical

section is prohibited.

E_OS_ACCESS

error code is not returned by

GetResource

service if

more than 8 resources (including

RES_SCHEDULER

) are defined in the

appl icati on or

FastResource

configuration option is turned on or

ResourceAccessCheck

configuration option is turned off.

This service is not implemented if the system configuration option

Resources

GetResource

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the resource identifier is invalid;

–

E_OS_ACCESS

– the inadmissible access to

resource;

–

E_OS_CALLEVEL

– a call at the interru pt level is not

allowed;

–

E_OS_LIMIT

– too many resources are occupied in

parallel.

Conformance: BCC1 , BCC2, ECC1, ECC2

System Services

Resource Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 223

NON-DISCLOSURE AGREEMENT REQUIRED

17.5.5 ReleaseResource

Syntax:

StatusType ReleaseResource( ResourceType <ResName> );

Input:

•

– a reference to the resource.

Output:

• None.

Description:

This call serves to leave the critical section in the code that is assigned

to th e refer enced re source. A n

ReleaseResource

call is a counterpart of

GetResource

service ca ll.

The

E_OS_ID

error code is generated in the following cases:

• the resource signature is invalid – this object is not resource;

• the resource is occupied by another task, the resource is not

released in this case;

• the resource is not the last occupied re source (a nesting

processi ng erro r), the reso urce is rel eased (unlinked from the l ist)

in this case.

Particularities:

This function is fully supported only beginning from the Conformance

Class BCC2. In the lower Conformance Classes only the standard

resource scheduler can be released via the constant

RES_SCHEDULER

For information on nesting conditions, see particularities of

GetResource

. This service is not implemented if the system

configuration option

Resources

ReleaseResource

are turned off in the

configuration file.

Status:

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

224 System Services MOTOROLA

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the resource identifier is invalid;

–

E_OS_NOFUNC

– an attempt to release a resource

which is not occupied;

–

E_OS_CALLEVEL

– a call at the interru pt level is not

allowed.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.5.6 Examp les of Using Resources

The exam ple below presents resource management directives.

The following definitions can be made in the definition file (for HC08):

...

TASK TASK_A {

TYPE = EXTENDED;

SCHEDULE = FULL;

AUTOSTART = FALSE;

PRIORITY = 3;

StackMethod = POOLSTACK;

StackPool = POOL1;

};

TASK TASK_B {

TYPE = BASIC;

SCHEDULE = FULL;

PRIORITY = 2;

AUTOSTART = TRUE;

RESOURCE = { SCI_res };

StackMethod = OWNSTACK;

STACKSIZE = 64;

};

TASK SCI_TASK {

TYPE = BASIC;

SCHEDULE = FULL;

PRIORITY = 1;

AUTOSTART = TRUE;

RESOURCE = { SCI_res };

StackMethod = NODESTACK;

};

RESOURCE SCI_res {

System Services

Counters and Alar ms Management Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 225

NON-DISCLOSURE AGREEMENT REQUIRED

}

};

...

The C-language code can be the following:

DeclareTask( SCI_TASK )

DeclareResource( SCI_res )

TASK( SCI_TASK )

{

...

GetResource( SCI_res ); /* occupy the SCI resource */

... /* user’s code */

ActivateTask( TASK_B );

GetResource( RES_SCHEDULER ); /* occupy the scheduler resource */

... /* user’s code */

ReleaseResource( RES_SCHEDULER ); /* release the scheduler */

ReleaseResource( SCI_res ); /* release the SCI resource */

TerminateTask();

}

17.6 Count ers and Alarms Managem ent Services

17.6.1 Data Types and Iden tifiers

The following data types are established by OSEK OS to work with

counters:

•

CtrRefType

– the data type references a counter

•

TickType

– the data type represent count value in

system ticks

•

TickRefType

– the data type references data

corresponding to the data type

TickType

•

CtrInfoType

– the data type represents a stru cture for

storage of counter characteristics. This

structure has the following elements:

–

maxallowedvalue

– maximum possibl e allowed counter

value;

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

226 System Services MOTOROLA

–

ticksperbase

– number of ticks require d to reach a

counter-specific significant unit;

–

mincycle

– minimum allowed number of ticks

for a cyclic alarm (only for system with

Extended Status).

All elements have the data type

TickType

, and the stru cture looks like

the following:

typedef CtrInfoType tagCIT;

struct tagCIT

{ TickType maxallowedvalue;

TickType ticksperbase;

TickType mincycle;

};

•

CtrInfoRefType

– the data type references data

corresponding to the data type

CtrInfoType

The fol lowing data type is e s tablished by OS EK OS to wo rk wi th alar ms:

•

AlarmBaseType

– the data type represents a stru cture for

storage of alarm characteristics. It is the

same as

CtrInfoType

;

•

AlarmBaseRefType

– the data type references data

corresponding to the data type

AlarmBaseType

;

•

AlarmType

– the data type represents an alarm element.

17.6.2 Constants

For system counter, which is always a time counter, the special

constants are provided by the operating system:

•

OSMAXALLOWEDVALUE

– maximum possible allowed value of the

system timer in ticks (see also

Section 13.8.1 Object Attributes);

System Services

Counters and Alar ms Management Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 227

NON-DISCLOSURE AGREEMENT REQUIRED

•

OSTICKSPERBASE

– number of ticks that are required to reach

OSTICKPERTIME

milliseconds in the

system coun ter (see also

Section 13.8.1 Object Attributes);

•

OSTICKDURATION –

duration of a tick of the system counter in

nanoseconds ( defined automatically by

System Generator utility (SG)

(see

Section 12.2 General ), through

OSTICKSPERBASE

value);

•

OSMINCYCLE

– minimum allowed number of ticks for a

cyclic alarm (only for system with Extended

Status, see also Section 13.8.1 Object

Attributes).

17.6.3 Counter and Alarm Declaration

To refer to a counter or alarm the declaration statements should be used

to declare the element (counter or alarm) befor e their using:

17.6.3.1 Counter Declaration

Syntax:

DeclareCounter( CtrRefType <CounterName> )

Input:

•

– a reference to the counter

Description:

DeclareCounter

serves as an external declaration of a counter. The

function and use of this service are similar to that of the external

declaration of variables.

Particularities: none

Conformance: BCC1 , BCC2, ECC1, ECC2

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

228 System Services MOTOROLA

17.6.3.2 Alarm Declaration

Syntax:

DeclareAlarm( AlarmType <AlarmName> )

Input:

•

– a reference to the alarm

Description:

DeclareAlarm

serves as an external declaration of an alarm. The

function and use of this service are similar to that of the external

declaration of variables.

Particularities: none

Conformance: BCC1 , BCC2, ECC1, ECC2

These declarations are equivalent to the external declaration of

variables.

17.6.4 InitCounter

Syntax:

StatusType InitCounter( CtrRefType <CounterName>,

TickType <Ticks>

);

Input:

•

– a reference to the counter;

•

<Ticks>

– a counter initialization value in ticks.

Output:

• None.

Description:

Sets the in itial value of th e counter with the va lu e

<Ticks>

. After this ca ll

the counte r will advance this initial value by one via the following call of

System Services

Counters and Alar ms Management Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 229

NON-DISCLOSURE AGREEMENT REQUIRED

CounterTrigger

. If there are running attached alarms, then their state

stays unchanged.

Particularities:

This service is not implemented if the system configuration option

Counters

InitCounter

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the counter identifier is invalid;

–

E_OS_VALUE

– the counter initialization value

exceeds the maximum admissible

value;

–

E_OS_CALLEVEL

– a call at interrupt level (not

allowed).

Conformance: BCC1 , BCC2, ECC1, ECC2

17.6.5 CounterTrigger

Syntax:

StatusType CounterTrigger( CtrRefType <CounterName> );

Input:

•

– a reference to the counter;

Output:

• None.

Description:

Increments the current value of the counter. If the counter reaches the

value

maxallowedvalue

(see Section 17.6.1 Data Types and

Identifiers), it is reset to “zero”.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

230 System Services MOTOROLA

If alarms are linked to the counter, the system checks whether they

expired after this tick and performs appropriate actions (task activation

and event setting).

Particularities:

Call admissible both from interrupt and task levels.

Depending on the underlying hardware it is possible that parts of the

functi onality of

CounterTrigger

may by done by the hardware. In this

case the remaining functionality of

CounterTrigger

has to be adapted .

This service is not implemented if the system configuration option

Counters

CounterTrigger

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the counter identifier is invalid.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.6.6 AdvanceCounter

Syntax:

StatusType AdvanceCounter( CtrRefType <CounterName>,

TickType <Ticks> );

Input:

•

– a reference to the counter;

• <Ticks

– a number of ticks to be advanced.

Output:

• None.

Description:

System Services

Counters and Alar ms Management Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 231

NON-DISCLOSURE AGREEMENT REQUIRED

Advances the current value of the counter.

If alarms ar e linked to the counter, the system checks whether they

expired during specified number of ticks and performs appropriate

actions (task activation and event setting).

This service is not defined in the OSEK OS v.2.0 rev. 1 specification.

This is an extension of OSEK OS.

Particularities:

Call admissible from task level only.

This service is not implemented if the system configuration option

Counters

AdvanceCounter

are turned off in the configuration file.

Status:

• Standard:

– E_OK – no error;

– E_OS_VALUE – specified value is greater than

maxallowedvalue.

• Extended:

– E_OS_ID – the counter identifier is invalid.

– E_OS_CALL EVEL – call at interrupt level is invalid.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.6.7 GetCounterValue

Syntax:

StatusType GetCounterValue( CtrRefType <CounterName>,

TickRefType <Ticks> );

Input:

•

– a reference to the counter;

Output:

•

<Ticks>

– a counter value in ticks.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

232 System Services MOTOROLA

A reference to the return counter value in ticks.

Description:

The system service provides the current value of the counter

CounterName>

in ticks.

Particularities:

This service is not implemented if the system configuration option

Counters

GetCounterValue

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the counter identifier is invalid;

–

E_OS_CALLEVEL

– a call at interrupt level (not allowed).

Conformance: BCC1 , BCC2, ECC1, ECC2

17.6.8 GetCounterInfo

Syntax:

StatusType GetCounterInfo( CtrRefType <CounterName>,

CtrInfoRefType <Info> );

Input:

•

– a reference to the counter;

Output:

•

<Info>

– a reference to the structure with constan ts

of the counter.

Description:

Returns the counter characteristics into the

<Info>

structure. For a

system coun ter special constants may be used instead of this service.

System Services

Counters and Alar ms Management Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 233

NON-DISCLOSURE AGREEMENT REQUIRED

The re turn value

<Info>

is a structure in which the information of data

type

CtrInfoType

is stored.

Particularities:

The str ucture consists of tw o elemen ts in case of the “S tandard Stat us”,

and of three elements in case of the “Extended Status”.

This service is not implemented if the system configuration option

Counters

GetCounterInfo

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the counter identifier is invalid;

–

E_OS_CALLEVEL

– a call at interrupt level (not

allowed).

Conformance: BCC1 , BCC2, ECC1, ECC2

17.6.9 SetRelAlarm

Syntax:

StatusType SetRelAlarm( AlarmType <AlarmName>,

TickType <Increment>,

TickType <Cycle> );

Input:

•

– a reference to the alarm;

•

– a relative value in ticks;

•

<Cycle>

– an alarm cycle value in ticks in case of

cyclic alarm. In case of single alarms, the

value cycle has to be equal zero.

Output:

• None.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

234 System Services MOTOROLA

Description:

The system service occupies the alarm

element. After

this service call the counter will count

ticks starting from the

curren t count er value at the mom ent of t he cal l. After

ticks

have elapsed from that moment, the task assigned to the alarm

is activated or the assigned event (only for Extended

Tasks) is set.

<Cycle>

is unequal 0, the alarm element is logged on again

im mediat ely after expiry w ith th e relati ve value

<Cycle>

. Otherw ise, the

alarm triggers only once.

Particularities:

If the relative value

is very small, the alarm may

immediately expire, and the task may become

ready

. It is because the

certain time is needed for system activities to return to the calling task

after the

ticks for the counter have been set.

The al arm

must not al ready be in use. T o change values

of alarms already in use the alarm has to be cancelled first.

This service is not implemented if the system configuration option

Alarms

SetRelAlarm

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error;

–

E_OS_STATE

– the alarm is already in use.

• Extended:

–

E_OS_ID

– the alarm identifier is invalid;

–

E_OS_VALUE

– the alarm initialization value or cycle

value is greater than the maximum

allowed value of the counter, or the

cycle value is less than the minimum

cycle value of the counter .

Conformance:

System Services

Counters and Alar ms Management Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 235

NON-DISCLOSURE AGREEMENT REQUIRED

• BCC1, BCC2;

• Events: ECC1, ECC2.

17.6.10 SetAbsAlarm

Syntax:

StatusType SetAbsAlarm( AlarmType <AlarmName>,

TickType <Start>,

TickType <Cycle> );

Input:

•

– a reference to the alarm;

•

<Start>

–an absolute value in ticks;

•

<Cycle>

– an alarm cycle value in ticks in case of

cyclic alarm. In case of single alarms, cycle

has to be equal zero.

Output:

None.

Description:

The system service occupies the alarm

element. The

counter will count

<Start>

ticks starting from zero counter value. When

<Start>

ticks are reached, the task assigned to the alarm

is activated or the assigned event (only for Extended Tasks) is set.

<Cycle>

is unequal 0, the alarm element is logged on again

im mediat ely after expiry w ith th e relati ve value

<Cycle>

. Otherw ise, the

alarm triggers only once.

Particularities:

Since the current counter value at the moment of the service call is most

likely not equal zero, there exist the some period of time while the

counter reaches its maximum allowed value and will be logge d on aga in

(its value will become 0). Only starting from zero

<Start>

ticks will be

counted.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

236 System Services MOTOROLA

If the absolute value

<Start>

is very close to the current counter value,

the alarm may immediately expire, and the task may become

ready

(E.g., the current counter value at the moment of service call equals 253,

the maximum allowed counter value equals 255 and the

<Start>

value is

2.)

The alarm

must not already be in use.

To change values of alarms a lready in use the alarm has to be cancelled

first.

This service is not implemented if the system configuration option

Alarms

SetAbsAlarm

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error;

–

E_OS_STATE

– the alarm is already in use.

• Extended:

–

E_OS_ID

– the alarm identifier is invalid;

–

E_OS_VALUE

– the alarm initialization value or cycle

value is greater than the maximum

allowed value of the counter, or the

cycle value is less than the minimum

cycle value of the counter .

Conformance:

• BCC1, BCC2;

• Events: ECC1, ECC2.

17.6.11 CancelAlarm

Syntax:

StatusType CancelAlarm( AlarmType <AlarmName> );

Input:

System Services

Counters and Alar ms Management Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 237

NON-DISCLOSURE AGREEMENT REQUIRED

•

– a reference to the Alarm.

Output:

None.

Description:

The service cancels the alarm (transfers it into the stop state).

Particularities:

This service is not implemented if the system configuration option

Alarms

CancelAlarm

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error;

–

E_OS_NOFUNC

– the alarm is not in use.

• Extended:

–

E_OS_ID

– the alarm identifier is invalid.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.6.12 GetAlarmBase

Syntax:

StatusType GetAlarmBase( AlarmType <AlarmName>,

AlarmBaseRefType <Info> );

Input:

•

– a reference to the Alarm;

Output:

•

<Info>

– a reference to the structure with constan ts

of the alarm base.

Description:

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

238 System Services MOTOROLA

Returns the alarm base characteristics into the

<Info>

structure. The

return value

<Info>

is a structure in which the information of data type

AlarmBaseType

is stored.

Particularities:

The str ucture consists of tw o elemen ts in case of the “S tandard Stat us”,

and of three elements in case of the “Extended Status”.

This service is not implemented if the system configuration option

Alarms

GetAlarmBase

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the alarm identifier is invalid.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.6.13 GetAlarm

Syntax:

StatusType GetAlarm( AlarmType <AlarmName>,

TickRefType <Ticks> );

Input:

•

– a reference to the Alarm;

Output

•

<Ticks>

– a refer ence to a variabl e ( or memo ry fi eld

) which gets a r elative value in ticks before

the alarm expires.

Description:

This service calculates the time in ticks before the alarm expires. If the

alarm is not started the

E_OS_NOFUNC

error code is generated.

System Services

Counters and Alar ms Management Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 239

NON-DISCLOSURE AGREEMENT REQUIRED

Particularities:

It is up to the application to decide whether for example an alarm may

still be useful or not.

is not in use <

Ticks>

is 0.

This service is not implemented if the system configuration option

Alarms

GetAlarm

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error;

–

E_OS_NOFUNC

– the alarm is not in use.

• Extended:

–

E_OS_ID

– the alarm identifier is invalid.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.6.14 Exam ples for Counter and Alarm Management

The exam ple shows how counters and alarms can be used.

The following definitions are made in the definition file (for HC08):

...

TASK TaskTime {

TYPE = EXTENDED;

SCHEDULE = FULL;

AUTOSTART = FALSE;

PRIORITY = 3;

StackMethod = POOLSTACK;

StackPool = POOL1;

};

TASK TASK_B {

TYPE = BASIC;

SCHEDULE = FULL;

AUTOSTART = TRUE;

PRIORITY = 2;

StackMethod = OWNSTACK;

STACKSIZE = 64;

};

TASK TASK_X {

TYPE = BASIC;

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

240 System Services MOTOROLA

SCHEDULE = FULL;

AUTOSTART = TRUE;

PRIORITY = 1;

StackMethod = NODESTACK;

};

COUNTER TimeCnt {

MAXALLOWEDVALUE = 127;

TICKSPERBASE = 1;

};

COUNTER DgrCnt {

MAXALLOWEDVALUE = 36;

TICKSPERBASE = 1;

};

ALARM TimeAlm {

ACTION = ACTIVATETASK;

COUNTER = TimeCnt;

TASK = TASK_X;

};

ALARM DgrAlm {

ACTION = SETEVENT;

COUNTER = DgrCnt;

TASK = TASK_B;

EVENT = DgrAlmEvent;

};

EVENT DgrAlmEvent {

MASK = 0x01;

};

MESSAGE Norm {

TYPE = QUEUEDMESSAGE;

ITEMTYPE = "int";

ITEMS = 6;

ReceiverNum = 3;

};

...

The alarm

TimeAlm

activates the task

TASK_X

when the counter

TimeCnt

expires. The alarm

DgrAlm

sets the specified event for the

task

TASK_B

when the counter

DgrCnt

expires.

The C-language code can be the following:

DeclareTask( TASK_B )

DeclareTask( TaskTime )

DeclareTask( TASK_X )

DeclareCounter( TimeCnt )

DeclareCounter( DgrCnt )

DeclareAlarm( TimeAlm )

DeclareAlarm( DgrAlm )

OSMSGNorm _Norm;

System Services

Counters and Alar ms Management Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 241

NON-DISCLOSURE AGREEMENT REQUIRED

TASK( TaskTime )

{

TickType curTime;

TickType ticksToExpire;

OSBYTE i=0;

InitCounter( TimeCnt, 0 ); /* init time counter with 0 value */

AdvanceCounter( TimeCnt, 2 ); /* increments counter value by 2 */

while (i != 1) {

GetCounterValue( TimeCnt, &curTime ); /* read TimeCnt value */

if( curTime == CONST )

{ /* if desired value, activate TaskB */

ActivateTask( TASK_B );

SetRelAlarm( TimeAlm, 10, 0 );

/* activate TaskX when TimeCnt reaches 10 */

GetAlarm( TimeAlm, &ticksToExpire );

/* just for example: TimeAlm will

expire after ‘ticksToExpire’ ticks of TimeCnt */

}

if( curTime > CONST )TerminateTask();

/* if more than desired value, terminate the task */

}

TASK( Task_B )

{

OSMSGNorm _Norm;

EventMaskType evMask;

evMask = 0x01;

InitCounter( DgrCnt, 0 ); /* init degree counter with 0 value */

SetAbsAlarm( DgrAlm, 75, 15 ); /* set cyclic alarm */

WaitEvent( evMask );

/* wait for event which must be set by the alarm */

_Norm = 1; /* wake up and send the message that all is OK */

SendMesssage( Norm, _Norm);

TerminateTask();

}

ISR( Timer_Isr )

{

... /* reset the hardware */

EnterISR();

CounterTrigger( TimeCnt ); /* increment the counter */

LeaveISR();

}

ISR( Dgr_Isr )

{

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

242 System Services MOTOROLA

... /* reset the hardware */

EnterISR();

CounterTrigger( DgrCnt ); /* increment the counter */

LeaveISR();

}

17.7 Event Manage ment Services

17.7.1 Data Types

The OSEK Operating System establishes the following data types for the

event management:

•

EventMaskType

The data type of the event mask;

•

EventMaskRefType

The data type to refer to an event mask.

The only data types must be used for operations with events.

17.7.2 Event Declaration

To refer to a event the constructional element should be used to declare

the event before its using:

Syntax:

DeclareEvent( EventMaskType <Event> )

Input:

•

<Event>

– event name.

Description:

DeclareEvent

serves as an external declaration of an event. The

function and use of this service are similar to that of the external

declaration of variables.

Particularities: none

Conformance: ECC1 , ECC2

System Services

Event Man agem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 243

NON-DISCLOSURE AGREEMENT REQUIRED

17.7.3 SetEvent

Syntax:

StatusType SetEvent( TaskType <TaskName>,

EventMaskType <Mask> );

Input:

•

– a reference to the task (the task’s name).

•

<Mask>

– an event mask to be set.

Output:

•None

Description:

This service is used to set one or several events of the desired task

according to the event mask. If the task was

waiting

for at least one of

the specified events, then it is transferred into the

ready

state. The

events no t speci fied by the mask r ema in uncha nged . Onl y an extend ed

task may be referenced to set an event.

Particularities:

Any events not set in the event mask remain unchanged.

It is possible to set events for the running task (task-caller).

This service is not implemented if the system configuration option

Events

SetEvent

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the task identifier is invalid;

–

E_OS_ACCESS

– the referenced task is not an

Extended Task;

–

E_OS_STATE

– the referenced task is in the

suspended state;

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

244 System Services MOTOROLA

Conformance: ECC1 , ECC2

17.7.4 ClearEvent

Syntax:

StatusType ClearEvent( EventMaskType <Mask> );

Input:

•

<Mask>

– an event mask to be cleared.

Output:

• None.

Description:

The task which calls this service defines the event which has to be

cleared.

Particularities:

The system service

ClearEvent

is restricted to Extended Tasks.

This service is not implemented if the system configuration option

Events

ClearEvent

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ACCESS

– the calling task is not an Extended

Task;

–

E_OS_CALLEVEL

– a call at the interru pt level is not

allowed.

Conformance: ECC1 , ECC2

System Services

Event Man agem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 245

NON-DISCLOSURE AGREEMENT REQUIRED

17.7.5 GetEvent

Syntax:

StatusType GetEvent( TaskType <TaskName>,

EventMaskRefType <Event> );

Input:

•

– a reference to the task.

Output:

•

<Event>

– a pointer to the event mask to be filled.

Description:

The event mask which is referenced to in the call is filled according to the

current state of the events of the desired task.

It is possible to get event mask of the running task (task-caller).

Particularities:

The re ferenced task must be an extended task.

This service is not implemented if the system configuration option

Events

GetEvent

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ID

– the task identifier is invalid;

–

E_OS_ACCESS

– the referenced task is not an

Extended Task;

–

E_OS_STATE

– the referenced task is in the

suspended state;

Conformance: ECC1 , ECC2

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

246 System Services MOTOROLA

17.7.6 WaitEvent

Syntax:

StatusType WaitEvent( EventMaskType <Mask> );

Input:

•

<Mask>

– an event mask to wait for.

Output:

• None.

Description:

The calling task is transferred into the waiting state until at least one of

the events specified by the mask is set.

Particularities:

This call enforces the rescheduling, if the wait condition occurs.

This service is not implemented if the system configuration option

Events

WaitEvent

are turned off in the configuration file.

Status:

• Standard:

–

E_OK

– no error.

• Extended:

–

E_OS_ACCESS

– the calling task is not an Extended

Task;

–

E_OS_RESOURCE

– the ca lling task o ccupies r esou rces;

–

E_OS_CALLEVEL

– a call at the interru pt level is not

allowed.

Conformance: ECC1 , ECC2

System Services

Event Man agem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 247

NON-DISCLOSURE AGREEMENT REQUIRED

17.7.7 Examples of Using Events

The exam ple below shows how events can be used in the OSEK

Operating System.

The following definitions can be made in the definition file (for HC08):

...

TASK TASK_A {

TYPE = EXTENDED;

SCHEDULE = FULL;

AUTOSTART = TRUE;

PRIORITY = 3;

StackMethod = OWNSTACK;

STACKSIZE = 64;

};

TASK TASK_B {

TYPE = EXTENDED;

SCHEDULE = FULL;

AUTOSTART = FALSE;

PRIORITY = 3;

StackMethod = POOLSTACK;

StackPool = POOL1;

};

TASK TASK_C {

TYPE = BASIC;

SCHEDULE = FULL;

AUTOSTART = TRUE;

PRIORITY = 1;

StackMethod = NODESTACK;

};

COUNTER DgrCnt {

MAXALLOWEDVALUE = 150;

TICKSPERBASE = 1;

};

ALARM AWAKE {

ACTION = SETEVENT;

COUNTER = DgrCnt;

TASK = TASK_B;

EVENT = DgrAlmEvent;

};

EVENT DgrAlmEvent {

MASK = 0x01;

};

MESSAGE Norm {

TYPE = QUEUEDMESSAGE;

ITEMTYPE = "int";

ITEMS = 6;

ReceiverNum = 3;

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

248 System Services MOTOROLA

};

...

The C-language file:

#define X_FLG 0x80 /* define masks for internal flags */

#define Y_FLG 0x40 /* #define may be used for event masks */

#define Z1_FLG 0x20 /* in other case evnt masks should be */

#define Z2_FLG 0x10 /* generated by SG tool and established */

/* via DeclareEvent() */

DeclareTask( TASK_A ) /* the extended tasks */

DeclareTask( TASK_B )

DeclareTask( TASK_C ) /* the basic task */

TASK( TASK_A ) /* Extended task TASK_A */

{

EventMaskType aa = 3; /* ‘external’ events */

EventMaskType x, z1 = Z1_FLG, /* ‘internal’ events (flags) */

z2 = Z2_FLG;

int speed;

...

/* Check the variable and set internal flag if needed */

if (speed == LIMIT)

{

x = X_FLG;

SetEvent( TASK_A, x );

}

...

GetEventMask( TASK_A, &x ); /* check internal flag */

/* Perform some actions in accordance with internal flag status */

if ((x & X_FLG) != 0 ) ClearEvent( z1 );

else SetEvent( TASK_A, z2 );

if ((x & Y_FLG) == 0 ) ChainTask( TASK_C );

...

WaitEvent( aa ); /* the task is stopped until one of three

‘external’ events is set by another task */

ClearEvent( aa ); /* clear all ‘external’ events after

awakening */

...

}

#define EVMASK1 0x01 /* event mask definitions */

#define EVMASK2 0x02

#define EVMASK3 0x04

System Services

Commun ication Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 249

NON-DISCLOSURE AGREEMENT REQUIRED

TASK( TASK_B ) /* Extended task TASK_B */

{

EventMaskType b_ev, a_ev;

b_ev = EVMASK1 | EVMASK3;

InitCounter( DgrCnt, 10 ); /* initialize the counter */

...

SetRelAlarm( AWAKE, 20, 0 ); /* this alarm will awake the task */

WaitEvent( b_ev ); /* waiting for one of two events */

/* The task will be ready again when one of two events are set. One of

them - EVMASK1 will be set by the alarm AWAKE after 20 ticks of the counter

DgrCnt. Thus, the task can delay itself. */

ClearEvent( b_ev ); /* clear all events */

GetEvent( TASK_A, &a_ev ); /* get events of TASK_A */

if ( (a_ev & EVMASK2) == 0)

{

a_ev = EVMASK2;

SetEvent( TASK_A, a_ev );

} /* set the event for TASK_A */

...

}

TASK( TASK_C ) /* Basic task TASK_C */

{

EventMaskType bb, set;

set = EVMASK3;

...

GetEventMask( TASK_B, &bb ); /* if the event is clear, set it */

if ((bb & EVMASK3) == 0 ) SetEvent( TASK_B, set );

...

}

17.8 Communication Management Services

17.8.1 Data Types and Iden tifiers

The following names are used in the OSEK Operating System for work

with messages:

•

SymbolicName

This is an unique name representing a

message. It only can be used in

conjunction with calls of the message

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

250 System Services MOTOROLA

service. A

SymbolicName

need not be a

data type. Variables or constants of

SymbolicName

can be declared or used.

•

AccessName

This is a unique name defining access to

a message object. Depending on the

chosen configuration, a distinction is

made between the following

AccessName

scheme:

WithCopy

configuration:

A application variable exists as a local

copy of the message. The name of the

variable is the

AccessName

. This variable

contains a copy of the corresponding

message object.

WithoutCopy

configuration:

The me ssage object data is a ccessed via

the

AccessName

. This

AccessName

is a

static link: it refers directly to the message

object data. The

AccessName

refers to

the same data (RAM) as the message

object.

17.8.2 SendMessage

Syntax:

StatusType SendMessage ( SymbolicName <Message>, AccessName <Data> )

Input:

•

– symbolic name of the message object,

•

<Data>

– AccessName of the message data to be

sent.

Output:

• None.

System Services

Commun ication Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 251

NON-DISCLOSURE AGREEMENT REQUIRED

Description:

In case of

WithCopy

This service updates the message object

with the Data

given by

<Data>

and requests the transmission of the message obje ct to

the receiving entities. The message object is locked during this update

and d uring the transmission of the data to the underlying communication

layer. The message object is not updated if it is already locked. This

service updates also the status information of the message object

accordingly.

In case of

WithoutCopy

– Possible for unqueued message type only –

This service requests th e transmission of the al ready updated m essage

object to the receiving entities via the bus.

Particularities:

SendMessage

does not verify whether the message object has been

initialized prior to sending it.

Status:

• Standard:

WithCopy

–

E_OK

– message object updated,

–

E_COM_LOCKED

– message object locked.

WithoutCopy

–

E_OK

– successful operation,

–

E_COM_LOCKED

– message object locked.

• Extended:

–

E_COM_ID

– invalid parameter

Conformance: N/A

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

252 System Services MOTOROLA

17.8.3 ReceiveMessage

Syntax:

StatusType ReceiveMessage ( SymbolicName <Message>,AccessName <Data>)

Input:

•

– symbolic name of the message object.

Output:

•

<Data>

– AccessName of the message data to be

received

Description:

In case of

WithCopy

This service delivers the message data associated with the message

object

to the applications message copy referenced by

<Data>

. The message object is locked during data reception. This

service also updates the status information of the message object

accordingly.

In case of

WithoutCopy

– Possible for unqueued message type only –

Returns Status

only since application can access directly to the

message object.

Particularities:

Queued messag es:

1. The service returns the oldest message.

2. In case of a FIFO overflow , at leas t one message was lost, the

oldest message is returned.

3.If the FIFO is empty, no message is returned to the application.

Unqueued messages:

1. The service returns the current message.

2. If no new message has been received since the last call to

ReceiveMessage

the current message is returned.

System Services

Commun ication Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 253

NON-DISCLOSURE AGREEMENT REQUIRED

Status:

• Standard:

WithCopy

–

E_OK

– message available,

–

E_COM_LOCKED

– message object locked,

–

E_COM_NOMSG

– in case of unqueued message, no

message received so far,

–

E_COM_NOMSG

– in case of queued message, no

message avail able (FIF O empty),

–

E_COM_LIMIT

– at l east one message ha s been lost

for a message object.

WithoutCopy

–

E_OK

– successful operation,

–

E_COM_LOCKED

– message object locked.

• Extend ed:

–

E_COM_ID

– invalid paramete r

Conformance: N/A

17.8.4 GetMessageResource

Syntax:

StatusType GetMessageResource ( SymbolicName <Message> )

Input:

•

– symbolic name of the message object.

Output:

• None.

Description:

The service

GetMessageResource

sets the given message object

status (extende d: for other tasks) as busy if it is n ot alread y

so. This call serves to enter critical sections in the code that are assigned

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

254 System Services MOTOROLA

to r ead or write the m essage o bject refer enced b y

. A cr itic al

section (critical sections should be short) must always be left using

ReleaseMessageResource

Particularities:

This service provides message availability information for the application

to ensure message consistency between API communication service

calls in the without copy configuration.

Corresponding calls to

Get-

and

ReleaseMessageResource

should

appear within the same function on the same function level. Before

terminating the task or entering the wait or suspend state the

corresponding service

ReleaseMessageResource

has to be used.

Status:

• Standard:

–

E_OK

– message object is set busy ,

–

E_COM_BUSY

– message object is already busy.

• Extended:

–

E_COM_ID

– invalid parameter

Conformance: N/A

17.8.5 ReleaseMessageResource

Syntax:

StatusType ReleaseMessageResource ( SymbolicName <Message> )

Input:

•

– symbolic name of the message object.

Output:

• None.

System Services

Commun ication Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 255

NON-DISCLOSURE AGREEMENT REQUIRED

Description:

The service

ReleaseMessageResource

sets off the message object

from busy.

ReleaseMessageResource

is the counterpart of

GetMessageResource

and serves to leave critical sections in the code

that are assigned to read or write the message object referenced by

Particularities:

This service allows for message consistency to be ensured by the

application in case without copy configuration.

Corresponding calls to

Get-

and

ReleaseMessageResource

should

appear within the same function on the same function level. Before

terminating the task or entering the wait or suspend state the

corresponding service

ReleaseMessageResource

has to be used

Status:

• Standard:

–

E_OK

– message object unlocked

successfully.

• Extend ed:

–

E_COM_ID

– invalid parameter

Conformance: N/A

17.8.6 GetMessageStatus

Syntax:

StatusType GetMessageStatus ( SymbolicName <Message> )

Input:

•

– symbolic name of the message object

Output:

• None.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

256 System Services MOTOROLA

Description:

The service

GetMessageStatus

returns the current status of the

message object

. If this service call fails, it has to return an

implementation specific error code which can be distinguished from all

other return values.

Particularities:

None.

Status:

• Standard:

–

E_OK

– no error,

–

E_COM_BUSY

– message object is currently in use

by the application,

–

E_COM_LOCKED

– message ob ject locked irrespective

of whether the message object is

currently in use by the application

(busy),

–

E_COM_NOMSG

– in case of unqueued message, no

message received so far,

–

E_COM_NOMSG

– in case of queued message, no

message avail able,

–

E_COM_LIMIT

– at least one message has been lost,

– implementation specific status information or error codes.

• Extended:

–

E_COM_ID

– invalid parameter

Conformance: N/A

17.8.7 Examples of Using Messages

The examples below present the usage of system ser vices for

communication. The Unqueued Message

MsgBAst

has a timestam p

and it is defined as a message of the

MSGTS

type.

The following definitions can be made in the definition file (for HC08):

System Services

Commun ication Managem ent Services

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 257

NON-DISCLOSURE AGREEMENT REQUIRED

...

TASK TASK_A {

TYPE = EXTENDED;

SCHEDULE = FULL;

AUTOSTART = FALSE;

PRIORITY = 3;

StackMethod = POOLSTACK;

StackPool = POOL1;

};

TASK TASK_B {

TYPE = BASIC;

SCHEDULE = FULL;

AUTOSTART = TRUE;

PRIORITY = 2;

EntryPoint = "task_b";

StackMethod = OWNSTACK;

STACKSIZE = 64;

};

TASK TASK_X {

TYPE = BASIC;

SCHEDULE = FULL;

AUTOSTART = TRUE;

PRIORITY = 1;

StackMethod = NODESTACK;

};

COUNTER Post {

MAXALLOWEDVALUE = 24;

TICKSPERBASE = 1;

};

MESSAGE msgAAst {

TYPE = UNQUEUEDMESSAGE;

ITEMTYPE = "int";

ITEMS = 1;

WithCopy = FALSE;

};

MESSAGE msgBAst {

TYPE = UNQUEUEDMESSAGE;

ITEMTYPE = "MSGTS";

ITEMS = 1;

WithCopy = TRUE;

};

MESSAGE msgCBst {

TYPE = UNQUEUEDMESSAGE;

ITEMTYPE = "int";

ITEMS = 1;

WithCopy = TRUE;

};

MESSAGE msgDBev {

TYPE = QUEUEDMESSAGE;

ITEMTYPE = "int";

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

258 System Services MOTOROLA

ITEMS = 6;

ReceiverNum = 3;

};

...

The C-language code can be the following:

DeclareTask( TASK_A )

DeclareTask( TASK_B )

DeclareTask( TASK_X )

OSMSGmsgAAst *_msgAAst = &OSmsgAAst;

OSMSGmsgBAst _msgAAst;

OSMSGmsgCBst _msgCBst;

OSMSGmsgDBev _msgDBev;

DeclareCounter( Post )

typedef struct tagMSGTS MSGTS;

struct tagMSGTS

{

TickType ts;

int x;

};

void Func( void );

{ /* The function uses the Queued Message - receives and processes it */

ReceiveMessage( msgDBev );

...

}

TASK( TASK_A )

{

...

ReceiveMessage( msgCBst, _msgCBst ); /* get the message */

if( msgCBst == 2 ) *_msgAAst = 1;

else *_msgAAst = 33;

SendMessage( msgAAst, _msgAAst );

...

_msgBAst.x = 60;

GetCounterValue( Post, &(_msgBAst.ts) );

SendMessage( msgBAst, _msgBAst );

...

Func();

...

}

TASK( TASK_B )

System Services

Operating System Execution Contr ol

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 259

NON-DISCLOSURE AGREEMENT REQUIRED

{

TickType cur_time;

...

_msgCBst = 15;

SendMessage( msgCBst, _msgCBst );

...

ReceiveMessage( msgAAst, _msgAAst );

if( *_msgAAst == 1 ) ActivateTask( TASK_X );

ReceiveMessage( msgBAst, _msgBAst );

_msgBAst.ts = 60;

GetCounterValue( Post, &cur_time );

if( (cur_time - _msgBAst.ts) > 15 ) SetEvent( TASK_X, 1 );

...

SendMessage( msgEBev, _msgEBev );

...

}

17.9 Operating System Execution Control

17.9.1 Data Types

The OSEK OS establishes the following data type for operation mode

representation:

•

AppModeType

This data type represents the operating

mode.

17.9.2 GetActiveApplicationMode

Syntax:

AppModeType GetActiveApplicationMode( void );

Description:

This service returns the current application mode. It may be used to write

mode dependent code (see Section 11.6 Application Mod es ).

This service is not implemented if the system configuration option

GetActiveApplicationMode

is turned off in the configuration file.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

260 System Services MOTOROLA

Particularities:

Conformance: BCC1 , BCC2, ECC1, ECC2

17.9.3 StartOS

Syntax:

void StartOS( AppModeType <Mode> );

Input:

•

<Mode>

– operati ng mode.

Output:

• None.

Description:

The user can call this system service to start the system in a specific

mode. This service calls user hook

StartupHook

. Each application mode

consists of own set of tasks (see S ecti on 11.6 Appl ication Modes).

Particularities:

See Sec ti o n 11 .5 S tar t- up R out ine and Section 11.6 Application

Modes for general description of system startup.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.9.4 ShutdownOS

Syntax:

void ShutdownOS( StatusType <Error> );

Input:

•

<Error>

– a code of the error occurred.

Output:

• None.

System Services

Operating System Execution Contr ol

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 261

NON-DISCLOSURE AGREEMENT REQUIRED

Description:

The user can call this system service to abort the overall system (e.g.

emerg ency off) . Th e operating syste m also calls this fu nction inte rnally,

if it has reached an undefined state and is no longer ready to run. This

service calls user hook

ShutdownHook

. If

ShutdownHook

returns, the

operat ing system jumps t o the n ext state ment following the initial call to

StartOS

(see Section 11.7 System Shutdo wn).

Particularities:

ShutdownOS

never returns to the location where it was called.

ShutdownOS

is appli cation spe ci fic, sin ce standa rdiz ed er ror treat ment

is not possible.

ShutdownOS

runs in connection wi th the currentl y active conte xt, which

may b e unknown to t he user. Thus, no API fun ctions are admit ted withi n

the

ShutdownOS

routin e.

After the return from

ShutdownOS

service all interrupts will be disabled.

This service is not implemented if the system configuration option

ShutdownOS

is turned off in the configuration file.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.9.5 Examples of Application Modes Usa ge

The exam ple bellow demonstrates di fferent application modes usage.

The following definitions can be made in the definition file (for HC08):

OIL_VERSION = "2.0e"; /* Force SG to use Extended */

/* OIL format */

INCLUDE “mot20.oil”

CPU cpu1 {

CFGACTIVE = { ModeA, ModeB }; /* Two application modes */

/* “ModeA”, “ModeB” are */

/* defined */

....

CFG ModeA { /* Application mode “ModeA” */

TASK TC { /* Common task for both modes */

TYPE = EXTENDED;

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

262 System Services MOTOROLA

SCHEDULE = FULL;

AUTOSTART = TRUE;

StackMethod = OWNSTACK;

STACKSIZE = 60;

PRIORITY = 3;

};

TASK TA1 { /* ModeA specific task TA1 */

TYPE = BASIC;

SCHEDULE = FULL;

AUTOSTART = TRUE;

StackMethod = POOLSTACK;

StackPool = POOL;

PRIORITY = 2;

};

... /* Other ModeA tasks */

};

CFG ModeB { /* Application mode “ModeB” */

TASK TB1 { /* ModeB specific task TB1 */

TYPE = BASIC;

SCHEDULE = FULL;

AUTOSTART = TRUE;

StackMethod = POOLSTACK;

StackPool = POOL;

PRIORITY = 4;

};

TASK TC { /* Common task for both modes */

TYPE = EXTENDED;

SCHEDULE = FULL;

AUTOSTART = TRUE;

StackMethod = OWNSTACK;

STACKSIZE = 60;

PRIORITY = 5;

};

... /* Other ModeB tasks */

};

STACK POOL { /* Stack pool definition */

StackSize = 60;

NumberOfStacks = 3;

}

COUNTER Timer { ... };/* Counter definition */

ALARM TimeLimit { /* Alarm definition */

ACTION = SETEVENT;

COUNTER = Timer;

TASK = TC; /* Activates common task */

EVENT = SHUTDOWN;

}

EVENT SHUTDOWN { MASK = 0x01; };

EVENT STARTTA1 { MASK = 0x02; };

EVENT STARTTB1 { MASK = 0x04; };

....

};

System Services

Operating System Execution Contr ol

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 263

NON-DISCLOSURE AGREEMENT REQUIRED

The C-language code can be the following:

DeclareTask( TA1 ) /* ModeA specific task TA1 */

DeclareTask( TB1 ) /* ModeB specific task TB1 */

DeclareTask( TC ) /* Task TC is shared between both modes */

DeclareCounter( Timer ) /* System timer */

DeclareAlarm( TimeLimit ) /* Alarm to abort the system */

DeclareEvent( SHUTDOWN ) /* TC command: shutdown the system */

DeclareEvent( STARTTA1 ) /* TC command: activate TA1 */

DeclareEvent( STARTTB1 ) /* TC command: activate TB1 */

...

AppModeType NewMode; /* Application mode */

void main( void )

{NewMode = ModeA; /* Set initial application mode */

for( ; ; )

{... /* Perform some actions before startup*/

/* and start OS in specific mode */

StartOS( NewMode );

... /* Perform some actions after system*/

/* shutdown */

}

TASK( TC ) /* TC code is shared between both modes */

{EventMaskType tc_ev; /* Set maximum possible time limit */

SetRelAlarm( TimeLimit, 1000, 0 );

for( ; ; )

{ClearEvent( SHUTDOWN|STARTTA1|STARTTB1 );

WaitEvent( SHUTDOWN|STARTTA1|STARTTB1 );

GetEvent( TC, &tc_ev );

if( ( tc_ev & SHUTDOWN ) != 0 )

{ /* Force system shutdown */

ShutdownOS( E_OK );

}

if( ( tc_ev & STARTTA1 ) != 0 )

{ /* Activate ModeA specific task */

ActivateTask( TA1 );

}

if( ( tc_ev & STARTTB1 ) != 0 )

{ /* Activate ModeB specific task */

ActivateTask( TB1 );

}

}/* USer’s shutdown hook */

void ShutdownHook( StatusType Error )

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

264 System Services MOTOROLA

{/* Check current application mode */

if( GetActiveApplicationMode( ) = ModeA )

NewMode = ModeB; /* Next time the system will start */

/* in application mode ModeB */

else

NewMode = ModeA; /* Next time the system will start */

/* in application mode ModeA */

}

TASK( TA1 ) /* ModeA specific task */

{... /* Activate other ModeA specific tasks */

TerminateTask( ); /* And terminate self */

}

TASK( TB1 ) /* ModeB specific task */

{... /* Activate other ModeB specific tasks */

TerminateTask( ); /* And terminate self */

}

17.9.6 Hook Routines

17.9.6.1 ErrorHook

Syntax:

void ErrorHook( StatusType <Error> );

Input:

•

<Error>

– a code of the error occurred.

Output:

• None.

Description:

This hook is called by the operating system at the end of a system

service which ha s a return value not equal to

E_OK

. It is called before

returning to the call level.

For error parameters to be transferred see

Section 17.9.4 ShutdownOS.

System Services

Operating System Execution Contr ol

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 265

NON-DISCLOSURE AGREEMENT REQUIRED

Particularities:

See Section 11. 3 Hook Routines for general description of hook

routines.

This hook is not implemented if the system configuration option

ErrorHook

is turned off in the configuration file.

Status:

• None.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.9.6.2 PreTaskHook

Syntax:

void PreTaskHook( void );

Input:

• None.

Output:

• None.

Description:

This hook is called before the operating system enters the context of the

task. This hook is called from the scheduler when it passes control to the

given task. It may be used by the application to trace the sequences and

timing of tasks’ execution.

Particularities:

See Section 11. 3 Hook Routines for general description of hook

routines.

This hook is not implemented if the system configuration option

PreTaskHook

is turned off in the configuration file.

Status:

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

266 System Services MOTOROLA

None.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.9.6.3 PostTaskHook

Syntax:

void PostTaskHook( void );

Input:

• None.

Output:

• None.

Description:

This hook is called after the operating system leaves the context of the

task. This hook is called from the scheduler when it switches from the

current task to another. It may be used by the application to trace the

sequences and timing of tasks’ execution.

Particularities:

See Section 11.3 Hook Routines for general description of hook

routines.

This hook is not implemented if the system configuration option

PostTaskHook

is turned off in the configuration file.

Status:

None.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.9.6.4 IdleLoopHook

Syntax:

void IdleLoopHook( void );

System Services

Operating System Execution Contr ol

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Services 267

NON-DISCLOSURE AGREEMENT REQUIRED

Input:

• None.

Output:

• None.

Description:

This hook is called by the operating system from scheduler idle loop. It

is not possible to call OSEK OS directives from this hook. Hardware

dependent code like manipulation with COP registers may be placed

here.

Particularities:

See Section 11.3 Hook Routines for general description of hook

routines.

This hook is not implemented if the system configuration option

IdleLoopHook

is turned off in the configuration file.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.9.6.5 StartupHook

Syntax:

void StartupHook( void );

Input:

• None.

Output:

• None.

Description:

This hook is called by the operating system at the end of the operating

system initialization and befor e the sche duler is running. At this point in

time the application can start tasks, alarms, initialize device drivers etc.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Services

User’s Manual OSEK Opera ting System — Re v 1.2

268 System Services MOTOROLA

Particularities:

See Section 11. 3 Hook Routines for general description of hook

routines.

This hook is not implemented if the system configuration option

StartupHook

is turned off in the configuration file.

Status:

None.

Conformance: BCC1 , BCC2, ECC1, ECC2

17.9.6.6 ShutdownHook

Syntax:

void ShutdownHook( StatusType <Error> );

Input:

•

<Error>

– a code of the error occurred.

Output:

• None.

Description:

This hook is called by the operating system when the service

ShutdownOS

has been called. This routine is called before the operating

system shuts down itself.

Particularities:

See Section 11. 3 Hook Routines for general description of hook

routines . This hook is not implemented if the system con figuration option

ShutdownHook

is turned off in the configuration file.

Status:

None.

Conformance: BCC1 , BCC2, ECC1, ECC2

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTO ROLA ORT I Impleme ntation 269
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Sectio n 1 8. ORTI Implementation
18.1 Contents
18.2 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
18.3 ORTI Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271
18.5 ORTI Gene rator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
18.2 General
The purpose of OSEK Run Time Interface (ORTI) implementation is 
giving the user extended opportunities in debugging embedded OSEK 
applications. The ORTI shall be supported from both sides: an OSEK OS 
and a debugger. The debugger able to display information in terms of 
OSEK  system objects is “ OSEK  aware” de bugger. The inte rnal O S d ata 
is to be made available to the debugger. For this purpose special ORTI 
file  is genera ted at co nfigur ation time  by an ORT I gener ator. A s a resu lt, 
more ser vices will be available to the user during application deb ugging 
ses sio n. 
The ORTI generator (OrtiGen) is the command line utility which uses OIL 
file (App.oil) as input file. The OrtiGen utility generates static information 
in the ORTI format. This utility analyzes the application configuration and 
genera tes ORTI  file. The  same OIL f ile is pr ocessed by the  SysGen a nd 
all f ile s with con figuration da ta for OS  are gen erated. After  applicat ion is 
compiled and linked and executable and map files are created then they 
are l oad ed by the  debugg er. If  the debu gger  i s OSEK  aware th en i t can 
load also the ORTI file for this application. The information from ORTI file 
provide the debugger with possibility to display information about system 
objects of current implementation of OSEK OS. This process is depicted 
on Figure 18-1.

NON-DISCLOSURE AGREEMENT REQUIRED

ORTI Impl ement ati on

User’s Manual OSEK Opera ting System — Re v 1.2

270 ORTI Implementation MO TOROLA

Figure 18-1. Application Building Process with ORTI Support

Programs Data file s

Library

User’s Source File

app.c OIL File

Application

Configuration

Files

ORTI Fil eMAP FileExecutable File

SysGen OrtiGen

Compiler/Linker

OSEK Aware

Debugger

Third-party tools

OSEK Oper a ti n g Sy ste m

components:

ORTI Implementation

ORTI Features

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA ORT I Impleme ntation 271

NON-DISCLOSURE AGREEMENT REQUIRED

18.3 ORTI Features

ORTI provides two kinds o f interfaces to OSEK OS data:

• Trace interface, which means getting an access to the data on a

running target when it is essential to trace data changes in a real

time;

• Breakpoint interface, which provides an access to desirable data

on a stopped target.

Note that ORTI Trace interface is desi gned to provide access to

requested data in accomplished form that is not requiring additional

processing.

18.3.1 ORTI Trace Interfaces

There are two trace ORTI interfaces: running task identification in run-

time and OSE K OS system calls identification in run-time.

The special attributes are generated for the OS object in ORTI file to

support trace interfaces . The re a re RUNNINGTASK and

CURRENTSERVICE attribute s1.

• RUNNINGTASK

This attribute specifies the name of the currently running task

within the OS.

The RUNNINGTASK attribute value presents the address of a

byte which contains either byte numeric identifier of a task which

is currently in the

running

state or the special byt e value in case of

none tasks are in the

running

state. The certain values of task

identifiers are statically determined and enumerated in the type

field of RUNNINGTASK attribute of an OS obje ct as well as the

special value (

NO_TASK

) representing none of tasks running.

1. The se attr ibut es are spe cifi ed in t he document “ORTI : OSEK Run Time Int erface , Versi on 2.0

(Draft a), 18 February 1999”.

NON-DISCLOSURE AGREEMENT REQUIRED

ORTI Impl ement ati on

User’s Manual OSEK Opera ting System — Re v 1.2

272 ORTI Implementation MO TOROLA

The value of the RUNNINGTASK attribute is updated each time

CPU switches to another task or to the code corresponding to

none of task running.

• CURRENTSERVICE

This attri bute sp ecifies w hich o pera ting ser vi ce, if an y i s curr ently

being executed.

The CURRENTSERVICE attribute value presents the address of

a byte which rep resents a service numeri c identif ier. Thi s value is

updated with OSEK OS service (

Service

) identifier on the

following events occurred:

– CPU enter s

Service

code;

– CPU resum es executi on of

Service

code aft er switching to the

task preempted (this also could take place in case of unacted

task preemption, when system scheduler tried to switch to

another task but found no appropriate task to switch to and

resumed

Service

code execution in a frame of the current

task);

– CPU resumes execution of

Service

code after leaving nested

OSEK OS service call (mainly for hook services).

In case of leaving OSEK OS service the byte accepts the special

value (

NO_SERVICE

) corresponding to none of OSEK OS service

being currently executed.

The byte is updated with this value on

the following events occurred:

– CPU l eaves OSEK OS se rvice code and st arts to execute non

OSEK OS service code;

– CPU preempts execution of OSEK OS service code to perform

task switching.

NOTE:

Typically trace sequence of CURRENTSERVICE looks like the

following:

Traced Value Description

...

SERVICE_1_ID entering or resuming Service 1

NO_SERVICE leaving Service 1 (possibly due to task switching

)

ORTI Implementation

ORTI Features

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA ORT I Impleme ntation 273

NON-DISCLOSURE AGREEMENT REQUIRED

18.3.2 O RTI Breakpoint Interf ace

There is one Breakpoint ORTI interface intended to facilitate debugger

access to task related data.

The following static (at breakpoints) ORTI services are supported:

• access to tasks information for a debugger on br eakpoints;

• access to stacks information for a debugger on br eakpoints.

Inform ati on need ed to d ispl ay th e cu rre nt ta sk stat us is avai lable for th e

debugger whenever th e de bugger is stopped (i.e. th is infor mation i s n ot

required in real-time and hence can be read from the TCB or similar

structure).

...

SERVICE_2_ID entering or resuming Service 2

SERVICE_2_ID resuming Se rvice 2 execution after unacted task

preemption (could be ignored)

NO_SERVICE leaving Service 2 (possibly due to task switching

)

...

SERVICE_3_ID entering or resuming Service 3

SERVICE_4_ID entering nested Service 4 call (possibly hook

routine)

SERVICE_3_ID leaving Service 4 and resuming Service 3

NO_SERVICE leaving Service 3 (possibly due to task switching

)

...

SERVICE_5_ID entering or resuming Service 5

SERVICE_6_ID entering nested Service 6 call (possibly hook

routine)

NO_SERVICE leaving Service 5 and Service 6 (possibl y due to

task switching

)

...

Traced Value Description

NON-DISCLOSURE AGREEMENT REQUIRED

ORTI Impl ement ati on

User’s Manual OSEK Opera ting System — Re v 1.2

274 ORTI Implementation MO TOROLA

The following task information is available to the user:

•priority,

• current stack.

Information in the ORTI file allows a debugger to display task information

using values that the user sets in the OIL file.

The task pr io rity value is provid ed wit h taking into account possi ble task

priority changes due to a dynamic resource allocation.

The task state indicates a standard OSEK state the task is currently in.

Information needed to display stacks allocated in the system is available

for the debugger whenever the debugger is stopped. All memory areas

defined as stack in the application are presented via:

•size,

• start address.

NOTE:

To provide system with information about application main stack area

make sur e 2 variab les are defined in Cosm ic link command file: __ stack

(required for Cosmic start-up code) and __stackstart (should be

allocated at the lowest address byte of application main stack area). In

this case Cosmic link command file may look like the following:

...

+seg .bss -a data # BSS starts after .data

+def __stackstart=@.bss # pointer to stack start value

+spc .bss=0x3F # reserve 0x3f bytes for stack in BSS

+def __stack=@.bss # stack pointer value

...

18.4 ORTI Supp orting OS Properties

To contr ol ORTI support some addi tional attributes sh ould be de fined in

the configuration file (OIL file). The following attributes are specified for

an object of the

type:

ORTI Implementation

ORTI Generator

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA ORT I Impleme ntation 275

NON-DISCLOSURE AGREEMENT REQUIRED

• DEBUG_LEVEL (ENUM)

Specifies the ORTI support in OS. The attribute can have values

0 or 1. If the system has the DEBUG_LEVEL = 0 the static ORTI

support is switched off. If the system has the DEBUG_LE VEL = 1

this mode is considered to be a debugging mode.

• ORTIR unnin gTask (BOOLE AN)

Specifies that the running task identi fication in run-time support

will be used. This attribute will be ignored if DEBUG_LEVEL = 0.

• ORTICurrentService (BOOLEAN)

Specifie s that the OSEK OS system calls identificat ion in ru n-time

support will be used. This attribute will be ignored if

DEBUG_LEVEL = 0.

All attributes of the OS object are described in Section 13.3 OS

Definition.

18.5 ORTI Generator

The ORTI generator utility is a command line utility which has the OIL file

as input and ORTI file as result of wor k. The ORTI generation utility is

intended to prepare all data needed for OSEK aware debugger to

display information about application in OSEK terms.

The OrtiGen utility has the following format of command line:

ortigen [-options] filename

All opti ons are case se nsitive. The space be tween op tion and argum ent

is optional.

NON-DISCLOSURE AGREEMENT REQUIRED

ORTI Impl ement ati on

User’s Manual OSEK Opera ting System — Re v 1.2

276 ORTI Implementation MO TOROLA

The following options are accepted by the OrtiGen:

The location of the ORTI template file can be pointed either in command

line or via the ORTI_TEMPLATE environment variable.

In addition to command line op tion the OSB_INCLUDE_DIR

environment variable can be used to specify the set of directories.

If the ORTI generator finds an error in the source files, it either halts

processing or outputs a warning message depending on the error

severity. If there are no error, the OrtiGen returns 0, if there are mild

errors the OrtiGen sends warning messages and returns 0, but does not

terminate processing, if severe errors are detected – the OrtiGen returns

2 and does not produce output file.

The ORTI generator performs the same verification as the SysGen does

and has the same format of er ror m essages. Al l System G ener ator error

and warning messages and their formats are described in

Appendix D System Generation Error Messages.

If the D EBUG_L EVE L attrib ute of th e OS obj ect is set to 0 o r unde fined

in the OIL file then the ORTI file is not produced and the following

warning is generated:

W0010: DEBUG_LEVEL is undefined, ORTI file is not generated

If the DEBUG_LEVEL attribute is undefined in the implementation

definition then the following warning is generated:

Table 18-1. ORTI Generator C ommand Line Options

Option Description

-c The argum ent of this opt ion defines file nam e for o utpu t ORTI file. By

default the input file name with extension

.ort

is used

-i

This option adds a directory to th e list of directories searched for include

files. To search more than one directory, give additional -i options on the

comm and line – one -i opti on for each directory. Directories are searched

only until the specified include file is found

-n The argument of t his option defines CPU name for which the ORTI fil e will

be written. By default the first CPU in the file is used

-t The argument of this option defines the name of template file f or the ORTI

file generation

ORTI Implementation

ORTI Generator

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTO ROLA ORT I Impleme ntation 277

NON-DISCLOSURE AGREEMENT REQUIRED

W0011: DEBUG_LEVEL is not define d in implementation

NON-DISCLOSURE AGREEMENT REQUIRED

ORTI Impl ement ati on

User’s Manual OSEK Opera ting System — Re v 1.2

278 ORTI Implementation MO TOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Sample Application 279

NON-DISCLOSURE AGREEMENT REQUIRED

User’s Manual — OSEK Operating System

Append ix A. Sample Applic atio n

A.1 Contents

A.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279

A.3 Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280

A.2 Description

The Sample application deli vered with the OSEK Operating System

should help to learn how to use OSEK OS. The Sample’s source files are

located in the SAMPLE directory - it contains all files needed to create

an executable file.

The Sample is not a real application and it does not perform any useful

work. But it has a certain algorithm so it is possible to track the execution.

It uses most of OSEK OS mechanisms and allows the user to have the

first look inside the OSEK OS.

The Sample consists of four tasks. It uses two counters (o ne of them is

the standard OSEK OS timer), three alarms, one resource, one

unqueued and one queued message. Timer interr upt is handled by the

ISR.

Generally, Sample tasks are divided into two pairs.

TASKSND

and

TASKRCV

compose the first pair and

TASKPROD

TASKCONS

are the

second pair. This two pairs interacts with the help of the event

mechanism.

The task

TASKSND

is activated by the

StartOS

routine. It gets the

resource to provide exclusive access to the unqueued message

MsgA

modi fies the messag e and se nds it to

TASKRCV

. After that th e resou rce

is released and the task terminates itself.

MsgA

consists of two parts (it

has the user defined type) and only one part (‘value’ is changed by

NON-DISCLOSURE AGREEMENT REQUIRED

Sample Applicat ion

User’s Manual OSEK Opera ting System — Re v 1.2

280 Sample Application MOTOROLA

TASKSND

). The message is used without copying. Arrival of the

message activates the task

TASKRCV

receives the message

MsgA

and analyze s it. If the ‘

value

’ is

greater than the certain limit, the second part of

MsgA

is increased and

the event is set for the task

TASKPROD

(producer). In the end the task

releases the resource and terminates itself.

The task

TASKPROD

is activated by the

StartOS

routine. Just after the

act ivation the task activate s the system counte r (time r) and the counter

for messages and sets two alarms. To prevent rescheduling at this

moment the scheduler is got by the tasks as a standard resource. One

alarm is the relative cyclic alarm ba sed on the system timer, it will be

used to “awake” the task, and the second alarm is the absolute alarm

based on the message counter. The message counter is intended to

count the number of items in the queued message

MsgB

. After all

initialization activities

TASKPROD

calls the

WaitEvent

service and, thus,

the task delays itself.

When

TASKPROD

becomes

running

again, it sends the queued message

MsgB

. The message contents depends on the event which has caused

task awakening. After sending

MsgB

the message counter is triggered.

The task

TASKCONS

(consumer) has the lowest priority. This is

preemptive task.

TASKCONS

is activated by the alarm when the message

counter reaches the predefined number. The task reads (consumes)

queued message

MsgB

items and ana lyzes th em. In case of the “

S_OK

”

message the message timestamp is saved in the variable “

normal

”. In

case of the “

S_LIMIT

” messag e the period of time elapsed between the

“

S_OK

” and “

S_LIMIT

” messages is saved in the var iable “

period

”.

The user can watch the “

normal

” and “

period

” variables, the message

contents and so on.

A.3 Source Files

Source files for the Sample application are the following:

• “sample.c” – the application code,

Sample Application

Source Files

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Sample Application 281

NON-DISCLOSURE AGREEMENT REQUIRED

• “cfg20.oil” – OSEK Implementation Language file (Version 2.0),

• “makefile” – command files to build the executable file,

• “vector.c”– Vector table,

• “crts.s” – Start-up module for Cosmic

• “make. bat“ – E nviron ment Confi gu ration file for OS EK OS ( buil ds

executable file)

To build the executable file the user should make sure that OSEK OS

compon ents a re p rope rly i nsta lled on the di sk and path es for the OSEK

directory and compiler software are known. The makefile was written for

Microsoft Visual C++ 4.2 NMAKE utility. Run the MAKE.BAT to build the

executable file. To build sample application for Cosmic compiler run

MAKE.BAT with 'c' variable set to 'cosmic12':

>MAKE "c =cosmic12"

To build sample application for M68HC12B32EVB run MAKE.BAT with

'type' variable set to 'B32':

>MAKE "type=B32"

To build sample application for M68HC12D60EVB user should run

MAKE.BAT with 'type' variable set to 'D60':

>MAKE "type= D60"

To clean all produ ced files in the OSEK\SAMPLE direc tory user shoul d

run MAKE.BAT and set clean target:

>MAKE cl ean

(See the file "makefile" in the OSEK\SAMPLE directory for additional

information)

Makefile uses the system environment variables CXPATH, CXLIB and

OSEKDIR to get Cosmic and OSEK components.

When all produced filed are ready, the executable file can be load into

the Evaluation board (HC12D60EVB for example) and run.

NON-DISCLOSURE AGREEMENT REQUIRED

Sample Applicat ion

User’s Manual OSEK Opera ting System — Re v 1.2

282 Sample Application MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Service Timing 283

NON-DISCLOSURE AGREEMENT REQUIRED

User’s Manual — OSEK Operating System

Appendix B. System Service Timing

B.1 Contents

B.2 General Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283

B.2 General No tes

The following notation is used to define four main states for run-time

services:

• Immediate Response (IR) – The service completes immediately

without any tasking changes.

• Stop Task (ST) – The service transfers the task from the

running

state into another state (

ready

waiting

suspended

). Task

switching will take place.

• Task Wai ting (T W) – The servic e called tr ansfe r an other task into

the

ready

state (from

waiting

suspended

states). This task has

the same or lower priority than the task calling the service, or

preemption is disabled, therefore task switching will not take

place.

• Task Waiting and Context Switch ing (TWCS) – The service called

transfer another task into th e

running

state (from

ready

waiting

suspended

states). This task has the higher priority than the

calling task, therefore task switching is performed.

Results in Table B-1 and Table B-2 below was got on the basis of the

certain OS configu ration . The list of systetm pr oper ties is shown below,

and this configuration is called in the table as “Initial”. Properties that are

not listed have their default values. In the column “Condition” the

differences from the given list (“Initial“) are indicated. For each

configuration the corresponded numbers are provided in the table.

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Service Timing

User’s Manual OSEK Opera ting System — Re v 1.2

284 System Service Timing MOTOROLA

OIL_VERSION = "2.0";

#include "mot20.oil"

CPU cpu1 {

OS os1 {

OSVERSION = 2;

TargetMCU = HC12;

CC = BCC2;

EntryExitISR = TRUE;

InterruptMaskControl = TRUE;

SCHEDULE = FULL;

TaskIndexMethod = FALSE;

StackPool = FALSE;

TaskOwnStack = TRUE;

PersistentNode = TRUE;

PersistentStack = FALSE;

STATUS = EXTENDED;

ErrorHook = TRUE;

StartupHook = TRUE;

ShutdownHook = TRUE;

PreTaskHook = FALSE;

PostTaskHook = FALSE;

InternalErrorHandler = TRUE;

Resources = FALSE;

FastResource = FALSE;

Events = FALSE;

Counters = TRUE;

CounterSize = 32;

Alarms = TRUE;

AlarmList = TRUE;

UnqueuedMessages = TRUE;

UnqueuedMsgDefaultValue = TRUE;

QueuedMessages = FALSE;

QueuedMsgOneToN = FALSE;

ActivateOnMsg = FALSE;

AlarmOnMsg = FALSE;

SetEventOnMsg = FALSE;

DisableInterruptMask = 0x50;

EnableInterruptMask = 0x40;

TaskLevelMask = 0x40;

IsrStackSize = 255;

NodeNumber = 5;

MaxPrio = 5;

SchedStackSize = 255;

NodeStackSize = 255;

NodeStack = FALSE;

MultiplyActivation = TRUE;

};

Sys te m Ser vice Tim ing

General Notes

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Service Timing 285

NON-DISCLOSURE AGREEMENT REQUIRED

All numbers in the table are the number of CPU cycl es counted by

readi ng the fr ee running counter. T herefore, to calculate these numb ers

in microseconds, these numbers must be multiplied by the period of

CPU clock. For instance, for HC12D60 with 16Mhz oscillator, CPU clock

frequency equals 8Mhz and the CPU clock period equals 0.125

microseconds the duration of

GetResource

service (for “Initial” system

confi guration) is 34 .125 microseco nds (273 * 0.125* 10-6 = 34 .125* 10-6).

It is possible that some real numbers can slightly differ from the

presented values due to some last changes in OSEK OS.

Table B-1. OSEKOS_20 version of the Operating System run-time services timing

characteristics (HC12D60, Cosmic software)(1)

Conditions IR ST TW TWCS

ActivateTask

BCC1, NONPREEMPT, STATUS=STANDARD,

Counters=FALSE, Alarms=FALSE,

UnqueuedMessages=FALS E,

QueuedMessages=FALSE, no hook routines, no

interrupts

--301-

NONPREEMPT - - 546 -

Initial - - 601 692

TerminateTask

BCC1, NONPREEMPT, STATUS=STANDARD,

Counters=FALSE, Alarms=FALSE,

UnqueuedMessages=FALS E,

QueuedMessages=FALSE, no hook routines, no

interrupts

-240--

NONPREEMPT - 455 - -

Initial - 447 - -

ChainTask

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Service Timing

User’s Manual OSEK Opera ting System — Re v 1.2

286 System Service Timing MOTOROLA

BCC1, NONPREEMPT, STATUS=STANDARD,

Counters=FALSE, Alarms=FALSE,

UnqueuedMessages=FALS E,

QueuedMessages=FALSE, no hook routines, no

interrupts

- - - 441

NONPREEMPT - - - 845

Initial - - - 821

Schedule

BCC1, NONPREEMPT, STATUS=STANDARD,

Counters=FALSE, Alarms=FALSE,

UnqueuedMessages=FALS E,

QueuedMessages=FALSE

67 - - 115

NONPREEMPT 123 - - 266

Initial 123 - - -

GetTaskId

Initial 48 - - -

GetTaskState

Initial: ru nning tas k

ready task

sus pended task

226

266 ---

EnterISR

Resources=TRUE, FastResource=TRUE 53 - - -

LeaveISR

Resources=TRUE, FastResource=TRUE 114 - - -

EnableInterrupt

Resources=TRUE, FastResource=TRUE 33 - - -

DisableInterrupt

Resources=TRUE, FastResource=TRUE 32 - - -

GetInterruptMask

Resources=TRUE, FastResource=TRUE 26 - - -

GetResource

Resources=TRUE, FastResource=TRUE 97 - - -

ReleaseResource

Resources=TRUE, FastResource=TRUE 151 - - 353

Table B-1. OSEKOS_20 version of the Operating System run-time services timing

characteristics (HC12D60, Cosmic software)(1)

Conditions IR ST TW TWCS

Sys te m Ser vice Tim ing

General Notes

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Service Timing 287

NON-DISCLOSURE AGREEMENT REQUIRED

SetEvent

ECC1, NONPRE EMPT 102 - 144 -

ECC1 102 - 180 280

ClearEvent

ECC1, NONPRE EMPT 29 - - -

ECC1 29 - - -

GetEvent

ECC1, NONPRE EMPT 98 - - -

ECC1 98 - - -

WaitEvent

ECC1, NONPRE EMPT 38 169 - -

ECC1 38 187 - -

SendMessage(2)

BCC1, an unqueued message with copy 107 - - -

ReceiveMessage(2)

BCC1, an unqueued message with copy 111 - - -

SendMessage(3)

BCC1, queued m essa ge, 1 receiver 209 - - -

ReceiveMessage(3)

BCC1, queued m essa ge, 1 receiver 250 - - -

InitCounter

Resources=TRUE, FastResource=TRUE 128 - - -

CounterTrigger(4)

Resources=TRUE, FastResource=TRUE 151 - 741 869

GetCounterValue

Resources=TRUE, FastResource=TRUE 107 - - -

GetCounterInfo

Resources=TRUE, FastResource=TRUE 82 - - -

SetRelAlarm(4)

Resources=TRUE, FastResource=TRUE 188 - 682 808

SetAbsAlarm(4)

Table B-1. OSEKOS_20 version of the Operating System run-time services timing

characteristics (HC12D60, Cosmic software)(1)

Conditions IR ST TW TWCS

NON-DISCLOSURE AGREEMENT REQUIRED

Syst em Service Timing

User’s Manual OSEK Opera ting System — Re v 1.2

288 System Service Timing MOTOROLA

1. In all configu rations number of ta sk objects is 5.

2. In this config uration number of message objects is 7.

3. In this config uration number of message objects is 8.

4. In this config uration number of al arm objects is 1.

Resources=TRUE, FastResource=TRUE 220 - 714 840

CancelAlarm(4)

Resources=TRUE, FastResource=TRUE 100 - - -

GetAlarm(4)

Resources=TRUE, FastResource=TRUE 100 - - -

Table B-1. OSEKOS_20 version of the Operating System run-time services timing

characteristics (HC12D60, Cosmic software)(1)

Conditions IR ST TW TWCS

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Memory Requirements 289

NON-DISCLOSURE AGREEMENT REQUIRED

User’s Manual — OSEK Operating System

Appendix C. M emor y Require ments

C.1 Contents

C.2 Memory for the OSEK Operating System. . . . . . . . . . . . . . . .289

C.3 Data Sheet for the Cosmic . . . . . . . . . . . . . . . . . . . . . . . . . . .292

C.2 Memory for the OSEK Operating System

The ta bl e be low contain s the data about R OM an d RA M ne eded for t he

OSEK Operating System kernel and system objects. The amount of

memory depends on the system configuration and on the number of

certain objects (e.g., tasks, counters, etc.). The table does not reflects all

possible configurations so the over all number of them is too big (more

than 2000). Therefore, only some most important configurations are

presented.

The following initial system property settings were used to determine

memory requirements:

OSVERSION = 2;

TargetMCU = HC12;

HCBankCode = FALSE;

HCBasePage = TRUE;

HCLowPower = FALSE;

CC = BCC1;

EntryExitISR = FALSE;

InterruptMaskControl = FALSE;

SCHEDULE = FULL;

SimpleScheduler = TRUE;

UseMainStack = FALSE;

UseSameContext = TRUE;

MultiplyActivation = FALSE;

TaskIndexMethod = FALSE;

TaskBasePage = TRUE;

NodeStack = FALSE;

StackPool = FALSE;

TaskOwnStack = TRUE;

NON-DISCLOSURE AGREEMENT REQUIRED

Memory Requirements

User’s Manual OSEK Opera ting System — Re v 1.2

290 Memory Requirements MOTOROLA

PersistentNode = FALSE;

PersistentStack = FALSE;

STATUS = STANDARD;

HookRoutines = FALSE;

ErrorHook = FALSE;

StartupHook = TRUE;

ShutdownHook = TRUE;

PreTaskHook = FALSE;

PostTaskHook = FALSE;

InternalErrorHandler = FALSE;

Resources = FALSE;

FastResource = FALSE;

Events = FALSE;

Counters = FALSE;

CounterSize = 8;

Alarms = FALSE;

AlarmList = FALSE;

UnqueuedMessages = FALSE;

UnqueuedMsgDefaultValue = FALSE;

QueuedMessages = FALSE;

QueuedMsgOneToN = FALSE;

ActivateOnMsg = FALSE;

AlarmOnMsg = FALSE;

SetEventOnMsg = FALSE;

This initial property l ist was use d for the fi rst row in the ta ble. It con forms

to the BCC1 Conformance Class without any additional mechanisms

and thi s is the minimal OS EK OS configuration. The row s below reflects

memory requirements for the next Conformance Cl asses. System

properties are shown in the rows which are turned on for the

corresponded Conformance Class. For BCC2, ECC1, ECC2 the

scheduler policy is full-preemptive one.

All other rows below the first one (“Initial”) has a title “Initial” or

“Changed:” and one or more options turned ON or OFF. If a row has a

title “Initial” it means that for such OS configuration the Initial property list

is used with particular options changed as shown. If a row has a title

“Changed:” i t means t hat for such OS conf ig uration the setting list as for

the previous row is used with particular options changed as shown.

Thus, the system functionality grows up.

Und er the title “E xtension s” the additi o ns are shown for each additiona l

system pr operty ( or group of th em). Th ese numbe rs are go t on the b ase

of ECC2 configu ration. For exa mple, the r ow “ Counter s = ON ” prese nts

the additional memory requirements for this mechanism. It allows the

Memory Requirements

Memory for the OSEK Operating System

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Memory Requirements 291

NON-DISCLOSURE AGREEMENT REQUIRED

user to evaluate the amount of memory needed to support some

particular mechanisms and features. Differences between the amount of

memory required to support these features for various Conformance

Classes are comparatively small. Therefore, the data is provided only for

ECC2. Thus, since each next row includes all functionality of the

previous ones, the last row presents the memory requirements for the

system with full functionality.

Since ea ch system object (a task, a message, an alarm, etc.) requires

some ROM and RAM the total amount of memory depends on the

number of objects. Therefore, the formulas should be used to calculate

the exact memory amount for each case. These formulas are provided

in the table.

NOTE:

In the formulas in the table the following symbols are used:

•T

sis the number of tasks i n non-suspended state;

•T

tis the total number of tasks;

• C is the number of counters;

• A is the number of alarms;

• S is the number of unqueued messages;

• E is the number of queued messages;

• P is the number of tasks’ pr iorities;

• R is the number of resources;

•S

pis the number of stack pools;

•S

bis the number of stack buffers.

It is possible that some real numbers can slightly differ from the

presented values due to some last changes in OSEK OS.

NON-DISCLOSURE AGREEMENT REQUIRED

Memory Requirements

User’s Manual OSEK Opera ting System — Re v 1.2

292 Memory Requirements MOTOROLA

C.3 Data Sheet for the Cos mic

Table C-1. OSEKOS_20 version of the Operating System memory requirements

Number System P rop erties

(configuration)

Confor-

mance

Class ROM RAM Base Page

RAM

0Initial

BCC1

- 840+7*Tt 23+7*Ts

1Initial

SCHEDULE = NON - 825+7*Tt 23+9*Ts

2Initial

SCHEDULE = MIXED - 840+7*Tt 23+7*Ts

3Initial

SCHEDULE = MIXED

UseSam eContext = FAL SE - 894+7*Tt 23+9*Ts

4Changed:

HCBasePage = FALSE

TaskBasePage = FALSE 23+7*Ts 890+7*Tt -

5Changed:

STATUS = EXTENDED 21+7*Ts 1001+10*Tt -

6Changed:

ErrorHook = TRUE 21+7*Ts 1001+10*Tt -

Changed:

STATUS = STANDARD

Error Hook = FALSE

EntryExitISR = TRUE

25+7*Ts 1056+7*Tt -

8Changed:

Interrupt MaskControl = TRUE 27+7*Ts 1165+8*Tt -

081 Changed:

Reconfig = TRUE 27+7*Ts 1191+10*Tt -

9Initial

SimpleScheduler = FALSE

BCC2

- 936+7*Tt 29+10*Ts+4*P

10 Changed:

HCBasePage = FALSE

TaskBasePage = FALSE 29+10*Ts+4*P 991+7*Tt -

11 Initial

SimpleScheduler = FALSE

MultiplyActivation = TRUE - 1266+11*Tt 31+10*Ts+4*P

12 Changed:

HCBasePage = FALSE

TaskBasePage = FALSE 31+10*Ts+4*P 1330+11*Tt -

13 Changed:

STATUS = EXTENDED 29+10*Ts+4*P 1456+14*Tt -

14 Changed:

ErrorHook = TRUE 29+10*Ts+4*P 1541+14*Tt -

Memory Requirements

Data Sheet for the Cosmic

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Memory Requirements 293

NON-DISCLOSURE AGREEMENT REQUIRED

15 Initial

SimpleScheduler = FALSE

Events = TRUE

ECC1

- 1075+7*Tt 29+12*Ts+4*P

16 Changed:

HCBasePage = FALSE

TaskBasePage = FALSE 29+12*Ts+4*P 1135+7*Tt -

17 Changed:

STATUS = EXTENDED 27+12*Ts+4*P 1336+10*Tt -

18 Changed:

ErrorHook = TRUE 27+12*Ts+4*P 1502+10*Tt -

Changed:

STATUS = STANDARD

Error Hook = FALSE

EntryExitISR = TRUE

31+12*Ts+4*P 1349+7*Tt -

20 Changed:

Interrupt MaskControl = TRUE 33+12*Ts+4*P 1494+8*Tt -

Initial

SimpleScheduler = FALSE

MultiplyActivation = TRUE

Events = TRUE

ECC2 - 1407+11*Tt 31+12*Ts+4*P

Table C-1. OSEKOS_20 version of the Operating System memory requirements

Number System P rop erties

(configuration)

Confor-

mance

Class ROM RAM Base Page

RAM

NON-DISCLOSURE AGREEMENT REQUIRED

Memory Requirements

User’s Manual OSEK Opera ting System — Re v 1.2

294 Memory Requirements MOTOROLA

Extens ions (based on the configuration for ECC2)

22 Changed:

Resources = TRUE

ECC2

2*R 1562+11*Tt+3

*R 31+14*Ts+4*P

23 Changed:

FastResource = TRUE - 1546+11*Tt 33+12*Ts+4*P

24 Changed:

Counters = TRUE 1*C 1666+11*Tt+4

*C 33+12*Ts+4*P

25 Changed:

Coun te rSiz e = 16 2*C 1674+11*Tt+6

*C 33+12*Ts+4*P

26 Changed:

Coun te rSiz e = 32 4*C 1716+11*Tt+1

0*C 33+12*Ts+4*P

27 Changed:

Alarms = TRUE

CounterSize = 8 3*C+8*A 2108+11*Tt+6

*C+7*A 33+12*Ts+4*P

28 Changed:

Alar m Lis t = TRUE 3*C+11*A 2115+11*Tt+4

*C+7*A 33+12*Ts+4*P

29 Changed:

UnqueuedMessages = TRUE 3*C+11*A+3*

S2445+11*Tt+4

*C+7*A+5*S 33+12*Ts+4*P

30 Changed:

UnqueuedMs gDefaul tVal ue = TRUE 3*C+11*A+3*

S2478+11*Tt+4

*C+7*A+7*S 33+12*Ts+4*P

31 Changed:

Que uedMessages = TRUE 3*C+11*A+3*

S+39*E

2711+11*Tt+4

*C+7*A+7*S+

11*E 33+12*Ts+4*P

32 Changed:

QueuedMsgOneToN = TRUE 3*C+11*A+3*

S+39*E

2830+11*Tt+4

*C+7*A+7*S+

15*E 33+12*Ts+4*P

33 Changed:

Acti vateOnMsg = TRUE 3*C+11*A+3*

S+39*E

2891+11*Tt+4

*C+7*A+10*S

+18*E 33+12*Ts+4*P

34 Changed:

SetEventOnMsg = TRUE 3*C+11*A+3*

S+39*E

2907+11*Tt+4

*C+7*A+10*S

+18*E 33+12*Ts+4*P

35 Changed:

AlarmOnMsg = TRUE 3*C+11*A+3*

S+39*E

3052+11*Tt+4

*C+7*A+13*S

+21*E 33+12*Ts+4*P

36 Changed:

StackPool = TRUE 4*Sp+3*C+11*

A+3*S+43*E

3218+11*Tt+1

0*Sp+4*C+7*

A+13*S+21*E 33+14*Ts+4*P

Table C-1. OSEKOS_20 version of the Operating System memory requirements

Number System P rop erties

(configuration)

Confor-

mance

Class ROM RAM Base Page

RAM

Memory Requirements

Data Sheet for the Cosmic

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA Memory Requirements 295

NON-DISCLOSURE AGREEMENT REQUIRED

37 Changed:

NodeStack = TRUE

ECC2

4*Sp+3*C+11*

A+3*S+47*E

3265+11*Tt+1

0*Sp+4*C+7*

A+13*S+21*E 33+16*Ts+4*P

38 Changed:

Persi st entNode = TRUE 4*Sp+3*C+11*

A+3*S+47*E

3348+13*Tt+1

0*Sp+4*C+7*

A+13*S+21*E 33+16*Ts+4*P

39 Changed:

Persi stentStack = TRUE 4*Sp+3*C+11*

A+3*S+47*E

3390+13*Tt+1

0*Sp+4*C+7*

A+13*S+21*E 33+16*Ts+4*P

40 Changed:

HCBasePage = FALSE

TaskBasePage = FALSE

33+16*Ts+4*P

+4*Sp+3*C+1

1*A+3*S+47*

3430+13*Tt+1

0*Sp+4*C+7*

A+13*S+21*E -

41 Changed:

STATUS = EXTENDED

31+16*Ts+4*P

+4*Sp+3*C+1

3*A+5*S+47*

4058+16*Tt+1

0*Sp+7*C+7*

A+13*S+21*E -

42 Changed:

ErrorHook = TRUE

31+16*Ts+4*P

+4*Sp+3*C+1

3*A+5*S+47*

4431+16*Tt+1

0*Sp+7*C+7*

A+13*S+21*E -

43 Changed:

EntryExitISR = TRUE

33+16*Ts+4*P

+4*Sp+3*C+1

3*A+5*S+49*

5125+16*Tt+1

0*Sp+7*C+7*

A+13*S+21*E -

44 Changed:

Interrupt MaskControl = TRUE

35+16*Ts+4*P

+4*Sp+3*C+1

3*A+5*S+51*

5349+17*Tt+1

0*Sp+7*C+7*

A+13*S+21*E -

Table C-1. OSEKOS_20 version of the Operating System memory requirements

Number System P rop erties

(configuration)

Confor-

mance

Class ROM RAM Base Page

RAM

NON-DISCLOSURE AGREEMENT REQUIRED

Memory Requirements

User’s Manual OSEK Opera ting System — Re v 1.2

296 Memory Requirements MOTOROLA

OSEK Op erati ng System — Rev 1.2 User’s Manual
MOTOROLA System Generat ion Error Messages 297
 NON-DISCLOSURE AGREEMENT REQUIRED
 
 
 
User’s Manual — OSEK Operating System
Appendix D. System Ge ner atio n Err or Messages
D.1 Contents
D.2 Error Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
D.3 Error Messages  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
D.4 Warning Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
D.2 Error Message Format
The System Generator checks the compatibility of properties, 
parameters and limits and reports about possible errors via error 
messages. The error messages are divided into errors and warnings. By 
convention messages are divided into subgroups according to related 
objects. The error code is presented by the following string 
LNN##
:
L
 is equal to “E” for error and” W” for warning,
NN
 presents the group number,
##
 presents the error number inside the group.
An error message includes the file name, the line number, the error code 
and a  short error (or warning) description. The error message has  one of 
the following formats:
<filename>(<line number>) : error ENN ## : <message>
<file name>(<line number>) : warning WNN## : <message>
Below all System Generator error and warning messages are described.
D.3 Error Messages
E0001: syntax error

NON-DISCLOSURE AGREEMENT REQUIRED

System Generation Error Messag es

User’s Manual OSEK Opera ting System — Re v 1.2

298 System Generat ion Error Messages MO TORO LA

A syntax error was found in the inpu t stream. Problems of this type can

sometime s be attri buted to a syntactical or clerical er ror. For examp le:

TASK taskA

{

PRIORITY = 5 // No closing semicolon

SCHEDULE = FULL;

};

In the preceding example, the error message will be generated for the

line which contains the definition of SCHEDULE attr ibute, although the

true source of the error appears on the line just above. As a general rule,

make sure to also examine the lines above the line listed in the error

message when trying to determine the cause.

E0002: invalid token ’<token>’

An invalid (unrecognizable) token was found in the input stream.

E0003: unexpected end of file found in comment

The system generato r found the en d of a file while sc anning a comment.

A comment cannot be split across source files.

Thi s e rro r ca n also be cause d b y a comm ent on the last l ine of a source

file that is not followe d by the ‘CR’ symbol as in the example:

int i; // error: last line not terminated by newline

To eliminate this error, go to the end of the line and add a new line.

E0004: Unexpected EOF

The syste m generator reached the end of a source file without re solving

a construct.

For instance, a object definition may be missing a closing curly brace.

E0005: End of line in STRING

A string constant was continued on a second line without a backslash (\)

or the closing double-quote missed.

To bre ak a str ing consta nt that is o n two lines i n the sour ce fi le, en d the

first line with the line-continuation character, a backslash.

System Generation Er ror Messages

Error Mess ages

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Generat ion Error Messages 299

NON-DISCLOSURE AGREEMENT REQUIRED

E0011: cannot open source file: <name>

cannot open include file: <name>

ca nn ot ope n out put fil e: <na me>

This file either did not exist, could not be opened, or was not found.

There are three possible reasons of that:

– This error can occur if the fi le, subdirectory, o r disk on which it resides

is read-only. In this case, make the file writable or move the file to a

wri table disk.

– Trying to open a file or directory for w hich you do not have permi ssion

can cause this error.

– If an include file could not be opened, check that the INCLUDE

environment variable is set correctly and that the name of the file is

spelled correctly.

E0012: cannot read file: <name>

The system generator encountered an error when trying to read a file.

This error can be caused by a disk error or by a fil e-sharing conflict.

E0013: cannot write file: <name>

An error occurred while SG was trying to write into the file.

E0014: Disk is fu ll

An error occurred while the system generator was trying to write to the

output file. The cause of this error is insufficient disk space.

E0015: Template file not found

The system generator could not find template file for use in the

generation process be cause the command-line option or

SYSGEN_TEMPLATE environment variable was set to an invalid

filename.

To eliminate this error, either correct command line or use the SET

command to change the SYSGEN_TEMPLATE environment variable so

that it points to a valid filename.

NON-DISCLOSURE AGREEMENT REQUIRED

System Generation Error Messag es

User’s Manual OSEK Opera ting System — Re v 1.2

300 System Generat ion Error Messages MO TORO LA

E0020: <flag> requires an argument

A command-line option requires an argument, but nothing is specified.

E0021: no input file specified

The input file is not specified in the command line.

E0030: Incorrect object name

Incorr ect name was defined for obje ct. The first char acter o f an id entifier

name must be an underscore or an uppercase or lowercase letter. The

next characters of an identifier name must be an underscore or an

uppercase or lowercase letter or a digit.

The following OIL keywords can not be used as identifier:

STRING, INT, BOOLEAN, ENUM, AUTO, WITH_AUTO,

CPU, GROUP, CFG, PCFG, CONSTANT, NETWORK,

OS, TASK, MESSAGE, STACK, ISR, EVENT, RESOURCE,

COUNTER, ALARM ,

COM, NM, NODE, NETMESSAGE, CONNECTION, LINK,

NMCFGALARM, NMSTATEALARM.

E0032: Undefined object type

The non-standard object type was detected, object definition ignored.

E0033: This OIL version is not supported

The unsupported OIL version was defined as value for the

OIL_VERSION

attribute.

E0034: Undefined OIL version

The undefined OIL version was detected.

E0035: Only one CPU can be defined in the STANDARD OIL

E0036: Configuration is not supported in the STANDARD OIL

E0037: Object library is not supported in the STANDARD OIL

E003 8: C PU <name >: C FGACT IVE att rib ut e is n ot supp or ted in t he

Standard format

System Generation Er ror Messages

Error Mess ages

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Generat ion Error Messages 301

NON-DISCLOSURE AGREEMENT REQUIRED

The standard OIL format is intended to define simple application inside

separate CPU without using object library and configuration.

E0039: CPU <name>: Active CFG <cfg> is not defined.

Attribute "CFGACTIVE" deleted

The

CFGACTIVE

attribute was defined while the CFG with desired

name was not detected.

E0040: Same name <name> is used for different objects.

CPU <cpu>: Same name for several object inside cfg: <name>

CPU <cpu> : Same name for several object inside Cpu: < name>

The g iven name has a lready been used for a syst em o bject o f the othe r

type.

E0041: <object type> objects are not supported

The object type is not supported in the current implementation.

E0042: No NET can be defined in the STANDARD OIL

The standard OIL format is intended to define simple application inside

separate CPU without NETWORK configurati on.

E0043: Project Configurat ion is not sup ported in the STANDARD

OIL

The standard OIL format is intended to define simple application inside

separate CPU without using Project configuration.

E0044: Constant Table is not supported in the STANDARD OIL

The standard OIL format is intended to define simple application without

using Constant tables.

E0046: Invalid reference

The re ference was not defined in the implementation.

E0047: <name> reference is single, so only one parameter will be

processed!

The set of values was listed for single reference.

NON-DISCLOSURE AGREEMENT REQUIRED

System Generation Error Messag es

User’s Manual OSEK Opera ting System — Re v 1.2

302 System Generat ion Error Messages MO TORO LA

E0048: Unresolved reference from <name> to <name>

The re ferenced object was not found.

E0049: Invalid referenced object type from <name> to <name>

The re ferenced object type does not correspond to reference type.

E0050: CP U <nam e>: M or e t han on e OS de fin ed insid e lo cal o bjec t

CPU <nam e>: More than on e OS de fin ed in sid e cf g: <n am e>

Only one OS shall be defined for application.

E0051: Desired cpu <name> is not defined in the file

No cpu was defined in the file

Either the CPU specifi ed in comma nd line was no t found in the file o r no

CPU was defined in the file.

E0052: Active Project CFG <pcfg> is not defined

The

PCFGACTIVE

attribute was defined while the PCFG with desired

name was not detected.

E0053 no <name> configuration defi ned inside <cpu> CPU

no <name> co nfi g uration defined inside <net> NET WOR K

The setting for CPU or NETWORK was defined inside PCFG but the

referenced CFG was not defined for defined object.

E0054: unresolved reference from project configuration <pcfg> to

<name>

The setting for CPU or Network was defined inside PCFG but neither

CPU nor NETWORK with the name was defined.

E0055: redefinition of <name> table item

The given identifier was defined twice inside table (either Constant or

Project configuration table) . The system generator used the second

definition.

E0056: redefinition of CPU <cpu> c onfiguration

System Generation Er ror Messages

Error Mess ages

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Generat ion Error Messages 303

NON-DISCLOSURE AGREEMENT REQUIRED

The configuration for given CPU was defined twice inside Project

configuration table. The system generator used the second definition.

E0070: Only one implementation definition is allowed

More than one Implementation definition was found in the input file.

E0071: Redefined type of reference does not correspond to

previously defined.

New type ignored!

Other reference type defined for standard reference.

E0072: Redefined type of referenced object does not correspond to

previously defined

Other referenced object type defined for standard reference.

E0073: Redefined type of attribute does not correspond to

standard.

Definition ignored

Other type of standard attribute defined.

E0074: Attribute redefinition: previous attribute definition ignored

Implementation specific attribute was defined twice, only last definition

make a sense.

E0075: Invalid default value

Default value does not correspond to attribute type or attribute value

range.

E007 6: R an ge v alue do es no t co rr esp ond to attribu te type, ign or ed

Range value does not correspond to attribute type.

E0077: undefined type of refe renced object

The undefined type of referenced object was defined in reference

definition.

NON-DISCLOSURE AGREEMENT REQUIRED

System Generation Error Messag es

User’s Manual OSEK Opera ting System — Re v 1.2

304 System Generat ion Error Messages MO TORO LA

E0080: <attribute name> attribute is not defined in the

implementation

The used implementation does not correspond to current version of

system generator. Check your implementation file or contact vendor.

E0090: the <name> application mode is not defined

The application mode is listed as the CFG_ACTIVE attribute value but

there is not the CFG with defined name.

E0091: only TASK can be redefined for mode

Other than TASK object is defined inside CFG declared as application

mode. There is restriction that only set of tasks can be varied in

appl icati on mode .

E0092: TargetMCU shall be defined

The default value for TargetMCU is not allowed.

E0100: No OS defined for Cpu: <cpu name>

No OS defined inside cfg: <cfg name>

OS is manda tory object for C PU. Th e OS shall be def in ed either in local

CPU object or for each configuration.

E0102: Undefined attribute

The attribute was not defined in the implementation.

E0103: Invalid attribute value

The attribute value does not correspond to the type or range.

E0104: incorrect property <name> setting

The setting of the property <name> is incompatible with other current

settings.

E0105: method of task stack assignment is not defined

At least one of task stack assignment methods shall be defined, either

NodeStack

StackPool

TaskOwnStack

System Generation Er ror Messages

Error Mess ages

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Generat ion Error Messages 305

NON-DISCLOSURE AGREEMENT REQUIRED

E010 6: Si mp leSched ule r pr op erty can n ot b e u sed w i th R eso urces

property

SimpleScheduler

is used then the resources can not be used.

E0107: Conformance class shall be defined

The

attribute was not defined.

E0108: status shall be defined

The

STATUS

attribute was not defined.

E0110: interrupt masks shall be defined

The

InterruptMaskControl

property is turned on, but the inter rupt masks

are not defined.

E0111: interrupt stack shall be defined

The

EntryExitISR

property is turned on, but the interrupt stack is not

defined.

E0112: Multiple activation is not supported in BCC1

Multiple activation is not supported in ECC1

According to OSEK OS spec. v2.0 Multiple task activation is not

supported for the

BCC1

and

ECC1

conformance classes.

E0113: no task with multiple activation defined

The Mu ltiplyActivation property is turned on, but no task with multiple

activation defined. To avoid this error turn the MultiplyActivation property

of or define ACTIVATION attribute for task greater than 1.

E0115: TimeModuloValue shall be defined

The TimerModulo property is turned on, but TimerModuloValue is not

defined.

E0116: PrescalerValue shall be defined

The Prescaler property is turned on, but PrescalerValue is not defined.

NON-DISCLOSURE AGREEMENT REQUIRED

System Generation Error Messag es

User’s Manual OSEK Opera ting System — Re v 1.2

306 System Generat ion Error Messages MO TORO LA

E0117: resource access checking is not supported in standard

status

The ResourceAccessCheck property is turned on, but

STANDARD

status of the system define d. To avoid this error set

EXTENDED

status

or turn ResourceAccessCheck property off.

E0118: resource access checking is not supported for

FastResource

The ResourceAccessCheck property is turned on, but FastResource

proper ty is tu rned on too. To a void th is err or se t F astResour ce pr operty

off.

E011 9: resou rce acce ss checking is n ot suppor ted fo r more th an 8

resources

The ResourceAccessCheck property is turned on, but more than 8

resources are defined. To avoid this error set ResourceAccessCheck

property off.

E0120: error hook shall be defined

The

ErrorHook

property is turned on, but the error hook is not defined.

E0121: context switch routines shall be defined

The

PreTaskHook

PostTaskHook

property is turned on, but the

corresponding routine is not defined.

E0122: more than one hook of the type defined

The several hooks with the same type were defined.

E0123: startup hook shall be defined

The

StartupHook

property is turned on, but the startup hook is not

defined.

E0124: shutdown hook shall be defined

The

ShutdownHook

property is turned on, b ut the shutd ow n h ook is n ot

defined.

System Generation Er ror Messages

Error Mess ages

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Generat ion Error Messages 307

NON-DISCLOSURE AGREEMENT REQUIRED

E0160: Reconfig property turned off, no application mode

supported

More than one application modes are defined but

Reconfig

property is

turned off. Either turn

Reconfig

property on or change definition of

application mode set.

E0201: the number of task control blocks shall be greater than 0

The

NodeNumber

attribute is equal to 0.

E0202: number of priorities shall be greater than 0

The

MaxPrio

attribute is equal to 0.

E0203: size of scheduler stack shall be defined

The

UseMainStack

property is turned off, but the

SchedulerStackSize

attribute is not defined.

E0204: size of task node stack shall be defined

The

NodeStack

property is turned on, but the

TaskNodeStackSize

attribute is not defined.

E0205: number of task control blocks less than priority range

The number of task control blocks are less than maximum of ta sk

priority, it is not enough in case of

SimpleScheduler

E0302: EXTENDED task not supported in BASIC classes

The OS Conformance Class is defined as one of the BCC classes, but a

task has the

EXTENDED

type.

E0304: task priority exceeds the maximu m limit

The defined task priority is greater than

MaxPrio

attribute d efined for OS.

E0305: the number of task nodes is not enough to allocate

pe rs iste nt nod es

The number of tasks with persistent node are greater than the number

of nodes. A lso this error is caused when the number of tasks with

NON-DISCLOSURE AGREEMENT REQUIRED

System Generation Error Messag es

User’s Manual OSEK Opera ting System — Re v 1.2

308 System Generat ion Error Messages MO TORO LA

persistent node is equal to number of nodes and there are at least one

more tasks.

E0306: the stack pool parameter shall be defined

A task has the define d

POOLSTACK

stack attachment met hod, but the

StackPool

reference has not been defined.

E0308: the basic task cannot be notified by event setting

The basic task is referenced by ALARM or MESSAGE to be notified by

event setting.

E0309: at least one task shall be defined

At least one task shall be defined in the system.

E031 0: NodeSt ack proper ty is turned o ff, stack can not be allocat ed

A task has the define d

NODESTACK

stack attachm ent m ethod , but the

NodeStack

property is turned off.

E0310:

StackPool

property is turned off, stack cannot be allocated

A task has the define d

POOL STACK

stack attachment met hod, but the

StackPool

property is turned off.

E0311: task has no stack

The m ethod of ta sk stack a ttachm ent is not defined o r no t supp orted by

the OS.

E0312: the stack size parameter shall be defined

A task has the d efined

OWNSTACK

attachment method, but the

STACKSIZE

attribute has not been defined.

E0313: Multiple activation is not supported for EXTENDED task

Multiple activation is not supported in BCC1

Multiple activation is not supported in ECC1

The

ACTIVATION

attribute has the value greater than 1, but according

to OSEK OS spec. 2.0 multiple task activation is not supported in the

System Generation Er ror Messages

Error Mess ages

OSEK Op erati ng System — Rev 1.2 User’s Manual

MOTOROLA System Generat ion Error Messages 309

NON-DISCLOSURE AGREEMENT REQUIRED

BCC1

and

ECC1

conformance classes for

BACIS

task and never

supported for

EXTENDED

task.

E0314: non-preemptive tasks are not supported by full-preemptive

scheduler

preemptive tasks are not supported by non-preemptive

scheduler

The defined task preemptive property is incompatible with defined

schedul ing policy.

E0318: task scheduling type shall be defined

Task preemptive property is not defined. The

SCHEDULE

attribute is

obligatory for TASK object.

E0319: task type shall be defined

The task type is not defined. The

TYPE

attribute is obligatory for TASK

object.

E0320: task priority shall be defined

Task priority property is not defined. The

PRIORITY

attribute is

obligatory for TASK object.

E0321: number of task activations shall be defined

Number of task acti vations is not de fined. T he

ACTIVATION

attrib ute is

obligatory for TASK object.

E0322: AUTOSTART task property shall be defined

Initial task state is not defined. The

AUTOSTART

attribute is ob ligatory

for TASK object.

E0323: only EXTENDED task can have Events

The

BASIC

task has the reference to EVENT.

E0324: EVENT not supported in BASIC classes

The task has the reference to EVENT.

NON-DISCLOSURE AGREEMENT REQUIRED

System Generation Error Messag es

User’s Manual OSEK Opera ting System — Re v 1.2

310 System Generat ion Error Messages MO TORO LA

E0325:

TaskOwnStack

property is turned off, stack cannot be

allocated

A task has the d efined

OWNSTACK

stack attachment method, but the

TaskOwnStack

property is turned off.

E0326: the same priority can’t be defined for tasks in case of

SimpleScheduler

The simp lified sched uler ca n be used only if e ach task in the app lication

has an unique priority.

E0351: Size of buffer in the pool shall be defined

Size of buffer in the pool shall be defined for the STACK object.

E0352: Number of buffers in the pool shall be defined

Number of buffers in the pool shall be defined for the STACK object.

E0401: resource priority exceeds the maximum limit

The defined

PRIORITY

attribute for RESOURCE is greater than

MaxPrio

attribute of OS.

E0450: ISR category shall be defined

The