Smx - RTOS

INTRO
smx ®
TRAINING CLASS
WORKBOOK
TASKS
ITC
v3.6
INTERNALS
A Class on the Theory
Of Using smx
by
Ralph Moore
MEMORY
I/O
© Copyright 1998, 2001, 2004
Micro Digital Associates, Inc.
2900 Bristol Street #G204
Costa Mesa, CA 92626
(714) 437-7333
support@smxinfo.com
www.smxinfo.com
All rights reserved.
TIMING
ERROR
SUMMARY AND
DISCUSSION
NOTES

SMX TRAINING CLASS
APPROXIMATE SCHEDULE
1st day
9:00 AM 1. INTRODUCTION
10:15 AM break
10:30 AM 2. TASKS
12:00 PM lunch
1:00 PM 3. INTERTASK COMMUNICATION
2:45 PM break
3:00 PM 4. INTERNALS
4:00 PM IN-DEPTH Q & A
5:00 PM done
2nd day
9:00 AM 5. MEMORY MANAGEMENT
10:15 AM break
10:30 AM 6. INTERRUPTS & I/O
12:00 PM lunch
1:00 PM 7. TIMING
2:00 PM 8. ERROR MANAGEMENT
2:45 PM break
3:00 PM 9. SUMMARY AND DISCUSSION
4:00 PM 10. DISCUSSION OF OTHER PRODUCTS
5:00 PM done

INTRODUCTION
1. OBJECTIVES
2. DEFINITIONS
3. WHAT IS WRONG WITH SUPERLOOPS?
4. BENEFITS OF MULTITASKING
5. METHODOLOGY OF MULTITASKING
a. NEW MINDSET
b. DIVIDE & CONQUER
6. PRECISION AGRICULTURE EXAMPLE
a. SOIL ANALYSIS MACHINE (SAM)
b. SAM BLOCK DIAGRAM
c. SAM FLOW DIAGRAM
7. WHAT SERVICES DOES A KERNEL PROVIDE?
8. MANUALS
a. REFERENCE MANUAL
b. USER’S GUIDE
c. QUICK START
INTRO-1

OBJECTIVES
TO TEACH:
1. THE PRINCIPLES OF MULTITASKING
2. HOW smx WORKS
3. HOW TO USE smx EFFECTIVELY TO SIMPLIFY APPLICATION
CODE
COURSE FORMAT
1. INFORMAL
2. QUESTIONS ARE WELCOME
REVIEW APPLICATION
1. SO I CAN SLANT COURSE AT IT
2. DRAW EXAMPLES FROM APPLICATION
WHO HAS USED MULTITASKING?
INTRO-2

DEFINITIONS
TASK
A SMALL PART OF A JOB. (SAME AS A THREAD.)
PROCESS
A COMPLETE EXECUTABLE OR APPLICATION.
USUALLY AN EMBEDDED SYSTEM IS A SINGLE PROCESS.
RTOS
LAN
Network
smx
Kernel
Shell
User Interface
We will be discussing
primarily the kernel
Sensors &
Actuators
Application
File i/o
Disk
BOOTS AND RUNS FROM RAM
LOADS, RUNS, AND MANAGES APPLICATION CODE
USUALLY LARGE, COMPLEX, SLOW & EXPENSIVE
SMX BREAKS THIS MOLD. IT IS A MODULAR RTOS
REAL-TIME MULTITASKING KERNEL (smx)
TARGETED AT BLACK BOXES W/O STD I/O DEVICES
RUNS FROM ROM ON POWER-UP OR RESET
USUALLY LINKED WITH APPLICATION
SMALL, SIMPLE, FAST, & INEXPENSIVE
HEREAFTER CALLED “KERNEL”
INTRO-3

WHAT IS WRONG WITH SUPERLOOPS?
1
2
1
2
3
3
INTERRUPT
TASK
4
1. LACK OF TASK INDEPENDENCE
2. CRUDE TASK SCHEDULING
a. FIXED EXECUTION ORDER ==> INFLEXIBILITY
b. NO TASK PRIORITIES
c. NO PREEMPTION
3. NO INTER-TASK COMMUNICATION MECHANISM
4. INFLEXIBILITY — HARD TO ADD MORE TASKS
5. POOR HANDLING OF ASYNCHRONOUS EVENTS
6. DIFFICULTY ACHIEVING FAST RESPONSE TIMES
THESE LIMITATIONS EVENTUALLY LEAD TO “SPAGHETTI CODE”
BASIC RULE:
WHAT IS NOT IN THE KERNEL ENDS UP IN THE APPLICATION
EXTREME KERNEL SIMPLICITY LEADS TO APPLICATION COMPLEXITY
INTRO-4

BENEFITS OF MULTITASKING
TASK
ISR
Client
F1
F3
Server
OR
TASK TASK TASK
Output1
ISR
Client
F2
ISR
TASK
TASK
Output2
Initial Design
Added Later
1. TASK INDEPENDENCE — NO SET ORDER OF EXECUTION
2. PRIORITY-BASED TASK SCHEDULING
3. MANY INTER-TASK COMMUNICATION MECHANISMS
4. FLEXIBLE STRUCTURE (ADD NEW TASK EASILY — SEE ABOVE)
5. GOOD HANDLING OF ASYNCHRONOUS EVENTS
6. EASE OF ACHIEVING FAST RESPONSE TIMES
+ 7. OOP PARADIGM: (VERY IMPORTANT BENEFIT)
a. ENCAPSULATION:
— TCB’S & STACKS
— OTHER KERNEL OBJECTS ALSO HAVE CB'S
b. REUSE
c. REPLACEMENT (SEE ABOVE)
8. CLIENT/SERVER PARADIGM (GOOD DESIGN TECHNIQUE)
9. WELL-DEFINED INTERFACES BETWEEN FUNCTIONAL AREAS -
I.E. F1, F2, F3 (MESSAGES, SEMAPHORES, ETC.)
— GOOD FOR MULTI-PROGRAMMER PROJECTS
INTRO-5

NEW MINDSET NEEDED
N
Y
Not Superloop Not Sequential
MULTITASKING REQUIRES DIFFERENT THINKING:
1. PARALLEL NOT SEQUENTIAL
Rx
Tx
CHK
Data
ACK/NAK
Data
FLOW DIAGRAM
CONTROL == DATA
2. FLOW IS CONTROL
T 1
M X M T 2
Task Message Exchange
3. OBJECT-ORIENTATION
TASKS
MESSAGES
EXCHANGES
SEMAPHORES
QUEUES
INTRO-6

DIVIDE AND CONQUER
SYSTEM -> SUBSYSTEMS
1 2
3 4
4a
SUBSYSTEM
-> TASKS
4b
4d
4c
WORK DOWN FROM HIGH LEVEL
GREATER AND GREATER DEFINITION
DETAILING ONE SUBSYSTEM USUALLY HAS LITTLE IMPACT ON
ANOTHER
INCREMENTAL DESIGN, IMPLEMENTATION, AND TEST
USE SKELETON TASKS (E.G. 4a & 4b TO TEST 4d)
INTRO-7

SOIL ANALYSIS MACHINE (SAM)
wireless WAN antenna
GPS antenna
air-conditioned cab
soil samples
soil sampler
Soil
Analysis
Machine
(Soil)
Sample S+1
SAM Inside
Sample S
N K P PH
Fe
Chemical
Analyzers
Returneth
INTRO-8

SAM SPECIFICATION
BLOCK DIAGRAM
Fertilizer
Company
GPS
Receiver
Farmer
Soil
Sampler
Controller
Main
Computer
Wireless
WAN
Soil
Sample
Analyzers
Operator
Interface
File
I/O
PCMCIA
HD
Touchscreen
LCD
Keyboard
Inkjet
Color
Printer
FUNCTIONS
1. CONTROL GPS RECEIVER, REQUEST POSITION & TIME INFO
2. CONTROL SOIL SAMPLING MECHANISM
3. PERFORM SOIL ANALYSIS (N, K, P, Acidity, Fe)
4. PROVIDE TRACTOR DRIVER WITH INFORMATION & DIRECTIONS
5. ACCEPT TOUCHSCREEN COMMANDS FROM TRACTOR DRIVER
6. ACCEPT KEYBOARD INPUT
7. GENERATE GRAPHICAL & TEXT OUTPUT TO LCD
INTRO-9

SAM SPECIFICATION (CONT)
8. PREPARE NUTRIENT MAP
a. PRINT
b. STORE
c. TRANSMIT TO FARMER
9. CALCULATE FERTILIZER NEEDS
10. INTERACT WITH FERTILIZER COMPANY
a. SEND DATA (WEB SITE)
b. RECEIVE INSTRUCTIONS (JAVA VIRTUAL MACHINE (JVM))
11. CHECK & CALIBRATE SUBSYSTEMS
INTRO-10

SAM ARCHITECTURE
FLOW DIAGRAM
GPS
position
Where
slower/
1
2 faster
4
Speed sample GUI
Control
Soil
Sampler
sample
taken
tag #
1
Tagger
2 3
Sample
Correlator
Analyzer
bad sample
warning
tag #
Map
Maker
3
Disk
Store
4
Analyzer
Controls
Soil Analyzers
Iron
Acid 1
Phos 1
Pot 1
Nitro 1
1
Analyzer
Outputs
touch
screen
Opcon
kbd
1
Plotter
3
www.
tractor.
com
WAN
2
1
web
server
TCP/IP
browser
TASK DEFINITION CRITERIA
1. ASYNCHRONOUS FUNCTIONS (NOT THE ONLY CRITERIA!)
2. HIGHER LEVEL (PROCESS OUTPUTS OF MULTIPLE LOWER-
LEVEL TASKS)
3. FUNCTIONALLY DIFFERENT (FOSTER RE-USE &
REPLACEMENT)
4. SERVER (USUALLY MULTIPLE CLIENTS)
INTRO-11

