AMX 86 User Manual
AMX™ 86 User's Guide
First Printing: November 1, 1990
Last Printing: March 1, 2005
®
Copyright © 1990 - 2005
KADAK Products Ltd.
206 - 1847 West Broadway Avenue
Vancouver, BC, Canada, V6J 1Y5
Phone: (604) 734-2796
Fax: (604) 734-8114
TECHNICAL SUPPORT
KADAK Products Ltd. is committed to technical support for its software products. Our
programs are designed to be easily incorporated in your systems and every effort has
been made to eliminate errors.
Engineering Change Notices (ECNs) are provided periodically to repair faults or to
improve performance. You will automatically receive these updates during the product's
initial support period. For technical support beyond the initial period, you must purchase
a Technical Support Subscription. Contact KADAK for details. Please keep us inform ed
of the primary user in your company to whom update notices and other pertinent
information should be directed.
Should you require direct technical assistance in your use of this KADAK software
product, engineering support is available by telephone, fax or e-mail. KADAK reserves
the right to charge for technical support services which it deems to be beyond the normal
scope of technical support.
We would be pleased to receive your comments and suggestions concerning this produ ct
and its documentation. Your feedback helps in the continuing product evolution.
AMX 86 User's Guide
KADAK Products Ltd.
206 - 1847 West Broadway Avenue
Vancouver, BC, Canada, V6J 1Y5
Phone: (604) 734-2796
Fax: (604) 734-8114
e-mail: amxtech@kadak.com
KADAK
i
Copyright © 1990-2005 by KADAK Products Ltd.
All rights reserved.
No part of this publication may be reproduced, transmitted, transcribed,
stored in a retrieval system, or translated into any language or computer
language, in any form or by any means, electronic, mechanical,
magnetic, optical, chemical, manual or otherwise, without the prior
written permission of KADAK Products Ltd., Vancouver, B.C., CANADA.
DISCLAIMER
KADAK Products Ltd. makes no representations or warranties with
respect to the contents hereof and specifically disclaims any implied
warranties of merchantability and fitness for any particular purpose.
Further, KADAK Products Ltd. reserves the right to revise this
publication and to make changes from time to time in the content
hereof without obligation of KADAK Products Ltd. to notify any
person of such revision or changes.
TRADEMARKS
AMX in the stylized form and KwikNet are registered trademarks of KADAK Products Ltd.
AMX, AMX/FS, InSight,
Microsoft, MS-DOS and Windows are registered trademarks of Microsoft Corporation.
All other trademarked names are the property of their respective owners.
ii
KwikLook and KwikPeg are trademarks of KADAK Products Ltd.
KADAK
AMX 86 User's Guide
Section 1: System Description
1. AMX Overview 1
1.1 Introduction ........................................................................................ 1
1.2 Glossary ............................................................................................. 3
1.3 AMX Nomenclature ........................................................................... 7
2. General AMX Operation 9
2.1 Introduction to Multitasking ............................................................... 9
2.2 AMX Operation ................................................................................. 11
2.3 AMX Managers .................................................................................. 17
2.4 Starting AMX ..................................................................................... 20
3. Application Tasks 25
3.1 Task Creation ..................................................................................... 25
3.2 Task States ......................................................................................... 27
3.3 Starting a Task .................................................................................... 29
3.4 Task Priority ....................................................................................... 30
3.5 Task Execution ................................................................................... 31
3.6 Task and Event Synchronization ........................................................ 32
3.7 Task Timing ....................................................................................... 34
3.8 Ending a Task ..................................................................................... 35
3.9 Message Passing ................................................................................. 36
3.10 Restart Procedures ............................................................................ 42
3.11 Exit Procedures ................................................................................ 44
3.12 Task Enhancements .......................................................................... 46
AMX 86 USER'S GUIDE
Table of Contents
Page
AMX 86 User's Guide
4. Interrupt Service Procedures 49
4.1 The Processor Interrupt Facility ......................................................... 49
4.2 ISPs for External Interrupts ................................................................ 51
4.3 Nested Interrupts ................................................................................ 56
4.4 ISP/Task Communication .................................................................. 57
4.5 Task Error Traps ................................................................................ 60
4.6 Non-Maskable Interrupt ..................................................................... 64
4.7 Special Interrupts ............................................................................... 65
4.8 Vector Table Initialization ................................................................. 68
5. AMX Timing Control 69
5.1 Introduction to Timing Facilities ........................................................ 69
5.2 AMX Clock Handler and Kernel Task ............................................... 71
5.3 Interval Timers and Timer Procedures ............................................... 75
5.4 Task Time Slicing .............................................................................. 79
5.5 Time/Date Manager ............................................................................ 82
KADAK
iii
AMX 86 USER'S GUIDE
Table of Contents (Cont'd.)
Section 1: System Description (Cont'd.)
6. AMX Semaphore Manager 91
6.1 Introduction ........................................................................................ 91
6.2 Semaphore Use ................................................................................... 93
6.3 Semaphore Applications .................................................................... 97
7. AMX Event Manager 103
7.1 Introduction ........................................................................................ 103
7.2 Event Synchronization ....................................................................... 105
7.3 Event Flag Application ....................................................................... 107
8. AMX Message Exchange Manager 111
8.1 Introduction ........................................................................................ 111
8.2 Message Exchange Use ...................................................................... 113
8.3 Message Exchange Application ......................................................... 115
Page
9. AMX Buffer Manager 119
9.1 Introduction ........................................................................................ 119
9.2 Buffer Pool Use .................................................................................. 120
9.3 Buffer Applications ............................................................................ 122
9.4 Buffer Manager Caveats ..................................................................... 124
10. AMX Memory Manager 125
10.1 Introduction ...................................................................................... 125
10.2 Nomenclature ................................................................................... 127
10.3 Memory Allocation .......................................................................... 128
10.4 Private Memory Allocation .............................................................. 130
10.5 Memory Assignment ........................................................................ 131
10.6 Memory Assignment Procedure ....................................................... 132
11. AMX Circular List Manager 135
11.1 Circular Lists .................................................................................... 135
11.2 Circular List Use .............................................................................. 136
11.3 Circular List Structure ...................................................................... 137
iv
KADAK
AMX 86 User's Guide
AMX 86 USER'S GUIDE
Table of Contents (Cont'd.)
Section 1: System Description (Cont'd.)
12. AMX Linked List Manager 139
12.1 Introduction ...................................................................................... 139
12.2 Linked Lists ...................................................................................... 140
12.3 Linked List Use ................................................................................ 142
13. Advanced Topics 147
13.1 Fatal Exit .......................................................................................... 147
13.2 User Error Procedure ........................................................................ 150
13.3 Task Scheduling Hooks .................................................................... 152
13.4 Abnormal Task Termination ............................................................ 153
13.5 Task Suspend/Resume ...................................................................... 158
13.6 Breakpoint Manager ......................................................................... 159
Section 2: System Construction
Page
14. AMX System Configuration 163
14.1 System Configuration Module ......................................................... 163
14.2 System Configuration Builder .......................................................... 164
14.3 Using the Builder ............................................................................. 166
14.4 System Parameter Definition ............................................................ 170
14.5 AMX Object Allocation ................................................................... 173
14.6 Restart/Exit Procedure Definition .................................................... 176
14.7 Task Definition ................................................................................. 178
14.8 Timer Definition ............................................................................... 181
14.9 Semaphore Definition ...................................................................... 183
14.10 Event Group Definition .................................................................. 185
14.11 Message Exchange Definition ........................................................ 187
14.12 Buffer Pool Definition .................................................................... 189
14.13 Breakpoint Manager Definition ...................................................... 191
Section 3: Programming Guide
15. AMX Service Procedures 193
15.1 Introduction ...................................................................................... 193
15.2 Summary of Services ....................................................................... 194
AMX 86 User's Guide
16. AMX 86 Procedures 201
16.1 Introduction ...................................................................................... 201
Alphabetic List of Procedures .......................................................... 205
KADAK
v
Appendices
A. AMX 86 Reserved Words 347
B. AMX 86 Error Codes 349
C. Configuration Generator Specifications 353
D. AMX 86 Structure and Constant Definitions 365
E. AMX 86 Assembler Interface 381
AMX 86 USER'S GUIDE
Table of Contents (Cont'd.)
Page
C.1 Introduction ....................................................................................... 353
C.2 User Parameter File Specification ..................................................... 354
C.3 System Configuration Template ........................................................ 359
C.4 Porting the Configuration Generator ................................................. 362
D.1 AMX C Structures and Constants ..................................................... 365
D.2 AMX Assembler Structures and Constants ....................................... 373
Index Index-1
AMX 86 USER'S GUIDE
Table of Figures
Page
Section 1: System Description
Figure 2.2-1 AMX General Operation ..................................................... 12
Figure 3.2-1 AMX Task State Diagram ................................................... 28
Figure 3.9-1 Message Transmission ......................................................... 38
Figure 3.9-2 Message Reception .............................................................. 39
Figure 5.4-1 Simple Time Slicing ............................................................ 80
Figure 5.4-2 Interrupted Time Slicing ...................................................... 80
Figure 5.5-1 Time/Date Format Specification Parameter ........................ 89
Figure 12.2-1 Doubly Linked Lists ........................................................... 141
Section 2: System Construction
Figure 14.2-1 AMX Configuration Building Process .............................. 165
Figure 14.3-1 Configuration Manager Screen Layout .............................. 167
Appendices
Figure C.2-1 User Parameter File ............................................................. 354
vi
KADAK
AMX 86 User's Guide
1. AMX Overview
1.1 Introduction
The AMX™ Multitasking Executive provides a simple solution to the complexity of realtime multitasking. AMX supervises the orderly execution of a set of application program
modules called tasks. AMX allows the system designer to concentrate on the application
without becoming overly concerned about the multitasking aspects of the solution.
AMX is based on concepts proven over the past thirty years in minicomputer and
microprocessor applications in process control environments. AMX simplifies real-time
software implementation by providing the system designer with a well-defined set of
rules.
AMX operates in real mode on any Intel
including the 8086/8088, 80186/188, 80286, Intel386
also be used on the VAutomation 24-bit Turbo86 processor family. Unless otherwise
specified, references in this manual to 8086 infer all of the other processors as well.
AMX gives the system designer complete flexibility and control over the microcomputer
configuration employed. A real-time clock must be provided in the configuration if
AMX timing facilities are to be employed.
AMX provides a wide variety of services from which the real-time system designer can
choose. Many of the services are optional and, if not used, will not even be present in
your AMX system. The AMX managers are all optional.
®
8086 compatible microprocessor system
™
, Intel486™ and Pentium™. It can
The purpose of this manual is to provide the system designer and applications
programmer with the information required to properly configure and implement an
AMX-based real-time operating system. It is assumed that you are familiar with the
architecture of the processor on which you will be using AMX. It is further assumed that
you are familiar with the rudiments of microprocessor programming including the
concepts of code, data and stack separation.
For historical reasons, AMX 86 is coded in assembly language. The result is a fast,
compact, reliable implementation whose code has remained invariant throughout the
lifetime of this very stable product. AMX is provided in source format to ensure that
regardless of your development environment, your ability to use and support AMX is
uninhibited.
The C programming language, commonly used in real-time s ystems, is used throughout
this manual to illustrate the features of AMX.
AMX Overview
KADAK
1
Section Summary
This manual is divided into three sections. Each section is divided into chapters.
Section 1 of this manual describes the AMX Multitasking System and how it is used.
Separate chapters are provided for each of the AMX managers.
Section 2 describes the AMX System Configuration Builder and the manner in which it is
used to create your AMX System Configuration Module.
Section 3 is the application programming guide. It provides detailed descriptions of all of
the AMX service procedures which are available in the AMX Library.
AMX Guides
This manual describes the use of AMX 86 for all target processors on which it can be
used. Target specific requirements or programming considerations are provided only
when necessary to clarify proper operation on a particular processor.
This manual describes the use of AMX in a tool set independent fashion. References to
specific assemblers, compilers, librarians, linkers, locators and debuggers a re purposely
omitted. The AMX 86 Tool Guide provides guidance for the proper use of AMX with
each toolset with which AMX has been tested.
Guidelines for the proper use of AMX when coding in C are provided in the separate
AMX 86 C Programming Guide. This guide includes useful debugging tips as well as a
description of the AMX Sample Program provided with AMX.
The AMX 86 T iming Guide discusses general timing issues related to the use of AMX.
Timing metrics generated for specific boards and software development toolsets are also
provided. These timing figures can be used as guidelines to expected AMX performance,
but are not to be construed as product specifications. The AMX Timing Guide is
provided as an appendix in the AMX 86 Tool Guide.
Note
The AMX 86 PC Supervisor is delivered with AMX for use
in the development of applications which must run on PCs
with access to PC peripherals and DOS.
The AMX 86 PC Supervisor Reference Manual is provided
in its own section of this manual.
2
KADAK
AMX Overview
1.2 Glossar y
Buffer Pool A collection of data buffers whose use is controlled by the AMX
Buffer Manager.
Buffer Pool Id The handle assigned to a buffer pool by AMX for use as a unique
buffer pool identifier.
Circular List An application data structure used to maintain a list of 1, 2 or 4
byte elements with the ability to add and remove elements at both
the top (head) and bottom (tail) of the list.
Clock Handler The name given to the AMX procedure which is called by the ISP
root which services the hardware clock interrupt.
Clock Tick The interrupt generated by a hardware clock.
Conforming ISP An Interrupt Service Procedure consisting of an ISP root which
calls an Interrupt Handler which has the right to make calls to a
subset of the AMX service procedures.
Counting Semaphore
A particular type of AMX semaphore used for event signalling or
for controlling access by tasks to multiple resources.
Envelope The private data storage element used b y AMX to pass a m essage
to a task mailbox or message exchange.
Error Code A series of signed integers used by AMX to indicate error or
warning conditions detected by AMX service procedures.
Event Group A set of 16 events whose access and signalling is controlled by the
AMX Event Manager.
Event Group Id The handle assigned to an event group by AMX for use as a unique
event group identifier.
Exit Procedure An AMX or application procedure executed by AMX during the
exit phase when an AMX system is shut down.
Fatal Error A condition detected by AMX which is considered so abnormal
that to proceed might risk catastrophic consequences. Examples
include, but are not limited to, insufficient memory in the AMX
Data Segment or division by zero in an ISP.
FIFO First in, first out. Usually used to refer to the ordering of elements
in a queue, circular list or linked list.
Group Id See Event Group Id.
Handle An identifier assigned by AMX for use by your application to
AMX Overview
reference a private AMX system data item.
KADAK
3
Interrupt Handler An application procedure called from an ISP root to service an
interrupting device.
Interrupt Service Procedure (ISP)
An AMX or application procedure which is executed in response
to an external device interrupt request.
ISP See Interrupt Service Procedure
ISP root The ISP code fragment (produced by AMX function ajispm())
which informs AMX that an interrupt has occurred and calls an
application Interrupt Handler.
Kernel Task The private AMX task which is responsible for all timing control
and event sequencing in an AMX system.
Linked List An application data structure used to maintain a doubly-linked list
of arbitrary application data elements with the ability to add and
remove elements at head, tail or specified positions in the list.
List Element An 8-bit, 16-bit or 32-bit value which can be added to or removed
from a circular list.
Mailbox An AMX data structure consisting of a single message queue.
Mailboxes allow the interchange of messages between two or more
cooperating components (tasks, ISPs, etc.) of an AMX system.
Each task or message exchange can have up to four mailboxes.
Memory Block A portion of a memory section that has been allocated for use by
one or more tasks.
Memory Handle The handle assigned to a private memory section by AMX for use
as a unique memory section identifier.
Memory Section A contiguous region of memory assigned to the AMX Memory
Manager for allocation to application tasks.
Message Application information passed by AMX in an envelope to a task
mailbox or message exchange.
Message Exchange An AMX data structure that consists of four message queues, each
for messages of a different priority. The message exchanges allow
the interchange and prioritization of messages between two or
more cooperating components (tasks, ISPs, etc.) of an AMX
system.
Message Exchange Id
The handle assigned to a message exchan ge by AMX for use as a
unique message exchange identifier.
4
KADAK
AMX Overview
Message Queue An AMX data structure used to manage messages sent to a task
mailbox or message exchange. A separate message queue is
provided for each of the four message priorities which a task or
message exchange can support.
Message Priority Identifies which of a task's or message exchange's four message
queues is to receive the AMX message.
Nonconforming ISP An Interrupt Service Procedure which bypasses AMX completely
and hence cannot use any AMX service procedures.
RAM Alterable memory used for data storage and stacks.
Resource Semaphore
A particular type of AMX semaphore used to provide access to an
entity such as a math coprocessor, disk file or non-reentrant library
whose ownership is to be controlled by the AMX Semaphore
Manager.
Restart Procedure An AMX or application procedure executed by AMX during the
initialization phase when an AMX system is started.
ROM Read only memory of all types including PROMs, EPROMs and
EAROMs.
Segment An area of memory in which AMX code or data is stored.
Segments are sometimes called sections or regions according to the
nomenclature adopted for a particular processor.
Semaphore An AMX data structure which can be used by the AMX
Semaphore Manager to provide an event signalling mechanism or
mutually exclusive access by tasks to specific user facilities.
Semaphore Id The handle assigned to a semaphore by AMX for use as a unique
semaphore identifier.
Slice Interval The interval of time allocated to a task which is time sliced.
Slot One of n locations used to store list elements in a circular list.
System Configuration Module
A software module, produced by the AMX S ystem Configuration
Builder, which defines the characteristics of a particular AMX
application.
System Tick A multiple of the hardware clock tick from which the fundament al
AMX unit of time is derived. All time intervals in an AMX system
are measured in multiples of the system tick.
Tag A 4-character name that can b e assigned to an y AMX system dat a
structure when it is created. A tag can be used to find the identifier
of a task, timer, semaphore, event group, message exchange or
buffer pool with a particular name.
AMX Overview
KADAK
5
Task An application procedure which is executed by AMX in a way
which makes it look as though all such procedures are ex ecuting at
once.
Task Control Block (TCB)
A private data structure maintained by AMX for each task in the
system.
Task Id The handle assigned to a task by AMX for use as a unique task
identifier.
Task Priority The priority at which a task executes. Tasks which have the same
task priority are actually ordered in priority according to the order
in which the tasks were created.
Task Signal A set of 15 user-defined event signals associated wi th ea ch task for
task synchronization use.
TCB See Task Control Block
Time Slice The process by which AMX allows tasks having the same priority
to share the use of the processor in a round robin fashion.
Timer A facility provided by AMX to permit precise interval
measurement in AMX applications.
Timer Id The handle assigned to a timer by AMX for use as a unique timer
Identifier.
Timer Procedure An application procedure which is executed by the AMX Kernel
Task whenever the corresponding timer interval expires.
6
KADAK
AMX Overview
1.3 AMX Nomenclature
The following nomenclature has been adopted throughout the AMX User's Guide.
Processor registers are referenced as follows:
8-Bit Registers AH, AL, BH, BL, CH, CL, DH, DL
16-Bit Registers AX, BX, CX, DX, SP, BP, SI, DI
Instruction Pointer IP
Flags (Condition Code) CC
Segment Registers CS, DS, SS, ES
The processor flags (condition code) are referenced using the mnemonics employed in
software branches as follows:
Zero Z
Non-zero NZ
Carry C
No Carry NC
Positive (no sign) NS
Minus (sign) S
Interrupt flag IF
Direction flag UP if forward; DN if backward
Numbers used in this manual are decimal unless otherwise indicated. Hexadecimal
numbers are indicated as 0xABCD in C code or 0ABCDH in assembly language code.
The terminology A(Table XYZ) is used to define add resses. It is r ead as "t he address of
Table XYZ".
Addresses are written as segment:offset. For example ES:BX is the address with segment
determined by extended register ES and offset determined by base register BX.
Read/write memory is referred to as RAM. Read only memory (non-volatile storage) is
referred to as ROM.
AMX symbol names are identified as follows:
ajxxxx AMX procedure called from C
AAXXXX AMX procedure called from assembler
AMXXXX Private AMX procedures, structures and constants
AERXXX AMX Error Code XXX
AA831xxx.xxx AMX kernel filenames
AJ831xxx.xxx AMX C Interface filenames
AMxxxxxx.xxx AMX reserved filenames
AA832xxx.xxx AMX PC Supervisor filenames
Throughout this manual examples are provided in C and assembly language. In general,
code examples in C are presented in lower case. Code examples in assembler are in
upper case. File names are shown in upper case. C code assumes that an int is 16 bits as
is common for most C compilers for the 8086 family.
AMX Overview
KADAK
7
This page left blank intentionally.
8
KADAK
AMX Overview
2. General AMX Operation
2.1 Introduction to Multitasking
A real-time system is characterized by the need to respond rapidly to events occurring
asynchronously in time. A multitasking system is one in which a number of activities or
processes must be performed simultaneously without interference with each other. A
system in which several activities must operate simultaneously with time-critical
precision is called a real-time multitasking system.
The AMX Multitasking Executive provides a simple solution to the
complexity of real-
time multitasking. AMX supervises the orderly execution of a set of application program
modules called tasks. Each task solves a particular problem and provides a specific
functional capability within the system.
As we all know, the microprocessor can only do one thing at a time. Fortunatel y, it does
all things very quickly. However, to get the effect that all activities are occurring
simultaneously, it is necessary to rapidly switch back and forth from one process to
another in a well controlled fashion. It is AMX which organizes and controls the use of
the microprocessor to achieve this apparent concurrent execution of tasks.
Each task solves a particular problem or provides a specific functional capability within
the system. Each task executes independent of other tasks. Facilities are provided,
however, to permit tasks to co-operate to achieve a common goal. This process in which
more than one task is allowed to share the use of a single processor is called multitasking.
The software program which makes it possible is AMX.
What a task does is completely application dependent. In fact, the most difficult aspect
of system design is to logically break the problem into a set of tasks which, if
implemented, will achieve the desired goal. The following example is presented to
illustrate one way in which a simple real-time alarm logging system can be implemented.
Example
Assume that it is necessary to periodically scan a set of digital alarm inputs. When any
alarm is detected, a message is to be logged on a printer. The message is to include a
description of the alarm and the time of day at which it occurred.
Careful examination of this problem indicates that in fact it is three problems. First, a set
of digital inputs must be scanned for the detection of alarms. Second, a message must be
printed. Finally, the time of day must be maintained for inclusion in the message.
Three problems usually result in three tasks. Our example is no exception. A time of day
task is required to maintain the date and time within the system. The task must be
executed once each second if time is to be maintained to the nearest second. We will
ignore the requirement to somehow set the proper time and date. (Isn't that another task?)
General AMX Operation
KADAK
9
Alarm scanning will likely be hardware dependent. We will simplify matters by
assuming that a scanning task must examine all digital inputs every 100 ms. The task
must be capable of detecting alarm changes in the digital inputs. When an alarm is
detected, the scanning task must initiate the logging of a message.
However, the scanning task is not allowed the luxury of waiting until the message is
printed. It must continue scanning for additional alarms at the same 100 ms rate. The
scanning task must, therefore, send to the message task parameters identifying the alarm
which has occurred and the time at which it was detected.
The message task is very simple to describe. It receives parameters identifying the time
at which a particular alarm occurred. The task must output to a printer a message
describing the alarm.
The foregoing example, although very simple, illustrates many of the features of a realtime multitasking system. At first, the implementation of the required set of tasks may be
difficult to envision. Two of the tasks must operate periodically at different intervals.
The third task, printing, is such a slow process that the other two tasks must be allowed to
execute with higher priority. Moreover, provision must be made to allow the alarm
parameters to continue piling up on the message task when alarms are occurring at a rate
faster than can be printed. (What would we do if we had to print high priority alarms first
and delay the printing of lower priority alarms?)
The implementation of the proposed solution is greatly simplified by AMX. AMX will
supervise the execution of the three tasks in the defined priority order. Timing facilities
are provided by AMX with a resolution governed by the hardware clock. AMX supports
message passing between tasks. AMX allows these messages to pile up at the destination
task at any of four priority levels because automatic message queuing with priority
sorting is an inherent feature of AMX.
This introduction to multitasking is not exhaustive. The intent is to remove some of the
mystery from the multitasking concept. The above example is intended to inspire
confidence in your ability to understand AMX and use it to solve real-time problems.
10
KADAK
General AMX Operation
2.2 AMX Operation
AMX Startup
Each AMX-based system consists of the AMX executive program and a set of
application tasks and interrupt service procedures. This collection of programs resident
in the memory of the microprocessor configuration represents the entire operating
system.
The manner in which the operating system begins execution is application dependent. In
ROM-based systems, automatic hardware vectoring to the program start address is often
implemented. In RAM-based systems, the program is first loaded from some storage
medium (ROM, hard disk, diskette, etc.) or downloaded from one processor to another.
Once the program is loaded, it is started at its start address by the loader.
Figure 2.2-1 illustrates the general operation of an AMX system. Execution be gins in the
user domain providing the opportunity for hardware specific and application dependent
setup prior to the initialization of the AMX system. For example, hardware interfaces
may require custom configuring. In some systems, it might be desirable to perform a
memory integrity check before system startup is permitted.
Once all custom initialization has been performed, the program calls the AMX entry
procedure ajentr. Operating characteristics are defined in an AMX System
Configuration Module. It is possible to predefine specific tasks and timers which will be
automatically created by AMX during its initialization phase. AMX initializes itself and
places all application tasks and timers into an idle state.
Once AMX has initialized all of its internal variables and structures, it executes a
sequence of user provided Restart Procedures. These procedures can invoke AMX
services to start tasks and initialize interval timers.
General AMX Operation
KADAK
11
Start
k
Initialization
Restart
Procedure
User AMX
Control Flow
Functi on calls
Interrupts
Task S cheduler
Task A
Kernel Task
Clock
Interrupt
Service
Procedure
Interrupt
Supervisor
Task N
Cloc
Handler
Services
Timer
Procedure
Figure 2.2-1 AMX General Operation
12
KADAK
General AMX Operation
The Task Scheduler
Following system initialization, AMX proceeds to its Task Scheduler. The Task
Scheduler searches its list of available tasks to determine the highest priority task capable
of execution. Task execution priorities are determined by the s ystem designer. If no task
is ready to begin execution, AMX sits with interrupts enabled, waiting for some external
event to generate an interrupt.
AMX begins task execution at the task's defined start address. The task executes as
though it were the only program in the system. Services offered by AMX can be invoked
by the task by procedure calls as indicated in Figure 2.2-1.
Once a task begins execution, it appears to operate without interruption. The interrupts
that are periodically taking place are completely hidden from the task by the AMX
Interrupt Supervisor and Task Scheduler. The task, once executing, inhibits the
performance of all tasks of priority lower than its own. The task continues to execute
until it decides to relinquish control, even if only temporarily, by calls to AMX.
The task ends by returning to the AMX Task Scheduler which again finds the next
highest priority task ready to execute and gives it control of the processor. A task, once
executing, is free to call any of the AMX task services. For instan ce, a task can send a
message to a task mailbox or message exchange, wait for an event or wait for a timed
interval. If the task wishes to wait for an event, the AMX service procedure will suspend
the task and request the AMX Task Scheduler to force execution of the next highest
priority task ready for execution.
AMX acts as the context switcher supervising the orderly execution of application tasks.
AMX employs a preemptive, priority-driven scheduling algorithm which ensures that the
highest priority task which is ready to do useful work always has control of the processor.
AMX will switch tasks if it receives a request from the executing task to perform an
operation which, of necessity, invokes a task of higher priority. For instance, the
executing task may request AMX to start a higher priority task.
General AMX Operation
KADAK
13
The Interrupt Supervisor
Tasks execute with the processor interrupt facility enabled to permit service of external
devices. When an external interrupt occu rs, the task i s int errupted i n the mann er dict ated
by the processor. The processor automatical ly saves the return address and some subset
of the processor state (registers, flags, etc.) and branches to an Interrupt Service
Procedure (ISP). The exact vectoring method is determined by the hardware
configuration employed in the system.
Two types of ISPs exist: nonconforming ISPs and conforming ISPs.
A nonconforming ISP must quickly service the device to remove the interrupting
condition. The ISP must preserve all registers which it uses. The nonconforming ISP
cannot make calls to any AMX service procedures.
A conforming ISP can make use of a subset of the AMX service procedures. A
conforming ISP consists of an ISP root and an Interrupt Handler. The processor vectors
to the ISP root which informs the AMX Interrupt Supervisor that the interrupt has
occurred. The Interrupt Supervisor preserves the state of the interrupted task and, if
necessary, switches to an interrupt stack. The Interrupt Supervisor then calls the
associated Interrupt Handler.
The Interrupt Handler must quickly service the device to remove the interrupting
condition. The handler is free to make procedure calls to a subset of the AMX service
facilities. When device service is completed, the AMX Interrupt Supervisor dismisses
the interrupt.
The AMX Interrupt Supervisor monitors calls made by the Interrupt Handler to AMX
service procedures. If no such calls have been made, AMX automatically restores the
state of the interrupted task and returns directly to the interrupted task at its point of
interruption.
The Interrupt Handler may have requested AMX to initiate or resume execution of some
task of higher priority than the interrupted task. If so, the AMX Interrupt Supervisor
suspends the interrupted task and marks it as ready to resume execution at the earliest
opportunity. The AMX Task Scheduler is then invoked to determine the highest priority
task capable of execution.
The AMX Interrupt Supervisor supports nested interrupts on processors which provide
this capability. If interrupts nest, the Interrupt Supervisor defers its task switching checks
until all of the concurrent interrupts have been serviced.
Note
A conforming ISP root can be created using AMX
procedure ajispm.
14
KADAK
General AMX Operation
Timing Facilities
The AMX Timer Manager provides a Clock Handler and a Kernel Task to provide
complete timing control for your real-time application. The AMX Clock Handler is
independent of any particular hardware configuration. If AMX timing facilities are to be
utilized, a real-time clock must be included in the configuration.
The hardware clock interrupt must be serviced by a conforming ISP. Whenever a cl ock
interrupt occurs, the application Interrupt Service Procedure must dismiss the hardware
clock interrupt and call the AMX Clock Handler.
The AMX Clock Handler triggers the AMX Kernel Task if required. The Kernel Task is
triggered at the user defined system tick interval if, and only if, there is any outstanding
timing activity required in the system. In this case, the interrupted task is suspended and
the AMX Kernel Task begins execution.
The AMX Kernel Task executes as the highest priorit y task in the system. The AMX
Kernel Task monitors all tasks which are in a timed wait state. If a task's timer expires,
the AMX Kernel Task primes the task to resume execution with a timeout indication.
The AMX Kernel Task also services all expiring application interval timers. Whenever
an application interval timer expires, the corresponding application Timer Procedure is
executed. This procedure can invoke a subset of the AMX services to send messages,
signal events or wake tasks. If the timer is defined to be periodic, the AMX Kernel Task
automatically restarts it with the predefined period.
General AMX Operation
KADAK
15
Message Queuing
One of the more powerful features of AMX is its ability to queue messages for tasks.
The queuing facility permits messages to pile up in a controlled fashion, fre eing the ISP,
Timer Procedure or task which is sending the message to continue with its appointed
function. If a task sends a message, it can suspend itself until the message has been
received and processed by some other task.
The AMX message queuing facility is further enhanced by allowing the messages to
queue at any of four priority levels. A task can therefor e receive messages from a variety
of callers with the messages already sorted in order of priority by AMX.
The system designer describes the exact message queuing requirements in a task
definition or in a message exchange definition. For each task and message exchange, you
can specify which, if any, of the four message queuing priorit y levels are to be support ed.
You also specify the required message nesting depth for each of these message queu es,
often referred to as mailboxes.
AMX maintains a free list of message envelopes. These envelopes are used by AMX to
transmit messages to the mailboxes of tasks and message exchanges. The caller's
message parameters are moved into a free envelope which is then added to the message
queue of the destination task mailbox or message exchange mailbox.
The AMX message queuing facility is especially useful in event logging applications. In
such applications, messages are transmitted to a printing task by any task wishing to log
an event. The printing task is then executed once for each unique request which it has
received. High priority messages can easily be forced to precede low priority messages
using the AMX message priority feature. Finally, any task wishing to wait until its
particular message has been logged can do so by informing AMX of its intent at the time
the message is sent.
AMX Shutdown
An AMX system can be shut down in the same orderly fashion in which it was started. A
task initiates a shutdown with a call to the AMX exit procedure
ajexit.
It is the caller's responsibility to assure that the AMX system is in a reasonable state to
permit a shutdown. For instance, all device I/O operations should be stopped and all
timing activity should be curtailed.
The AMX shutdown procedure executes a series of user Exit Procedures which can
restore the original environment which existed prior to starting the AMX system. Device
interfaces can be reprogrammed and interrupt vectors restored if necessary.
Once all of the Exit Procedures have b een executed, AMX returns to the point at which
AMX was originally launched.
16
KADAK
General AMX Operation
2.3 AMX Managers
AMX provides a set of managers to simplify event synchronization, resource
manipulation and memory allocation. Not all applications will make use of all of the
managers. The system designer can decide which of the AMX managers is best suited
for a particular application.
The Time/Date Manager provides Y2K compliant time of day calendar support if
required. The AMX calendar clock includes second, minute, hour, day, month, year and
day of the week. AMX services are provided to set and read the calendar clock.
A formatting procedure is also provided to translate the calendar time and date from the
internal format in which it is maintained by AMX into an ASCII string in several of the
most popular formats.
An application procedure can be tied to the calendar clock and called at one second
intervals to permit simple time of day event scheduling.
The Semaphore Manager provides two types of semaphores each with priority queuing
and timeout: resource semaphores and counting semaphores.
A resource semaphore can be used to provide controlled access to your resources. It uses
a binary semaphore to limit access to each resource to one task at a time. Ownership and
release of a resource is governed by calls to the Semaphore Manager. A resource
semaphore offers the unique characteristic of identifying each resource owner. Only the
task which owns a resource is permitted to release it.
General purpose counting semaphores can be created for mutual ex clusion and resource
management. Tasks must request the Semaphore Manager for access to the resource
controlled by such a semaphore. The task can specify the priorit y of its request to use the
semaphore. If the semaphore is not free, the task will be forced to wait for its
availability. The task will be placed on the semaphore wait queue at the priority specified
by the task. Optionally, the task can specify a timeout interval limiting the time the task
is prepared to wait.
A task, ISP or Timer Procedure can signal the semaphore with a call to the Semaphore
Manager. The Semaphore Manager grants access to the semapho re to the task, if any,
waiting at the top of the semaphore's wait queue.
The Ev ent Manager provides a convenient method for synchronizing one or more tasks
to events detected in Interrupt Service Proc edures, Timer Procedures and other tasks. A
task requests the Event Manager to suspend its operation until any one of a particular set
of events occurs. Alternatively, the task can request to wait until all of a set of event
conditions are met. Optionally, the task can specify a timeout interval limiting the time
the task is prepared to wait. More than one task can be waiting for the same event or set
of events.
When a task, ISP or Timer Procedure detects an event, it signals the event with a call to
the Event Manager. The Event Manager checks to see if the event has resulted in an
event combination for which one or more tasks are waiting. If so, the tasks which were
waiting are allowed to resume execution.
General AMX Operation
KADAK
17
The AMX 86 Task Mailbox facility provides a general purpose message queuing
mechanism for tasks. This service is not provided by a separate AMX manager; it is an
inherent feature of AMX 86. Any task can have up to four private mailboxes in which
the task can receive AMX messages. Tasks, ISPs or Timer Procedures can send
messages to such a task mailbox. The messages are ordered in each task mailbox
according to their order of arrival . If such a task is idle when a message is deposit ed in
one of its mailboxes, the task will automatically be started and given the message
extracted from the mailbox. At any time, a task can request a message from any of its
mailboxes. When the task ends, it will automatically be restarted if its mailboxes are not
all empty. The task will be given the highest priority message available.
The Message Exchange Manager provides a general purpose prioritized message
queuing facility. Tasks, ISPs or Timer Procedures can send messages to a message
exchange to be queued at any of four priority levels. When a task requests a message
from a message exchange, it is given the highest priority message available. If no
message is available, the task will be forced to wait. The task will be placed on the
message exchange wait queue at the wait priority specified by the task. Optionally, the
task can specify a timeout interval limiting the time the task is prepared to wait. This
interval can be from no wait to an indefinite wait. When a message subsequently arrives,
it is immediately given to the task waiting at the top of the message exchange's wait
queue.
The Buffer Manager provides fast, efficient access to multiple pools of buffers, each
buffer representing a fixed size block of memory. This form of memory management
meets the requirements of most typical applications and is best suited for real-time use in
which memory block availability must be predictable and in which the penalties for
memory fragmentation cannot be tolerated.
Application modules can request the Buffer Manager to get a buffer from a pool. Unlike
other AMX managers, the Buffer Manager does not permit a task to wait for a buffer to
become available.
When released, the buffer is automatically returned by the Buffer Manager to the pool to
which the buffer belongs. Buffer ownership can be increased so that more than one task
can simultaneously own a shared buffer. Special facilities are provided to assure that if a
buffer is owned by more than one task, it is only returned to its pool when the slowest
owner finally releases it.
Memory Manager controls the dynamic allocation of memory to tasks in the
The
multitasking environment. Multiple sections of user defined memory can be controlled
by the Memory Manager. A section can exceed 64K bytes. The memory in each section
must be contiguous but the sections themselves do not have to be contiguous.
A task can request the Memory Manager to allocate a contiguous block of memory of any
size. When finished with the block, the task requests the Memory Manager to free the
memory for use by other tasks.
A particularly unique feature of the Memory Manager permits any block of memory
(including those acquired from the Memory Manager) to be treated as memory from
which smaller private blocks can be dynamically allocated.
18
KADAK
General AMX Operation
The Circular List Manager provides a general purpose circular list facility for
maintaining compact lists of 8-bit, 16-bit or 32-bit variables. Circular lists are
particularly useful for managing character streams associated with input/output devices.
The Linked List Manager provides a fast, general purpose doubly-linked list facility for
maintaining lists of arbitrary application data structures (objects).
The Linked List Manager removes the tedium and the frequent errors usually encountered
when each application must manipulate the linkages of different types of objects on
different lists. Objects can reside on multiple lists at the same time, a characteristic
frequently encountered in real problems but ignored by most list manipulation software.
General AMX Operation
KADAK
19
2.4 Starting AMX
An AMX operating system consists of AMX, the subset of its managers which you
choose to use and your complement of application programs. All of these modules are
connected together to form the AMX operating system as described in the AMX Tool
Guide.
Before launching AMX, you must establish the required operating mode for the particular
target processor you are using. AMX 86 operates only in the 8086 real mode.
AMX uses the Medium or Large segmentation model in which multiple code segments
and one or more read/write data segments are provided. AMX makes no assumption
about the manner in which these segments correlate to physical memory.
AMX is launched with a launch parameter defining the nature of the launch. The l aunch
parameter is a 16-bit unsigned integer in which each bit defines a particular launch
characteristic. Bit mask mnemonics
AMX831SD.DEF.
Bit Value Launch parameter
0 0 Launch is permanent
AMLPTMP Launch is temporary
AMLPxx are defined in include files AMX831SD.H and
1 0 Vector Table is not alterable (in ROM or not accessible)
AMLPVA Vector Table is alterable (in RAM and accessible)
2 0 Interrupts disabled during launch
AMLPIE Interrupts enabled during launch
AMX is always launched from your main program (or startup module) by calling AMX
procedure ajentr from C or AAENTR from assembly language.
Your AMX operating system can be launched in two wa ys: permanently or temporarily.
The type of launch is determined by bit 0 of the launch parameter.
Bit 1 of the launch parameter indicates whether or not AMX will be permitted to alter the
processor vector table. For most applications, the vector table is in RAM and therefo re
alterable.
AMX disables the interrupt system at the time you launch AMX. Unless bit 2 of your
launch parameter indicates otherwise, interrupts will remain disabled during the startup
process while AMX initializes its internal parameters and calls each of your Restart
Procedures.
20
KADAK
General AMX Operation
Permanent Launch
In most applications, your AMX operating system is resident in ROM or loaded into
RAM. AMX is started in real mode and given permanent control of the processor.
An AMX system can be launched permanently from a main program coded in C as
illustrated in the following example.
The implication of starting AMX from a main C program is that a C startup module has
already provided a stack before procedure main was called. The main procedure calls
AMX at its entry point ajentr with three parameters. The first parameter is the launch
parameter. The value AMLPVA indicates that the launch is permanent (bit 0 is 0), vectors
are alterable (bit 1 set by AMLPVA) and interrupts are to be disabled during the launch (bit
2 is 0).
The second parameter is the pointer to your application's User Parameter Table in the
System Configuration Module which defines the characteristics of your AMX system.
The third parameter, NULL, must be present but is not used by AMX because the launch is
permanent.
/* Start AMX for permanent execution */
#include "amx831sd.h" /* AMX Structure Definitions */
void main()
{
struct amxupts FAR *uptp; /* User Parameter Table pointer*/
:
ajupt(&uptp); /* Fetch pointer to UPT */
/* Start AMX: no exit, */
/* vectors alterable and */
/* interrupts disabled */
ajentr(AMLPVA, uptp, NULL);
}
If the vector table is in ROM or, for any reason, is not to be altered by AMX, set the
launch parameter to 0 instead of AMLPVA. In this case, you will not be able to use AMX
services to dynamically install pointers to Interrupt Service Procedures into the vector
table.
If you wish interrupts enabled during the launch process, add AMLPIE to the launch
parameter. Be sure that interrupts from a particular device are inhibited until you have
installed an ISP to handle interrupts from the device.
General AMX Operation
KADAK
21
An AMX system can be launched permanently from a startup module coded in assembly
language as illustrated in the following example.
Systems of this type begin execution at the AMX entry point AAENTR with the launch
parameter in register BX. Register BX[0] must be set to zero to indicate that a perm anent
launch is required. Register pair
ES:SI must provide a pointer to the User Parameter
Table in the System Configuration Module which defines the characteristics of your
AMX system.
Set register
BX[1] to 0, you will not be able to use AMX services to dynamically install pointers to
BX[1] to 1 (AMLPVA) if interrupt vectors are to be alterable. If you set register
Interrupt Service Procedures into the vector table.
Set register BX[1] to 0 if interrupts are to be disabled during the startup process. If you
set register BX[1] to 1 (AMLPIE) to enable interrupts during the launch, be sure that
interrupts from a particular device are inhibited until you have installed an ISP to handle
interrupts from the device.
When AMX is started in this manner, it immediately establishes the AMX Kernel Stack
as the current stack. There is therefore no need for your applicat ion t o provide a st ack fo r
a permanent launch.
In a ROM based system, AMX is frequently restarted whenever the 8086 processor is
reset. A startup module, coded in assembler, receives control, initializes the 8086, enters
protected mode and starts AMX as illustrated in the following example.
EXTRN AAENTR:FAR ;AMX Entry Point
EXTRN _AMXUPT_:DWORD ;A(User Parameter Table)
;
USER_CODE SEGMENT BYTE 'CODE'
;
ASSUME CS:USER_CODE
;
UPTADR DD _AMXUPT_ ;A(User Parameter Table)
;
START PROC FAR
:
Initialize 8086
:
LDS SI,CS:UPTADR ;DS:SI = A(User Parameter Table)
MOV BX,AMLPVA ;BX = no exit, vectors alterable
;and interrupts disabled
JMP AAENTR ;start AMX
;
START ENDP
;
USER_CODE ENDS
22
KADAK
General AMX Operation
Loading...