WHAT SERVICES DOES A KERNEL PROVIDE?
1. TASK MANAGEMENT
2. INTERTASK COMMUNICATION (ITC)
3. MEMORY MANAGEMENT
4. INTERRUPT AND I/O MANAGEMENT
5. TIMING
6. ERROR MANAGEMENT
THESE WILL BE COVERED NEXT
SMX MANUALS
REFERENCE MANUAL — 100% DEFINITION OF SMX
USER'S GUIDE — TUTORIAL
QUICK START — INSTALLATION, GETTING STARTED,
APPLICATION DEVELOPMENT
TARGET GUIDE — CPU AND TOOL INFORMATION
INTRO-12

TASKS
1. NATURE OF TASKS
2. TASK STATES
3. TASK SCHEDULING
4. CREATING TASKS
5. STARTING TASKS
6. WHY HAVE DYNAMIC TASKS?
7. TASK PREEMPTION
8. BUMPING TASKS
9. BOUND VS. UNBOUND TASKS
10. TASK CONTROL FUNCTIONS
11. TASK FLAGS
12. LOCATE & DELETE
TASKS-1

NATURE OF TASKS
MORE PRECISE DEFINITION OF SOFTWARE TASK
A PORTION OF THE WORK, WHICH IS NOT CONFINED TO ONE
REPETITION
CONSISTS OF:
1. CODE — TYPICAL:
void atask_main(par)
{
// initialization code
while(1)
{
// main task code
}
}
2. STACK
REQUIRED FOR EVERY ACTIVE TASK
USUALLY ARE FAIRLY LARGE (500-10000 BYTES)
ALLOW FOR:
MAXIMUM NESTING OF FUNCTIONS (P, R, & AV) 1
MAXIMUM NESTING OF ISR’S (R & AV) 2
MAXIMUM LSR REQUIREMENT (P, R, & AV) 2
SPACE FOR RUN-STATE REGISTERS (INCLUDING
COPROCESSOR) WHEN TASK IS SUSPENDED
SPACE NEEDED BY DEBUGGER, IF DEBUGGING
1
P, R, & AV = PARAMETERS, REGISTERS SAVED, &
AUTOVARIABLES
2 ISR’S AND LSR’S SHARE CURRENT TASK’S STACK FOR
SPEED
TASKS-2

NATURE OF TASKS (CONT)
3. TASK CONTROL BLOCK (TCB)
fl
bl
flags TASK
priority
errnum
rv
sv
sfp
sp
ss
thisptr
fun
hook_entry
hook_exit
stp
sbp
ssz
shwm
ctxt
name
forward link
backward link
cbtype and flags
task priority
last error for task
return value
suspend value
stack frame pointer
stack pointer
stack segment (segmented versions only)
this pointer ( smx ++
)
function pointer
hooked entry routine pointer
hooked exit routine pointer
stack top pointer
stack bottom pointer
stack size
stack high-water mark
pointer to task context
task name
4. TIMER
FOR TASK TIMEOUT, WHENEVER IN WAIT STATE
NOTES
1. TCB AND TIMER ARE UNIQUE TO EACH TASK CREATED
2. STACK IS UNIQUE TO EACH ACTIVE TASK
3. CODE CAN BE SHARED BETWEEN TASKS
TASKS ARE OBJECTS, WHEREAS CODE IS JUST CODE.
TASKS-3

TASK STATES
A TASK MAY BE IN ONE OF FOUR STATES
RUN
create = create_task
del = delete_task
Start Here
preempt,
resume, start
dispatch
del
NULL
create
stop, suspend, sleep,
receive, test, count
READY
del
del
stop, suspend
start, resume, timeout, send, signal
WAIT
NULL
WAIT
READY
RUN
TASK NOT YET CREATED
WAITING FOR AN EVENT TO OCCUR
READY TO RUN. (IN THE READY QUEUE.)
ACTUALLY RUNNING. ONLY ONE TASK AT A TIME CAN
ACTUALLY RUN. IT IS THE “CURRENT TASK” (ct).
FROM OUTSIDE IT LOOKS LIKE ALL READY TASKS ARE RUNNING
AT ONCE.
TASKS-4

TASK SCHEDULING
SCHEDULING IS THE METHOD FOR DECIDING WHICH READY TASK TO
DISPATCH (I.E. RUN) NEXT
TYPES
ROUND ROBIN
TIMESLICING
PRIORITY TIMESLICING
PREEMPTIVE
ROUND ROBIN (AKA “COOPERATIVE”)
TASKS MUST BE ALTERED AS
SYSTEM CHANGES
NOT MUCH IMPROVEMENT OVER
A SUPERLOOP
C
B
A
task decides when
to release processor
C
too long
service
event
TIMESLICING
Fixed length
time slices
C
too long
APPROPRIATE FOR MULTI-USER
SYSTEMS (E.G. UNIX) —
CONCEPT OF “FAIRNESS”
C
B
fixed
order
NOT CONSISTENT WITH
EMBEDDED APPLICATIONS — ALL
EVENTS ARE NOT EQUAL
A
TASKS-5

TASK SCHEDULING (CONT)
PRIORITY TIMESLICING
top priority
C
better
INCREASES COMPLEXITY
EVEN THEN, WORST CASE
RESPONSE IS 1 TIMESLICE
A SMALL TIMESLICE RESULTS IN
EXCESSIVE TASK SWITCHING
USED BY Phar Lap ETS, WinCE,
WinNT
C
B
A
variable
order
PREEMPTIVE (smx)
PREEMPTION DUE TO:
HARDWARE INTERRUPT
smx CALL
MOST NATURAL METHOD
RESPONSIVENESS IS ASSURED
(ALMOST NO WAIT)
CAN TUNE SYSTEM BY
CHANGING PRIORITIES OF TASKS
EASY TO ADD, REMOVE, OR
CHANGE TASKS
USED BY MOST “HARD” REAL-
TIME KERNELS & RTOS'S
C
B
A
C
optimum
TASKS-6

TASK SCHEDULING (CONT)
READY QUEUE (RQ)
HOLDS TASKS WHICH ARE READY TO RUN
SEQUENTIAL READY QUEUE (NOT USED BY smx):
Task to
Enqueue:
2
Last task
to run
Ready Queue:
4 3 3 2
0
Next task
# = priority
to run
SEARCH AND SEARCH ... AND SEARCH
LAYERED READY QUEUE (smx) — MUCH FASTER:
TWO STEPS TO ENQUEUE A TASK:
1. INDEX TO PRIORITY LEVEL
2. PUT AT END OF LEVEL
4
4
3
3
3
2
index
2
2
enqueue
DOUBLY LINKED LIST
MAKES STEP 2 FAST
(USE BACKLINK FROM QCB)
1
#’s ARE PRIORITIES
0
0
QCB
TCB
TASKS-7

NOTES ON SMX FUNCTIONS
1. RETURN VALUE == 0 ==> FAILURE OR TIMEOUT
!= 0 ==> OK (USUALLY HANDLE OR TRUE)
2. MANY SMX FUNCTIONS RETURN “HANDLES”. THESE ARE
UNSIGNED INTEGERS (UINTS) WHICH IDENTIFY SMX
OBJECTS.
3. WHEN AN SMX OBJECT IS CREATED, ITS HANDLE IS USUALLY
STORED IN A STATIC/GLOBAL VARIABLE BEARING THE NAME
OF THE OBJECT.
TCB_PTR my_task;
my_task = create_task (...)
4. WE WILL SKIP OVER SELDOM-USED SMX FUNCTIONS
5. ALL CAPS ==> MACROS OR INLINE FUNCTIONS (e.g. LOCK(),
TCB_PTR)
6. MOST SMX FUNCTIONS ARE SSR’S (SYSTEM SERVICE
ROUTINES) WHICH ARE “ATOMIC”
7. SMX FUNCTIONS ARE ORTHOGONAL AND SYMMETRIC
A. "ORTHOGONAL" MEANS TASK STATE DOES NOT MATTER
B. "SYMMETRIC" MEANS THAT WHAT CAN BE DONE CAN BE
UNDONE
8. "near" & "far" ARE X86 SEGMENTATION CONCEPTS.
EVERYTHING IS "near" FOR 32-BIT FLAT PROCESSORS.
TASKS-8

CREATING TASKS
FUNCTION
atask = create_task (task_main, priority, stack_size)
DEFINITIONS
atask
task_main()
priority
stack_size
TCB_PTR atask;
[NEAR] POINTER WHICH STORES THE TASK HANDLE
IS THE CODE
0-127 (127 IS HIGHEST)
BYTES
USES
NOTES
CREATES A TASK
STATES: NULL —> WAIT
1. 0 PRIORITY IS RESERVED FOR IDLE TASK OR TIMESLICED
TASKS
2. FIRST-COME, FIRST SERVE IS OFTEN BEST BETWEEN TASKS
OF SIMILAR IMPORTANCE (e.g. SAM ANALYZER TASKS)
USUALLY ONLY A HALF A DOZEN PRIORITY LEVELS ARE
NECESSARY OR USEFUL
3. RECOMMEND NAMES, NOT NUMBERS:
enum priority = { MIN, LOW, NORM, HIGH, MAX }
4. EASY TO ADD PRIORITIES:
enum priority = { MIN, VLOW, LOW, NORM, MHIGH, HIGH, MAX }
5. stack_size == 0 TEMPORARY STACK WILL BE ASSIGNED
FROM STACK POOL WHEN TASK IS
DISPATCHED
!= 0 PERMANENT STACK IS ASSIGNED AT TIME
OF TASK CREATION
TASKS-9

STARTING TASKS
FUNCTIONS
startx (atask)
start_par (atask, par)
VARIABLES
atask
par
TASK HANDLE
UINT PARAMETER PASSED TO atask STARTUP CODE
USES
NOTES
START NEW TASKS
ABORT AND RESTART TASKS
1. MOVES A TASK TO THE END OF ITS PRIORITY LEVEL, IN rq,
AND STARTS IT OVER — IF IN RQ
2. STATES: WAIT, READY, RUN —> READY
3. ACCEPTING A PARAMETER
void atask_main(uint par)
{
do_something_with(par);
// ...
while(1)
{
}
}
TASKS-10

STARTING TASKS (CONT)
EXAMPLE: CREATE TWO TASKS, ONE OF WHICH PREEMPTS THE OTHER
void init(void)
{
TCB_PTR A, B;
A = create_task(A_main, NORM, 500);
B = create task(B_main, HIGH, 500);
startx(A);
}
Case I
void A_main(void)
{
unlockx(); // make preemptible
startx(B);
f1();
} !
void B_main(void)
{
f2();
} !
f2() RUNS BEFORE f1()
// both have permanent
// stacks
Case II
void A_main(void)
{
startx(B); // not preemptible
f1();
unlockx();
} !
void B_main(void)
{
f2();
} !
f1() RUNS BEFORE f2()
! BOTH TASKS AUTO-STOP (RUN —> WAIT)
TASKS-11

WHY HAVE DYNAMIC TASKS?
i.e. atask = create_task (...);
& delete_task (atask);
TASKS CONSUME RESOURCES
BETTER TO CREATE EXPLICITLY IN CODE — EASIER TO MODIFY IN
ONE PLACE THAN TWO (I.E. CODE AND TABLE)
DYNAMIC TASKS ARE NECESSARY FOR DLM’S, DLL’S, APPLETS, ETC.
WE ARE LIVING IN AN INCREASINGLY DYNAMIC WORLD
EXAMPLE: VARIABLE # OF COMM PORTS
PORTS
User Input
or
Autodetect
n = # PORTS
void comm_code (port)
{
}
// same for all ports
TCB_PTR comm_task[]; // array of task handles
comm_task = (TCB_PTR *) callocx(n, sizeof(TCB_PTR));
for (j = 0; j < n; j++) // n = # PORTS
{
comm_task[j] = create_task(comm_code, HI, 500);
start_par(comm_task[j], j);
}
// n = # PORTS
TASKS-12

TASK PREEMPTION
B (HIGH)
A (NORM)
B preempts* A
T 1 T 2
done
done
* DUE TO:
(1) HDW INTERRUPT
(2) SMX CALL FROM A
PROBLEMS WITH PREEMPTION:
NON-REENTRANT SHARED CODE
GLOBAL VARIABLES
NON-SHARABLE RESOURCES
smx TASKS START AS NON-PREEMPTIBLE
void atask_main (void)
{
// …
unlockx(self);
while(1)
{
// …
LOCK();
// …
unlockx(self);
// ..
}
}
nonpre
pre
nonpre
pre
Task can lock itself at any time
METHODS TO PREVENT TASK PREEMPTION PROBLEMS
1. LOCK CURRENT TASK (ABOVE)
2. PUT TASKS AT THE SAME PRIORITY LEVEL* (OFTEN
OVERLOOKED)
3. USE SEMAPHORE (AKA "MUTEX") (TRADITIONAL)
4. USE MESSAGE AS A TOKEN (NICE IF MSG HAS RESOURCE
INFO — I/O PORTS ETC.)
* if not timesliced
TASKS-13

TASK PREEMPTION (CONT)
MUST ALWAYS BE AWARE OF THE POSSIBILITY OF PREEMPTION — IT
CAUSES DIFFICULT BUGS TO FIND
NON-ATOMIC OPERATION:
F1();
F2();
preemption possible
by F3()
F1 sets variable
F2 uses variable
F3 changes variable
ATOMIC OPERATION:
LOCK();
F1();
F2();
unlockx();
F3();
preemption
not possible
SSR'S & LSR'S ARE ALSO ATOMIC:
void F12(void)
{
ENTER_SSR(id)
F1();
F2();
exit_ssr(value)
}
.......
.......
invoke(F12_lsr, par)
.......
.......
OR:
void F12_lsr(uint par)
{
F1();
F2();
}
TASKS-14

BUMPING TASK PRIORITIES
FUNCTION
USES
bump_task (atask, new_priority);
1. CHANGE PRIORITY OF ANOTHER TASK
#define cp ct->priority;
bump_task(atask, cp-1); // put atask 1 below ct priority (so it won't
// preempt)
2. BUMP CURRENT TASK TO THE END OF ITS LEVEL —
PRODUCES ROUND-ROBIN SCHEDULING
bump_task(ct); // moves ct to end of cp level
3. CHANGE CURRENT TASK’S PRIORITY LEVEL TO REFLECT THE
IMPORTANCE OF A SECTION OF CODE OR TO PREVENT
PREEMPTION
// PRI_F is highest priority of any task using F()
old_priority = cp;
bump_task(ct, PRI_F);
F(x);
bump_task(ct, old_priority);
ABOVE IS AN EXAMPLE OF SAME PRIORITY-LEVEL PREEMPTION
BLOCKING. IT IS A GOOD METHOD TO PREVENT PRIORITY
INVERSION.
TASKS-15

BOUND VS. UNBOUND TASKS
(Unique Feature)
1
T
S
CURRENT
TASK
temporary stack
START HERE
permanent stack
STOP
CREATE
TASK
(STACK =)
0
STOP
CREATE
POOL
T
S
1 2
WAIT
T
S
S
1
T
S
T
2
S
S
STACK
POOL
RESUME
START
START
S
permanent
stack
temporary
stack
S
1
T
S
READY
T
2
S
DISPATCH
RUN
1
2
100 tasks @ 1KB/stack = 100KB (not too big a deal in 32-bit systems)
1000 tasks @ 1KB/stack = 1MB
TASKS-16

TASK CONTROL FUNCTIONS
(BASIC TO ALL smx TASK SERVICES)
startx (atask)
STATE: WAIT, READY, RUN —> READY
RESTARTS atask IMMEDIATELY
USE TO START OR RESTART atask
STACK IS RELEASED UNLESS PERMANENTLY BOUND
STACK POINTER IS RESET IF PERMANENTLY BOUND
stop (atask, timeout)
STATE: WAIT, READY, RUN —> WAIT
TASK WILL RESTART AT TIMEOUT
USE TO ABORT atask
STACK IS RELEASED UNLESS PERMANENTLY BOUND
STACK POINTER IS RESET IF PERMANENTLY BOUND
resume (atask)
STATE: WAIT, READY, RUN —> READY
RESUMES A TASK FROM WHERE SUSPENDED OR PREEMPTED
RESTARTS TASK IF IT WAS STOPPED
USE TO RESUME
STACK HELD & STACK POINTER IS UNCHANGED
suspend (atask, timeout)
STATE: WAIT, READY, RUN —> WAIT
TASK WILL RESUME AT TIMEOUT
TASK WILL RESTART AT TIMEOUT IF IT WAS STOPPED
USE TO SUSPEND
STACK HELD & STACK POINTER IS UNCHANGED
TASKS-17

TASK CONTROL FUNCTIONS (CONT)
THE PRECEDING ILLUSTRATES:
ORTHOGONALITY: ANY OPERATION IN ANY STATE (EXCEPT NULL)
AND SYMMETRY
STOP SUSPEND
START
RESUME
ALL SMX FUNCTIONS WHICH AFFECT TASK STATES ARE BUILT
ON THIS BACKBONE
TASKS-18

TASK FLAGS
TASK CBTYPE:
1 F E L S B C H
F
E
L
S
B
C
H
STACK IS FAR
TASK IS IN EVENT QUEUE
TASK IS LOCKED
LOCK (task=ct)
unlockx (task=ct)
PERFORM STACK CHECKING
STACK_CHECK (ON/OFF, task=ct)
PERMANENTLY BOUND STACK
TASK IS USING COPROCESSOR
SAVE COPRO REGISTERS ON SUSPENSION
RESTORE COPRO REGISTERS ON RESUMPTION
copro (ON/OFF, task=ct)
TASK IS HOOKED
RUN EXIT ROUTINE ON SUSPENSION
RUN ENTRY ROUTINE ON RESUMPTION
hook (entry, exit, task=ct)
cPROC
cPROC
_entry
; entry routine code here
ret
_exit
; exit routine code here
ret
HOOKED ROUTINES ACT LIKE EXTENSIONS OF THE SHEDULER.
TASKS-19

TASK LOCATE & DELETE FUNCTIONS
queue = locate (atask)
RETURNS HANDLE OF QUEUE TASK IS IN, OR 0 IF NOT IN QUEUE
delete_task (atask)
RELEASES ALL BLOCKS, MESSAGES, AND TIMERS OWNED BY
atask
DELETES atask
RELEASES STACK BACK TO HEAP OR POOL
RELEASES TCB AND TIMER
CLEARS atask POINTER
STATES: WAIT, READY, RUN —> NULL
(NOTE: FOR A TASK TO DELETE ITSELF REQUIRES A
HELPER TASK smxKillTask WHICH IS PART OF
PROTOSYSTEM)
TASKS-20

INTERTASK COMMUNICATION (ITC)
1. ITC PURPOSE & MECHANISMS
2. EXCHANGES
3. EXAMPLE: MESSAGES TO SAM CORRELATOR TASK
4. MESSAGES
5. MESSAGE PRIORITY
6. TASK PRIORITY
7. MISC EXCHANGE & MESSAGE FUNCTIONS
8. EXAMPLE: MORE DETAIL ON SENDING AND RECEIVING
9. EXAMPLE: RECEIVE STOP
10. SEMAPHORES
11. EXAMPLE: MUTUAL EXCLUSION
12. EVENT QUEUES
13. COUNTING EVENTS
14. EVENT TABLES
15. EXAMPLE: ANALYZER GROUP
16. EXAMPLE: BETTER IMPLEMENTATION
ITC-1

ITC PURPOSE & MECHANISMS
PURPOSE
1. EXCHANGE DATA & CONTROL INFORMATION BETWEEN
TASKS
2. SYNCHRONIZATION OF TASKS
3. CONTROL OF TASKS
MECHANISMS PROVIDED BY SMX:
EXCHANGES
SEMAPHORES
AKA
“MAILBOXES”
“MUTEXES”
EVENT QUEUES
EVENT TABLES
PIPES
“EVENT GROUPS”
“QUEUES”
WITHOUT ITC NOTHING USEFUL CAN BE ACCOMPLISHED
(REFER BACK TO SAM FLOW DIAGRAM, INTRO-11)
MESSAGING IS ONE OF smx's STRONGEST FEATURES
ITC-2

EXCHANGES
PERMIT SENDING MESSAGES BETWEEN TASKS
send()
receive()
T 1
X T 2
T has sent M
1 1
T will receive it
2
M 1
EXCHANGES CAN ENQUEUE MESSAGES
T 1
X M 1 T 2
M 2
T 1 has sent 3 messages
T 2 has received the
first message
M 3
INTRODUCES FLEXIBILITY: T 1 & T 2 ARE NOT IN LOCKSTEP
MESSAGE QUEUE AT X IS T 2 ’s WORKSTREAM
EXCHANGES CAN RECEIVE MESSAGES FROM MANY TASKS
T 2
T 1
T 3
X T 4
T 1, T 2, & T 3 send messages
to X
T 4 receives them
T 4 is a server
EXCHANGES CAN ENQUEUE TASKS
T 2
T 1
T1 will receive M1
T2 will receive the next
message M2
M 2 T 3
M 1 X
ITC-3

EXCHANGES (CONT)
EXCHANGES PROVIDE ANONYMITY
T 2
T 1
X
T2 can be replaced by
a whole subsystem
OR
T 3
OR
T 4 T 5
T2 can be replaced by T3
at any time
ANONYMITY INCREASES TASK INDEPENDENCE
ITC-4

EXAMPLE: MESSAGES TO SAM CORRELATOR TASK
WHERE
TASK
WX
IRON
TASK
IX
CORRELATOR
TASK
SAMPLE XCHG
SAX
NITRO
TASK
NX
XCB_PTR WX, IX, ..., NX, SAX;
void where_main(void)
{
MCB_PTR wmsg;
// ...
while(1)
{
// ... prepare wmsg
sendx(wmsg, WX);
}
}
void iron_main(void)
{
MCB_PTR imsg;
// ...
while(1)
{
// ... prepare imsg
sendx(imsg, IX);
}
}
void correlator_main(void)
{
MCB_PTR wmsg, imsg, ..., nmsg;
MCB_PTR smsg;
// ...
while(1)
{
wmsg = receive(WX, TMO);
imsg = receive(IX, TMO);
...
nmsg = receive(NX, TMO);
// ... prepare smsg
sendx(smsg, SAX);
}
}
CORRELATOR WAITS FOR
SLOWEST MSG
ILLUSTRATES ACHIEVING
DESIRED FUNCTIONALITY VIA
STRUCTURE
ITC-5

MESSAGES
WHAT ARE MESSAGES?
MESSAGE CONTROL BLOCK (MCB)
priority
fl
bl
FMSG/NMSG
onr
mp
size
reply
rxchg
DATA
BLOCK
(ACTUAL
MSG)
DATA BLOCK — STORES ACTUAL MESSAGE. IT CAN BE ANY SIZE
WHERE DO THEY COME FROM?
MESSAGE POOL / RESOURCE EXCHANGE (RX)
T 1
receive()
(”empty”)
send()
(full)
RX
X
send()
(”empty”)
receive()
(full)
T 2
RX = create_xchga(CB_RXCHG);
pool = create_dpool(RX, num, size, dar_struc_ptr);
dar_struc_ptr
min_ptr
max_ptr
DAR structure
DAR
Dynamically
Allocated
Region
CREATES num MESSAGES OF size BYTES IN THE DAR
GETS num MCB'S AND ENQUEUES MSGS AT RX
UPDATES min_ptr
ITC-6

MESSAGES (CONT)
T1 CAN OBTAIN MESSAGES QUICKLY FROM RX
T2 MUST RETURN USED MESSAGES TO RX — DON'T FORGET!
HEAP
heap
T 1
X T 2
heap
void task1_main(void)
{
MCB_PTR msg;
while (...)
{
msg = create_hmsgf (NULL, size);
msg = create_hmsgn (NULL, size);
fill(msg);
sendx(msg, X);
}
}
void task2_main(void)
{
MCB_PTR msg;
while (msg = receive(X, TMO))
{
process(msg);
delete_hmsg (msg);
}
// perform error handling
}
// far heap or
// near heap
// TMO = timeout
ITC-7

MESSAGE PRIORITY
MULTI-MESSAGE-LEVEL EXCHANGES
receive()
X T 2
M 3
2
3
M 2 >= 3
0 T will receive M next, then M & M
M 1 0,1,2
2 2 1 3
p = priority
PERMITS MORE URGENT MESSAGES (E.G. KILL TUNE) TO
BYPASS LESS URGENT MESSAGES (E.G. NOTES)
EACH LEVEL CAN BE A SINGLE PRIORITY OR A RANGE OF
PRIORITIES
PASS EXCHANGE
Client Tasks
Server Task
receive()
PX T 3
p = priority
T 1
4
4
T 2
2 2
T
3
will receive M
1
next and
M 2
1, 2
assume priority level 4
M 1
>= 3
0
Each client task assigns
its own priority to the
messages it sends to PX: bump_msg(msg, cp);
SERVER TASK WILL RUN AT PRIORITY LEVEL OF CLIENT TASK
When T has M :
3 1
M 1
4
T 3
4
ITC-8

TASK PRIORITY EXCHANGES
MULTI-TASK-LEVEL EXCHANGES
T will receive M
3 1
T will receive M
1 2
>= 2
0, 1
2
T 3
0 1
T 1
T 2
T 4
M 1
X
T 5
M 2
MESSAGE IS A TOKEN WHICH CONTROLS ACCESS TO A
RESOURCE (ONE MESSAGE PER RESOURCE)
MESSAGE MAY BE EMPTY OR CONTAIN INFORMATION
PERTAINING TO THE RESOURCE
EXAMPLE:
i/o ports:
M1
out port #1
status port #1
out
status
Line
Printer
1
M2
out port #2
status port #2
out
status
Line
Printer
2
BY USING INFORMATION IN TOKEN MESSAGES, THE CODE IN
EACH TASK CAN BE IDENTICAL.
ITC-9

MISC EXCHANGE & MESSAGE FUNCTIONS
CREATE EXCHANGE X
XCB_PTR X ;
X = create_xchga (type, limp=0);
type = X NORMAL
RX RESOURCE
PX PASS
(0 ==> single level task & msg queues)
>= 0
priority base
limp 0
3
2
0
tasks (1 level)
messages (3 level)
X
>= 3
2
0,1
CLEAR X
clear_q(X);
RETURNS OR FREES MSGS & RESUMES TASKS
DELETE EXCHANGE
delete_xchg (X);
FIRST CLEARS MSG OR TASK QUEUE
RELEASES XCB
CLEARS X
MESSAGE OPERATIONS
bump_msg (msg, new_priority);
bump_msg (msg); // current priority
ITC-10

EXAMPLE: MORE DETAIL ON SENDING AND RECEIVING
USE A MESSAGE TEMPLATE
struct WHERE {
int tag; // sample #
int x; // position x
int y; // position y
};
WHERE SUBSYSTEM
RX
WM
pool
REFER TO ITC-5
RX
SM
pool
Tagger
tag_
sem
Where
WX
X
Correlator
SAX
X
WHERE TASK CODE
XCB_PTR WMpool, WX, SMpool, SAX;
void where_main(void)
{
int
x,y, sample=1;
MCB_PTR wmsg;
struct WHERE *w;
DAR_STRUC *free_RAM;
WMpool = create_xchga(CB_RXCHG);
WX = create_xchga(CB_NXCHG);
create_dpool(WMpool, MAX_SAMPLES, sizeof(struct WHERE), free_RAM);
// ...
while (test(tag_sem, TMO))
{
wmsg = receive(WMpool, TMO);
w = wmsg->mp; // assign template
w->tag = sample++;
gps(&x, &y); // get latest position
w->x = x;
w->y = y;
sendx(wmsg, WX);
}
}
ITC-11

EXAMPLE: MORE DETAIL ON SENDING AND RECEIVING (CONT)
CORRELATOR TASK CODE
struct SAMPLE {
int sampno;
int x;
int y;
int iron;
// ...
}
void correlator_main(void)
{
MCB_PTR wmsg, smsg;
struct WHERE * w;
struct SAMPLE * s;
//...
}
while (wmsg = receive(WX, TMO))
{
smsg = receive (SMpool, TMO);
w = wmsg->mp;
s = smsg->mp;
s->sampno = convert(w->tag);
s->x = w->x;
s->y = w->y;
sendx(wmsg, WMpool);
//...
sendx(smsg, SAX);
}
THE WHERE TASK MUST HAVE HIGH OR MAX PRIORITY FOR
POSITIONAL ACCURACY
CORRELATOR TASK CAN HAVE NORM OR LOW PRIORITY (WX, IX,
ETC. MSG QUEUES WILL MERELY GROW LONGER)
ITC-12

EXAMPLE: RECEIVE STOP
receive_stop()
STACK IS RELEASED IF TEMPORARY
TASK IS RESTARTED WHEN MESSAGE IS RECEIVED OR TIMEOUT
OCCURS
void init(void)
{
TCB_PTR atask;
}
atask = create_task(atask_init, HIGH, 0);
startx(atask);
...
void atask_init(void)
{
// task initialization
ct->fun = atask_main;
receive_stop(xchg, TMO);
}
void atask_main(MCB_PTR msg)
{
if msg
{
// process msg
receive_stop(xchg, TMO);
}
else
// process error
}
// reassign code pointer
// wait for first msg
// wait for next msg
ITC-13

SEMAPHORES
SIMILAR TO EXCHANGES BUT NO MESSAGES ARE USED
signalx()
test()
T 1
S(th) T 2
COUNTING SEMAPHORE
EACH SIGNAL INCREMENTS AN INTERNAL COUNTER, c
A TEST PASSES IF c >= th WHERE th IS THE THRESHOLD OF S.
THEN c = c - th
th == 1 IS USED FOR MUTUAL EXCLUSION (“MUTEX”)
th > 1 IS USED FOR COUNTING EVENTS
A SEMAPHORE CAN ACCUMULATE COUNTS ABOVE ITS THRESHOLD
SEMAPHORES CAN ENQUEUE TASKS
threshold
T 2
test()
T 1
test()
T
1
will be the first task resumed
T will be the next task resumed
2
T 3
signalx()
S(1)
MULTILEVEL TASK SEMAPHORES ARE SUPPORTED
>= 2
T 1
2
T 3
3
0, 1
T 2
0
T 4
signalx()
S(1)
Order resumed: T , T , T
1 3 2
ALLOWS HIGHER PRIORITY TASKS TO GAIN ACCESS TO
RESOURCES FIRST
ITC-14

EXAMPLE: MUTUAL EXCLUSION
void init(void)
{
SCB_PTR in_fct1;
}
in_fct1 = create_sema(1); // threshold = 1
signalx(in_fct1);
// prime semaphore for first use
// ...
startx(taskA);
startx(taskB);
void taskA_main(void)
{
// ...
test(in_fct1, TMO);
fct1(); //non-reentrant
signalx(in_fct1);
// ...
}
void taskB_main(void)
{
// ...
test(in_fct1, TMO);
fct1();
signalx(in_fct1);
// ...
}
taskB (HIGH)
preempt
test
fct1
taskB done
taskA (NORM)
fct1
fct1
signal
A SEMAPHORE IS MORE SPECIFIC THAN LOCKING A TASK
IT BLOCKS ONLY TASKS TRYING TO USE THE SAME RESOURCE
HOWEVER, OVERHEAD IS HIGHER — NOT GOOD FOR SHORT
SECTIONS OF CODE
ITC-15

EVENT QUEUES
COUNT THE NUMBER OF EVENTS SINCE A TASK BEGAN WAITING
signalx()
count()
T 1
EQ T 2
TASKS ARE ENQUEUED BY DIFFERENTIAL COUNT
count (6, EQ)
6
T 4
x
= count
T 1
T 1
EQ
EQ
total count =
T 2
3
5
y
3
8
T 2
T 3
3
T 4 T 3
3 2
= diff count
total count =
3
6 8
ONLY THE COUNT IN THE FIRST TASK IS DECREMENTED BY EQ FOR
EACH EVENT (SIGNAL)
EVENT QUEUES ARE MOST FREQUENTLY USED FOR PRECISE DELAYS:
void init(void)
{
ECB_PTR ticks;
ticks = create_eq(); // signaled each tick
// ...
}
void task_main(void)
{
// ...
while (count(5, ticks)); // runs every 5 ticks
{
// ...
}
}
ITC-16

COUNTING EVENTS
EVENT QUEUES MISS COUNTS IF NO TASK IS WAITING
T 1
signalx()
EQ
Count is lost
(No task counter present)
SEMAPHORES NEVER MISS COUNTS
T 1
signalx()
ctr
S
Counter keeps incrementing
EACH HAS ITS USES
EVENT QUEUE WOULD NOT BE APPROPRIATE FOR SOIL SAMPLE
TAGGER (SEE PAGE ITC-11)
EXAMPLE FOR EVENT QUEUE
void init(void)
{
ECB_PTR revs;
revs = create_eq(); // signaled each revolution
// ...
}
void rev_task_main(void)
{
start_wheel();
count(20, revs);
stop_wheel();
}
ANY REVOLUTIONS BEFORE WHEEL STARTED OR AFTER WHEEL
STOPPED ARE UNIMPORTANT
ITC-17

EVENT TABLES
ALLOW A TASK TO WAIT ON MULTIPLE EVENTS
set_flags()
flags
-
1
0 0 0
31
3
2
1
0
mask0
A
1 1
test_flags()
T 1
mask1
O
1
1
test_flags()
T 2 T 3
unused slot
SETTING FLAG 1 CAUSES ALL THREE TASKS TO RESUME
WIDTH IS 16 (15 FLAGS) FOR 16-BIT SYSTEMS
WIDTH IS 32 (31 FLAGS) FOR 32-BIT SYSTEMS
CREATE EVENT TABLE
et = create_et(num_slots);
SPACE IS ALLOCATED FROM THE [NEAR] HEAP
HENCE, EVENT TABLES CAN BE OF ARBITRARY SIZE
A TASK WAITS ON A SLOT
T1: test_flags(et, AND + 0xA, TMO); // mask0 = AND + 0xA
T2 & T3: test_flags(et, OR + 3, TMO); // mask1 = OR + 3
AND = 0x8000 16-BIT
= 0x80000000 32-BIT
OR = 0
ITC-18

EVENT TABLES (CONT)
TASKS WITH THE SAME MASK ARE ENQUEUED ON THE SAME SLOT
FLAGS MAY BE SET OR CLEARED INDIVIDUALLY OR IN GROUPS:
set_flags(et, 2); // set flag 1 in et
reset_flags(et, ALL); // ALL = 0xff...f
TEST_FLAGS RETURNS STATE OF FLAGS IN ET
int flags;
flags = test_flags(et, mask, TMO);
ITC-19

EXAMPLE: ANALYZER GROUP
#define NITRO 0x10 // 10000b
#define POT 0x08 // 01000b
// ...
#define IRON 0x01 // 00001b
void init(void)
{
ETCB_PTR analyzer;
analyzer = create_et(1);
// ...
}
// 1 slot
void nitro_main(void)
{
// ...
while (test(nitro_sem, TMO))
{
// ...
set_flags(analyzer, NITRO);
}
}
void correlator_main(void)
{
// ...
while (test_flags(analyzer, AND+NITRO+POT+PHOS+PH+IRON, TMO)
{
reset_flags(analyzer, ALL);
get_sample(NITRO);
signalx(nitro_sem); // to start next sample
get_sample(POT);
signalx(pot_sem);
// ...
}
}
FLAGS DO NOT AUTORESET
INTERLOCKING (E.G. nitro_sem) IS NECESSARY TO AVOID LOSING
EVENTS DUE TO SETTING AN ALREADY-SET FLAG
WORKS BUT IS CLUMSY IN THIS CASE
ITC-20

EXAMPLE: BETTER IMPLEMENTATION
TAGGER
WS
WHERE
TASK
WX
IS
IRON
TASK
IX
CORRELATOR
TASK
SAX
NS
NITRO
TASK
NX
while (test(_S))
receive(wx,...)
receive(ix,...)
NOTES
1. TAGGER ISSUES A BATCH OF SIGNALS
2. NO SIGNALS WILL BE LOST — EVEN IF AN ANALYZER FALLS
BEHIND
3. EACH ANALYZER WORKS AT ITS OWN RATE (NOTE HOW
TASKS MIMIC HARDWARE UNITS)
4. EXCHANGES STORE MESSAGES CONTAINING
MEASUREMENTS
5. CORRELATOR WILL WAIT FOR A LATE MESSAGE
ITC-21

EXAMPLE: BETTER IMPLEMENTATION (CONT)
6. DYNAMIC CONFIGURATION: SUPPOSE AN ANALYZER IS
MISSING?
a. TAGGER WOULD NOT SIGNAL ITS SEMAPHORE
b. INSTEAD, TAGGER WOULD SEND A DUMMY MESSAGE TO
ITS EXCHANGE
c. ANALYZER TASK WOULD NEVER RUN
7. PLUG IN DIFFERENT TAGGERS
switch (config)
{
case 1:
tagger = create_task(tagger1_main, ...);
case 2:
tagger = create_task(tagger2_main, ...);
}
8. IT IS GOOD TO MIMIC THE REAL WORLD
a. CODE IS EASIER TO UNDERSTAND
b. EASIER TO ADAPT TO DIFFERENT HARDWARE
CONFIGURATIONS
ITC-22

TASK PIPES
PERMIT SENDING CHARACTERS BETWEEN TASKS
pput_char()
pget_char()
T 1
P
T 2
EACH TASK RUNS AT ITS OWN RATE:
1. IF THE PIPE IS FULL, T1 WILL SUSPEND ON IT AND HOLD THE
CHAR UNTIL T2 REMOVES A CHAR FROM P
2. IF THE PIPE IS EMPTY, T2 WILL SUSPEND ON IT UNTIL T1
SUPPLIES A CHAR
PIPES ARE GOOD FOR SYNCHRONIZING TASKS WHICH NATURALLY
RUN AT DIFFERENT RATES
CREATE PIPE
apipe = (PXCB_PTR) create_cx(CB_PIPE);
// "cx" means char xchg
ASSIGN A BUFFER
put_msg(msg, size, apipe);
DELETE PIPE
delete_cx((CXCB_PTR &) apipe);
RELEASES BUFFER FIRST
void task1_main(void)
{
char ch;
// ...
do
{
// ... produce char
} while(pput_char(ch, apipe, TMO));
}
void task2_main(void)
{
int ch; // in to distinguish NUL from no char
// ...
while (ch = pget_char(apipe, TMO)
{
// ... process 0xff & ch
}
}
ITC-23

INTERNALS
1. WHAT ARE TASKS, MESSAGES, ETC?
2. READY QUEUE
INTERNALS-1

WHAT ARE TASKS, MESSAGES, ETC?
THEY ARE OBJECTS CONSISTING OF:
DATA
IN CONTROL BLOCKS
“HIDDEN” — USUALLY NOT NECESSARY TO ACCESS
DIRECTLY
CODE
SET OF SMX SERVICES ASSOCIATED WITH THE OBJECTS
(E.G. sendx() & receive() ARE ASSOCIATED WITH EXCHANGES)
VIEW APPLICATIONS AS A SET OF INTERACTING OBJECTS
HOW ARE QUEUES FORMED?
XCB 0
XCT
XCB X
MCB y
MCB z
fl
fl
fl
bl
bl
bl
XCB n
MCB 0
MCT
NOTHING MOVES
IT’S ALL SMOKE & MIRRORS!
MCB m
INTERNALS-2

READY QUEUE
qcb's:
tcb's:
4
rq_top
handle
ct
handle
3
3
3
2
(numbers are priorities)
1
1
1
rq
handle
0
0
INTERNALS-3

MEMORY MANAGEMENT
1. HEAPS
2. BLOCK POOLS
3. EXAMPLE: TASK CONTEXT INFO
4. FAST BLOCK POOLS
5. OTHER MEMORY MANAGEMENT
MEMORY-1

HEAPS
REPLACE COMPILER HEAPS
MACROS (AT COMPILE TIME)
TRANSLATION FUNCTIONS (AT LINK TIME)
SAME NAMES AS IN COMPILER RTL
ADVANTAGES OF smx HEAPS
ATOMIC FUNCTIONS (I.E. SSR’S)
BETTER PROTECTION
ATTEMPT TO MINIMIZE FRAGMENTATION
FUNCTIONS PROVIDED
dp = mallocx(size);
dp = callocx(num, size);
dp_new = reallocx(dp_old, size)
freex(dp);
status = heapchkx();
status = heapsetx(fill_char);
status = heapwalkx(hip); // heap info structure pointer
HEAP STRUCTURE AND INITIALIZATION
WHEN AN SMX HEAP IS FIRST INITIALIZED, IT CONSISTS OF
THREE BLOCKS:
cf._heap_min
_heap_srchp
onr
1
0
hcb 0
hcb 1
nbp
data
block 1
(free)
nbp
increasing
memory
cf._heap_max
1
hcb n
(each row is a full
control block)
MEMORY-2

HEAPS (CONT)
AFTER ALLOCATING A BLOCK:
onr
cf._heap_min
task handle
1
h
hcb 0
hcb 1
nbp
_heap_srchp
0
block 1
hcb 2
nbp
increasing
memory
block 2
(free)
nbp
cf._heap_max
1
hcb n
(each row is a full
control block)
TO SPEED ALLOCATION _heap_srchp ALWAYS POINTS AT OR
BELOW THE LOWEST FREE BLOCK
CONTROL BLOCK (32-BIT FLAT VERSIONS)
0x5555AAAA
nbp
onr
blocks are on 8 byte
boundaries
0x5555AAAA
16 bytes
ADVANTAGES OF HEAPS
EASY TO USE
CAN ALLOCATE THE EXACT AMOUNT OF MEMORY NEEDED EACH
TIME
MEMORY NOT USED UNTIL NEEDED
SMX HEAPS ARE SELF-INITIALIZING
DISADVANTAGES OF HEAPS
FRAGMENTATION — “GARBAGE COLLECTION” IS NOT PRACTICAL
IN HARD REAL-TIME SYSTEMS
MIXING OF CONTROL INFORMATION AND DATA IS HAZARDOUS
TO HEAP INTEGRITY
ALLOCATION CAN BE SLOW AND UNPREDICTABLE. THIS IMPACTS
PREEMPTION LATENCY
MEMORY-3

HEAPS (CONT)
DEALING WITH THE DISADVANTAGES
FRAGMENTATION
BLOCKS ARE MERGED WITH ADJACENT WHEN FREED
USE FOR ONE-TIME ALLOCATIONS (E.G. SMX USES FOR
CONTROL TABLES)
DEVELOP A HEAP MANAGEMENT STRATEGY. E.G.:
ALLOCATE STANDARD-SIZE BLOCKS (E.G. N * 64 -16)
APPLICATION-LEVEL GARBAGE COLLECTION
ALLOW FOR WORST-CASE SCENARIO
RETRY, DON’T DIE
MIXING OF CONTROL AND DATA
X86 SEGMENTED PROTECTED MODE FAR HEAP: EVERY
DATA BLOCK IS A SEPARATE SEGMENT
OTHERS: TEST HEAP FENCES BY WALKING HEAPS IN IDLE
TASK
SLOW ALLOCATION
AVOID mallocx() IN HIGH PRIORITY TASKS
MANAGE FRAGMENTATION
MEMORY-4

X86 SEGMENTED HEAPS
NEAR HEAP
FUNCTIONS: nmallocx(), nfreex(), etc
CAN BE CALLED DIRECTLY
NEAR HEAP CONTROL BLOCK
0x5555
nbp
onr
0x5555
8 bytes
blocks are on 8 byte
boundaries
MAY NOT EXCEED (64K - sizeof(all near variables)) FOR 16-BIT
SYSTEMS
FAR HEAP
FUNCTIONS: fmallocx(), ffreex(), etc
CAN BE CALLED DIRECTLY
FAR HEAP CONTROL BLOCK (16 BYTES)
0x5555
(spare)
nbp
blocks are on 16 byte
boundaries
pbp
onr
0x5555
16 bytes
MODEL-INDEPENDENT FUNCTIONS
EXAMPLE: mallocx() MAPS TO nmallocx() OR fmallocx()
DEFAULT TO:
NEAR HEAP FOR SMALL DATA MODELS (SMALL, MEDIUM,
AND FLAT)
FAR HEAP FOR LARGE DATA MODELS (COMPACT AND
LARGE)
MEMORY-5

X86 SEGMENTED HEAPS (CONT)
FREE BLOCK MERGING
nfreex() MERGES UPPER FREE BLOCK ONLY (no pbp)
nfreex()
free
used
nmallocx() MERGES FREE BLOCKS AS ENCOUNTERED
ffreex() MERGES UPPER & LOWER FREE BLOCKS
ffreex()
MEMORY-6

FIXED BLOCK POOLS
ADVANTAGES
FAST
PREDICTABLE
CONTROL INFORMATION AND DATA ARE SEPARATE
DISADVANTAGES
FIXED NUMBER AND SIZE OF BLOCKS
MUST PRE-ALLOCATE WHOLE POOL BEFORE NEEDED
CREATE POOL
FROM DYNAMICALLY ALLOCATED REGION
apool = create_dpool(NULL, bnum, bsize, dar_struc_ptr);
SAME AS CREATING MESSAGE POOL, EXCEPT NO RXCHG (NULL)
apool
pp
BPCB
pool pointer
DAR
pool
control
block
minh
srch
maxh
bsize
bnum
data block n
block
control
block
onr
ph
bp
pool handle
block pointer
NO delete_pool()
MEMORY-7

FIXED BLOCK POOLS (CONT)
FROM HEAP
pool = create_hpooln(num, size);
pool = create_hpoolf(num, size);
delete_hpool(pool);
// near heap
// far heap
GETTING AND RELEASING BLOCKS
USES
blk = get_block(pool);
rel_block(blk);
STACKS IN STACK POOL
SBCB
onr
si
sx
ss
owner handle
stack min
stack max
stack segment
16-bit only
BUFFERS
WORK AREAS — IN LIEU OF STACK SPACE
TASK CONTEXT INFO — E.G. I/O ADDRESSES
MEMORY-8

EXAMPLE: TASK CONTEXT INFO
TCB_PTR comm_task[NUM_PORTS];
PORT_INFO struct {
uint read_port;
uint write_port;
uint ctrl_port;
}
void init(void)
{
PORT_INFO cp;
BCB_PTR cb;
comm_blks = create_hpooln(NUM_PORTS, sizeof(struct PORT_INFO));
// from near heap
for (j = 0; j < NUM_PORTS; j++)
{
cb = get_block(comm_blks);
cp = cb->bp;
cp->read_port = COMM_BASE + 3j;
cp->write_port = COMM_BASE + 3j + 1;
cp->ctrl_port = COMM_BASE + 3j + 2;
comm_task[j] = create_task((CODE_PTR) comm_main, HIGH, 1000);
start_par(comm_task[j], cb);
}
// ...
}
void comm_main(BCB_PTR cb)
{
PORT_INFO cp;
cb->onr = ct; // reassign owner because initially onr = init task
cp = cb->bp;
while(1)
{
outp(cp->write_port, next_char);
// ...
}
}
delete_taskcomm_task[3]);
WILL AUTOMATICALLY RELEASE ITS PORT INFORMATION BLOCK
MEMORY-9

FAST BLOCK POOLS
ADVANTAGES OVER NORMAL BLOCK POOLS
FASTER
SIMPLER — NO PCB’S OR BCB’S
DISADVANTAGES
USES
LESS SAFETY
NO OWNER
NO POOL INFORMATION
AVAILABLE FOR NEAR BLOCKS, ONLY (SEGMENTED X86)
SMX — CONTROL BLOCKS
C++ — OBJECTS (OVERLOAD new AND delete OPERATORS)
APPLICATION — OBJECTS & CONTROL BLOCKS
OPERATIONS
free_ptr = create_fbpool(data_ptr, num, size);
data_ptr —> AVAILABLE MEMORY
bp = get_fblocks(VOID PTR & free_ptr, num, size, clr_sz);
GETS num CONTIGUOUS BLOCKS, IF POSSIBLE (SIZE MUST
BE SPECIFIED BECAUSE THERE IS NO PCB). CLEARS clr_sz
BYTES.
DEFAULTS: num = 1, and size is NOT NEEDED
sort_fblocks(free_ptr);
rel_fblock(bp, & free_ptr);
MEMORY-10

OTHER MEMORY MANAGEMENT
MESSAGE POOLS
SIMILAR TO BLOCK POOLS
MESSAGES EASILY TRANSFERRED BETWEEN TASKS
CAN BE USED FOR BUFFERS AND WORK AREAS, JUST LIKE
BLOCK POOLS
DISADVANTAGE — MORE OVERHEAD
SHARED GLOBAL VARIABLES
STACKS
SIMPLE AND FAST
RISKY DUE TO ACCESS CONFLICTS
WHILE ONE TASK IS USING, A HIGHER PRIORITY TASK CAN
PREEMPT AND CHANGE
DIFFICULT BUGS TO FIND
SHOULD USE SEMAPHORES AND OTHER PROTECTION
MECHANISMS
BEST TO USE MESSAGES AND OTHER SAFE METHODS
FROM:
STACK POOL — BOUND UNTIL TASK STOPPED
NEAR HEAP (ss == ds) — PERMANENTLY BOUND
FAR HEAP (ss != ds) — PERMANENTLY BOUND
MEMORY-11

OTHER MEMORY MANAGEMENT (CONT)
STACKS SHOULD BE USED EXTENSIVELY
REENTRANT ROUTINES:
void task1_main(void)
{
// …
call
f1();
// …
}
task1
Stack
use
void f1(void)
{
int x,y;
// …
}
use
call
void task2_main(void)
{
// …
f1();
// …
}
task2
Stack
y
x
...
y
x
...
TWO ACCESS METHODS:
1. AUTO VARIABLES (bp-i)
2. BEGINNING OF STACK BLOCK (ss:0) (16-BIT ONLY)
ss:0
+
sp
bp
(low address)
BUFFER
top of stack
AUTO VAR’S
stack direction
(high address)
MEMORY-12

INTERRUPTS & I/O
1. INTERRUPTS
2. EXAMPLE: STARTING A TASK DUE TO AN INTERRUPT
3. LSR OPERATION
4. I/O PIPES
5. EXAMPLE: KEYBOARD INPUT
6. BUCKETS
7. EXAMPLE: PACKETIZED DATA OUT
I/O-1

INTERRUPTS
OBJECTIVE: MINIMAL KERNEL INTERRUPT LATENCY
LATENCY = TIME FROM INTERRUPT —> ISR
LATENCIES ADD:
PROCESSOR + KERNEL + APPLICATION
APPLICATION = LONGEST ISR + BACKGROUND
EXCESSIVE LATENCIES CAUSE:
DATA OVER-RUNS
MISSED COUNTS
SLOW RESPONSES —> INSTABILITY
INTERMITTENT FAILURES — THE WORST KIND TO FIND
SMX WORST-CASE INTERRUPT LATENCY
14 PROCESSOR INSTRUCTIONS
104 CLOCKS = 5.2 MICROSEC ON 20 MHZ 386
COMPARABLE TO PROCESSOR LATENCY
TWO-LEVEL FOREGROUND STRUCTURE
1. ISR’S (INTERRUPT SERVICE ROUTINES)
MINIMAL CODE
CAN ONLY DO GET & PUT CHAR OP’S AND INVOKE LSR’S
2. LSR’S (LINK SERVICE ROUTINES) (INT ENABLED 100%)
CAN DO ALL SMX CALLS
BUT CANNOT WAIT
RUN IN THE CONTEXT OF THE CURRENT TASK (USE ITS STACK)
ACT LIKE FOREGROUND TASKS
VERY-LOW OVERHEAD
INTERRUPT
INVOKE() signalx() start()
ISR LSR TASK
TASK
FOREGROUND
BACKGROUND
I/O-2

EXAMPLE: STARTING A TASK FROM AN INTERRUPT
uint x = 0;
void INTERRUPT startA_isr(void)
{
ENTER_ISR();
x++;
// ...
INVOKE(startA_lsr, x); // puts into lq
EXIT_ISR();
// branches to lsr scheduler
}
void startA_lsr(uint pass_num)
{
start_par(taskA, pass_num);
}
void taskA_main(uint pass_num)
{
if(pass_num ...)
// ...
}
RULES FOR USING ISR'S & LSR’S:
1. ENTER_ISR & EXIT_ISR() MAY BE OMITTED ONLY IF:
a. INVOKE() IS NOT USED IN THE ISR, AND
b. ISR PRIORITY > THAT OF ANY ISR USING INVOKE()
2. DO NOT USE CT IN AN LSR
3. NO WAITS (I.E. TIMEOUT PARAMETER = NO_WAIT (= 0))
I/O-3

LSR OPERATION
preempt task1
srnest
0
1
2
3
4
task1
c
ssr1
i
invoke lsr1
ssr1 S lsr1 lsr1 S lsr2 S
c
isr1 isr1 r
ssr2 r
i
isr2 r
invoke lsr2
r
task2
c = smx call i = interrupt r = return S = scheduler
1. WHEN INVOKED, LSR IS PUT INTO LSR QUEUE (LQ) ONLY
2. THE LSR DOES NOT RUN UNTIL:
a. ALL NESTED ISR’S FINISH
b. AN INTERRUPTED SSR FINISHES
c. THE LSR SCHEDULER STARTS IT
3. LSR’S RUN IN FIFO ORDER
4. AFTER ALL INVOKED LSR’S HAVE RUN, A TASK WILL RUN
I/O-4

I/O PIPES
LSR TASK
(NO WAIT)
L 1
pput_char()
P
pget_char()
T 1
pput_char()
pget_char()
T 2
P
L 2
(NO WAIT)
WORKS LIKE TASK —> TASK EXCEPT LSR CANNOT WAIT ON
PIPE
LSR 1 MUST SAVE CHAR SOMEWHERE IF PIPE IS FULL
LSR 2 MUST ABORT IF PIPE IS EMPTY
ISR TASK/LSR (macros only)
PPUT_CHAR()
PGET_CHAR()
I 1
P
T/L
T/L 2 2
PPUT_CHAR()
P
PGET_CHAR()
1 1
I 2
PPUT_CHAR()
MACRO
WILL NOT SUSPEND ON FULL PIPE — RETURNS FALSE
PGET_CHAR()
MACRO
WILL NOT SUSPEND ON EMPTY PIPE — RETURNS 0
0X100 ADDED TO A VALID CHAR TO DISTINGUISH NUL FROM
NO CHAR
I/O-5

EXAMPLE: KEYBOARD INPUT
void init(void)
{
PCB_PTR kbd_pipe;
TCB_PTR opcon;
MCB_PTR pipe_buf;
pipe_buf = create_msg(NULL, 100);
kbd_pipe = (PXCB_PTR) create_cx(CB_PIPE);
put_msg(pipe_buf, 100, kbd_pipe);
opcon = create_task (opcon_main, LOW, 500);
startx(opcon);
}
void INTERRUPT kbd_isr(void)
{
byte ch;
ENTER_ISR();
ch = inp(KBD_PORT);
INVOKE(kbd_lsr, ch);
EXIT_ISR();
}
void kbd_lsr(byte ch)
{
pput_char(ch, kbd_pipe);
}
void opcon_main(void)
{
int ch;
// ...
while(ch = pget_char(kbd_pipe, TMO))
{
switch (ch & 0xFF)
// ...
}
}
I/O-6

I/O PIPES
ISR/LSR TASK (macros + ssr’s)
PPUT_CHAR()
P
pget_char()
T 1
INVOKE()
T 1
I 1
I 1
resume_pget()
pput_char()
P
L 1
PGET_CHAR()
L 1
INVOKE()
resume_pput()
ISR/LSR —> TASK:
ISR 1 PUTS CHARS IN PIPE RAPIDLY WITH PPUT_CHAR()
INVOKES LSR 1 TO WAKEUP THE TASK WITH resume_pget()
(DON’T USE pput_char(). COULD CAUSE SEQUENCING
ERROR)
TASK —> ISR/LSR:
TASK 2 PUTS CHARS IN PIPE WITH pput_char()
ISR 2 GETS CHARS RAPIDLY WITH PGET_CHAR()
INVOKES LSR 2 TO WAKEUP TASK 2 WITH resume_pput()
(DON’T USE pget_char(). COULD CAUSE SEQUENCING
ERROR)
I/O-7

EXAMPLE: SERIAL INPUT
void init(void)
{
PCB_PTR inpipe;
MCB_PTR pipe_buf;
TCB_PTR intask;
pipe_buf = create_msg(NULL, 100);
inpipe = (PXCB_PTR) create_cx(CB_PIPE);
put_msg(pipe_buf, 100, inpipe);
intask = create_task (intask_main, HI, 500);
startx(intask);
}
void INTERRUPT serial_isr(void)
{
byte ch; int count = 0;
ENTER_ISR();
while (inp(PORT_STATUS) & RXRDY)
{
ch = inp(PORT_DATA);
PPUT_CHAR(ch, inpipe);
if (count++ >= 20)
{
INVOKE(wakeup_lsr); /* ensure intask is awake, getting chars */
count = 0;
}
}
EXIT_ISR();
}
void wakeup_lsr(void)
{
resume_pget(inpipe); /* wakeup task waiting on inpipe, if any */
}
void intask_main(void)
{
int ch;
while(ch = pget_char(inpipe, TMO))
// ...
}
I/O-8

BUCKETS
CONVERT SERIAL STREAMS MESSAGE STREAMS
IN
PUT_CHAR()
RX
I 1
T 1
put_msg()
B
get_msg()
OR
send()
X
L 1
X
receive()
T 2
OR
put_msg()
B
L 2
GET_CHAR()
I 2
OUT
CREATE A BUCKET
bucket = (BXCB_PTR) create_cx(CB_BUCKET);
DELETE A BUCKET
delete_cx((CXCB_PTR &) bucket)
GOOD FOR HIGH SPEED PACKETIZED SERIAL I/O
I/O-9

EXAMPLE: PACKETIZED DATA OUT
void init(void)
{
BXCB_PTR out_bucket;
// bucket
SCB_PTR next_packet;
// semaphore
XCB_PTR free_packets;
// resource exchange
static struct DAR near ndar;
ndar.dnext = ADDR1;
// in near memory
ndar.dmax = ADDR2;
// in near memory
out_bucket = (BXCB_PTR) create_cx(CB_BUCKET);
next_packet = create_sema(1);
signalx(next_packet);
// prime semaphore
free_packets = create_xchg(CB_RXCHG);
create_dpool(free_packets, 2, 500, (DAR_PTR)&fdar);
}
void out_task_main(void)
{
MCB_PTR packet;
char first_char;
// ...
while(test(next_packet, TMO))
{
packet = receive(free_packets, TMO);
fill(packet);
put_msg(packet, 500, out_bucket);
outp(out_port, first_char); // start sending
}
}
void INTERRUPT out_isr(void)
{
int ch;
ENTER_ISR();
if (ch = GET_CHAR(out_bucket))
outp(out_port, ch);
else
INVOKE(out_lsr, 0);
EXIT_ISR();
}
void out_lsr(void)
{
MCB_PTR packet;
if (packet = get_msg(out_bucket))
sendx(packet, free_packets);
signalx(next_packet);
}
I/O-10

TIMING
1. TIMEOUTS
2. DELAYS
3. TIMERS
4. EXAMPLE: PERIODIC TESTS OF SOIL ANALYSIS
MACHINE
TIMING-1

TIMEOUTS
AVAILABLE IN ALL SMX CALLS CAUSING WAITS
CAN BE USED TO PREVENT “LOSING” TASKS
TRY TO SPECIFY A REASONABLE MAXIMUM WAIT TIME FOR
EACH OPERATION
while (msg = receive(xchg, 20));
{
// ... normal processing
}
if (!xerrno)
// deal with timeout
TIMEOUTS ARE SPECIFIED IN TICKS
receive (xchg, NO_WAIT);
receive (xchg, 20);
receive (xchg, INF);
// don’t wait
// wait 20 ticks
// wait forever
HOWEVER THE TIMEOUT TASK DETERMINES TIMEOUTS
IT MAY RUN ONLY ONCE PER SECOND, AND
IT CAN BE DELAYED BY HIGHER PRIORITY TASKS
TIMEOUTS ARE NOT INTENDED FOR PRECISE DELAYS
TIMEOUTS CAN BE UP TO 248 DAYS @ 100 Hz TICK RATE FOR 16-BIT
SYSTEMS
TIMING-2

DELAYS
LONG DELAYS
sleepx(stime + 3600); // 1 hour
stime IS KEPT IN SECONDS
TIME FROM LAST COLDSTART, IF NOT SET
IF SET, IS TIME FROM A SPECIFIC TIME (E.G. 00:00:00 GMT 1/1/80)
APPLICATION MUST SET
USEFUL FOR LONG TIME DELAYS AND REAL TIME OPERATIONS
1 SEC ACCURACY. DEPENDENT UPON TIMEOUT TASK
SLEEPS CAN BE OVER 100 YEARS IN 16-BIT SYSTEMS
PRECISE DELAYS
while (count(29, ticks, INF)) {
do_op(); }
EVENT QUEUES WERE PREVIOUSLY DISCUSSED
SHORT DELAYS
UP TO 10 MIN (100 Hz TICK RATE) FOR 16-BIT SYSTEMS
+0/-1 TICK ACCURACY
TICK RATE IS LIMITED BY OVERHEAD
TIMING-3

TIMERS
ARE DYNAMIC OBJECTS
TMCB
fl
bl
forward link
backward link
TMR
onr
interval
diff_count
lsr
par
owner handle
for cyclic operation
differential counter
lsr to invoke
parameter to lsr
tmrA = start_timer(lsr, par, t, i)
t i creates tmrA
0 0 no-op
0 i now + i, & i cyclic
t 0 now + t one-shot
t i now + t, & i cyclic
TMCB IS ENQUEUED IN TQ DIFFERENTIALLY:
TMR X
10
TQ TMR 1
TMR 2
TMR 3
5 3 9
total time = 5 8 17
TQ TMR 1
TMR 2
TMR X
TMR 3
5 3 2 7
total time =
5 8 10 17
TIMING-4

TIMERS (CONT)
FIRST TIMER IS DECREMENTED EVERY TICK (OR A
DIFFERENT PERIODIC INTERRUPT CAN BE USED)
LOW OVERHEAD
WHEN TIMER TIMES OUT:
THE LSR IS INVOKED WITH PARAMETER, PAR
IF ONE-SHOT, TIMER IS DELETED
IF CYCLIC, TIMER IS IMMEDIATELY PUT BACK IN TQ FOR i
TICKS
NO ACCUMULATION OF TIMING ERROR
TIMERS CAN BE READ WITHOUT DISTURBING
read_timer (tmrA, &time_left);
TIMERS CAN BE STOPPED
stop_timer (tmrA, &time_left);
LSR DOES NOT RUN
TIMER IS DELETED
TIMING-5

EXAMPLE: PERIODIC TESTS OF SOIL ANALYSIS MACHINE
void init(void)
{
static TMCB_PTR samtst1_tmr, samtst2_tmr, samtst3_tmr, ...;
samtst1_tmr = start_timer(samtst_lsr, ST1, 0, ONE_MIN);
samtst2_tmr = start_timer(samtst_lsr, ST2, 0, FIVE_MIN);
samtst3_tmr = start_timer(samtst_lsr, ST3, 0, ONE_HR);
// ...
}
void samtst_lsr(int testno)
{
switch (testno)
{
case ST1: startx(samtst1);
case ST2: startx(samtst2);
case ST3: startx(samtst3);
}
}
— OR —
case ST1: signalx(samtst1_sem);
case ST2: signalx(samtst2_sem);
case ST3: signalx(samtst3_sem);
FIRST EXAMPLE:
NON-PRE TASKS
ABORT TEST IF NOT DONE AND RESTART
SECOND EXAMPLE:
NORMAL TASKS
COMPLETE ALL TESTS
TIMING-6

ERROR MANAGEMENT
1. ERROR MANAGEMENT
2. EXAMPLE: ANALYZER FAILURE
ERROR-1

ERROR MANAGEMENT
WHY?
BUGS ARE INEVITABLE
MALFUNCTIONS AND FAILURES ARE UNAVOIDABLE
DAMAGE CONTROL IS ESSENTIAL
GOOD ERROR DETECTION HELPS DEBUGGING
SMX PROVIDES EXCELLENT ERROR DETECTION
WELL-DEFINED PATHS (E.G. SMX CALLS)
LIMITED NUMBER OF POSSIBILITIES
TESTING IS INDEPENDENT OF APPLICATION
MINIMAL IMPACT UPON CODE SIZE AND SPEED
OVER 70 ERROR TYPES MONITORED
ERROR HANDLING
POINT OF CALL
CENTRAL (BY ERROR TYPE)
BOTH ARE PROVIDED
if (result = smxcall(...))
// do op
else
// handle error or timeout
DISPLAY
SCREEN
task
code
ssr
code
jump table
esr 1
ERROR
BUFFER
smx call
point of
call error
handler
error
errno
minor:
continue
esr 2
std or
userwritten
++
major:
restart task
or reboot
ERROR
CTRS
ERROR-2

ERROR MANAGEMENT (CONT)
CENTRAL ERROR HANDLING — COMMON
LOG ERROR INFORMATION INTO ERROR BUFFER (EB)
KEEP COUNTS OF ERRORS — ERROR COUNTER PER ERROR
TYPE
OUTPUT ERROR MESSAGE
INVOKE USER-WRITTEN ERROR SERVICE ROUTINE
POC ERROR HANDLING — SPECIAL
RECOVERY VS. SEVERITY
MINOR — RETRY, ABORT, OR IGNORE (POINT OF CALL)
SERIOUS — ABORT & RESTART TASK(S) (ESR)
CATASTROPHIC — SHUT DOWN SYSTEM & RESTART, IF
POSSIBLE (ESR)
ERROR-3

EXAMPLE: ANALYZER FAILURE
void correlator_main(void)
{
XCB_PTR IX, EX;
MCB_PTR iron_msg, error_msg;
}
while(1)
{
// ...
if (iron_msg = receive(IX, ONE_SEC)
process(iron_msg);
else
{
error_msg = receive(EX, NO_WAIT);
load(error_msg, “NO IRON SAMPLE”);
sendx(error_msg, X911);
}
// ...
}
void alarm_mgr_main(void)
{
// ...
while (error_msg = receive(X911, INF))
process(error_msg);
}
ERROR-4

SUMMARY
BENEFITS OF MULTITASKING
REDUCE TIME TO MARKET
LESS CODE TO DEVELOP
LESS DEBUGGING
EXPLICIT RELATIONSHIPS — FLOW DIAGRAM
NOT BURIED IN CODE
RELIABILITY
EXPANSIBILITY
FLEXIBILITY
EASILY UNDERSTOOD
ALLOWS MULTIPLE PROGRAMMERS TO WORK WITHOUT
EXCESSIVE INTERACTION — WELL DEFINED INTERFACES
programmer 1 programmer 2
T 1
X
T 2
message with well-defined format
USE MANY TASKS, NOT JUST A FEW
SUMMARY-1

SUMMARY (CONT)
FLEXIBILITY
Valve
Test 1
2ms
Timer
lsr
Main
Task
M 1
X 1
Valve 1
Control
DAC1
V1
M 2
Valve 2
X 2
DAC2
Control
V2
Valve
Test 2
TIMER CAN BE STOPPED AND VALVE TEST STARTED TO
PERIODICALLY RUN THE VALVE THROUGH A TEST SEQUENCE TO
VERIFY THAT IT IS OK.
INSTEAD OF:
DAC1
V1
2ms
Timer
lsr
2ms
task
DAC2
V2
SUMMARY-2

SUMMARY (CONT)
WHY ARE TASKS BETTER THAN SUBROUTINES?
TRUE OBJECTS
RELATIONSHIPS ARE MORE FORMAL & EXPLICIT
— E.G. MESSAGES
BETTER ISOLATION
MORE INDEPENDENT — GOOD FOR MULTI-PROGRAMMER
PROJECTS
DYNAMIC INSTANTIATION & LINKING — GOOD FOR SELF-
CONFIGURATION, TESTING, ETC.
MUCH BETTER RUN-TIME ERROR CHECKING
IN SUMMARY
MULTITASKING PROVIDES OBJECT-ORIENTED PROGRAMMING,
LIKE C++, WITH LESS COMPLEXITY AND BETTER SUITABILITY TO
EMBEDDED SYSTEMS.
SUMMARY-3