2. • Real Time Systems
• Real Time Operating Systems & VxWorks
• Application Development
• LoadingApplications
• TestingApplications
10
4
3. • Real-time is the ability of the control
system to respond to any external or
internal events in a fast and
deterministic way.
• We say that a system is deterministic if
the response time is predictable.
10
5
4. • The lag time between the occurrence of
an event and the response to that event
is called latency
• Deterministic performance is key to
Real-time performance.
10
6
5. • High speed execution:
– Fast response
– Low overhead
• Deterministic operation:
– A late answer is a wrong answer.
10
7
7. • What is vxWorks ?
– vxWorks is a networked RTOS which
can also be used in distributed systems.
– vxWorks topics
• Hardware Environment Requirements
• Development tools
• Testing
10
9
8. • vxWorks runs on range of platforms
• MC680x0
• MC683xx
• Intel i960
• Intel i386
• R3000
• SPARC based systems
11
0
9. • Areal time OS is a operating system
which will help implement any real
time system
11
1
12. • One task controlling all the components is a
loop.
• arm ( )
{
for(;;)
{
if (shoulder needs moving)
moveShoulder( ) ;
if (elbow needs moving)
moveElbow( );
if (wrist need moving)
moveWrist( );
. . . .
}
}
11
4
13. • Create a separate task to manipulate each
joint:
joint ( )
{
for(;;)
{
wait; /* Until this joint needs moving */
moveJoint ( );
}
}
11
5
16. • Manages tasks.
• Transparently interleaves task execution,
creating the appearance of many programs
executing simultaneously and
independently.
11
8
17. • Uses Task Control Blocks (TCBs) to keep track of
tasks.
– One per task.
– WIND_TCB data structure defined in taskLib.h
– O.S. control information
• e.g. task priority,
• delay timer,
• I/O assignments for stdin, stdout, stderr
– CPU Context information
• PC, SP
, CPU registers,
• FPU registers FPU registers
11
9
18. • Task Context.
– Program thread (i.e) the task program counter
– All CPU registers
– Optionally floating point registers
– Stack dynamic variables and functionals calls
– I/O assignments for stdin, stdout and stderr
– Delay timer
– Timeslice timer
– Kernel control structures
– Signal handlers
– Memory address space is not saved in the context
12
0
19. • To schedule a new task to run, the kernel
must: :
– Save context of old executing task into
associated TCB.
– Restore context of next task to execute from
associated TCB.
• Complete context switch must be very fast
12
1
20. • Task Scheduling
– Pre-emptive priority based scheduling
– CPU is always alloted to the ―
ready to run‖
highest priority task
– Each task has priority numbered between 0 and
255
– It can be augmented with round robin scheduling.
12
2
21. • Work may have an inherent precedence.
• Precedence must be observed when allocating
CPU.
• Preemptive scheduler is based on priorities.
• Highest priority task ready to run (not pended
or delayed) is allocated to the CPU
12
3
22. • Reschedule can occur anytime, due to:
– Kernel calls.
– System clock tick
12
4
23. Task t1
Task t2 Task t2
Task t1
TIME
T3
COMPLET
ES
t2 completes
Task t3
t2 preempts t1
t3 preempts t2
•Priority
12
5
24. • To allow equal priority tasks to preempt
each other, time slicing must be turned on:
– kernelTimeSlice (ticks)
– If ticks is 0, time slicing turned off
• Priority scheduling always takes
precedence.
– Round-robin only applies to tasks of the same
priority..
12
6
25. doCommFunc ( int data)
{
……
}
• All task reside in a common address
space
Common Subroutine
tTaskA
TaskA() {
doComFunc(10)
}
tTaskB
TaskB() {
doComFunc(20)
}
10
TASK STACKS
20
12
7
28. • Controls many external components.
– Multitasking allows solution to mirror the
problem.
– Different tasks assigned to independent
functions.
– Inter task communications allows tasks to
cooperate.
13
0
29. • High speed execution
– Tasks are cheap (light-weight).
– Fast context switch reduces system overhead.
• Deterministic operations
– Preemptive priority scheduling assures
response for high priority tasks.
13
1
31. • Low level routines to create and manipulate
tasks are found in taskLib..
• AVxWorks task consists of:
– A stack (for local storage such as automatic
variables and parameters passed to routines).
– ATCB (for OS control).
13
3
32. • Code is not specific to a task.
– Code is downloaded before tasks are spawned.
– Several tasks can execute the same code (e.g.,
printf( ))
13
4
34. INT TASKSPAWN ( NAME , PRIORITY,
OPTIONS, STACKSIZE, ENTRYPT,
ARG1, … ARG10)
⦿ Task name
13
6
initial PC
– name
–priority⦿ Task priority (0-255)
–options⦿ Task Options eg VX_UNBREAKABLE size of stack
–stackSizeto be allocated Address of code to execute (
– entryPt
)
– arg1 … arg10Arguments to entry point routine.
35. • Assigned by kernel when task is created.
• Unique to each task.
• Efficient 32 bit handle for task.
• May be reused after task exits.
• If tid is zero, reference is to task making
call (self).
13
7
36. • Relevant taskLib routines:
– taskIdSelf( )
– taskIdListGet( )
– taskIdVerifty( )
Get ID of calling task
Fill array with Ids of all
existing tasks.
Verify a task ID is valid
13
8
37. • Provided for human convenience.
– Typically used only from the shell (during
development).
– Use task Ids programmatically.
• Should start with a t.
– Then shell can interpret it as a task name.
– Default is an ascending integer following a t.
13
9
38. • Doesn‘t have to be unique (but usually is).
• Relevant taskLib routines: routines:
– taskName( ) Get name from tid.
– taskNameToId( ) Get tid from task name.
14
0
39. • Range from 0 (highest) to 255 (lowest).
• No hard rules on how to set priorities.There
are two (often contradictory) ―
r
ules of
thumb‖:
– More important = higher priority.
– Shorter deadline = higher priority.
• Can manipulate priorities dynamically with:
– taskPriorityGet (tid, &priority)
– taskPrioritySet (tid, priority)
14
1
41. • Contrary to philosophy of system resources
sharable by all tasks.
• User must attend to. Can be expensive.
• TCB and stack are the only resources
automatically reclaimed.
14
4
42. • Tasks are responsible for cleaning up after
themselves.
– Deallocating memory.
– Releasing locks to system resources.
– Closing files which are open.
– Deleting child/client tasks when parent/server
exists.
14
5
43. taskRestart (tid)
• Task is terminated and respawned with
original arguments and tid.
• Usually used for error recovery.
14
6
44. taskSuspend (tid)
• Makes task ineligible to execute.
• Can be added to pended or delayed state.
taskResume (tid)
• Removes suspension.
• Usually used for debugging and
development
14
7
45. • Shared Memory
• Semaphores: Timeout and queues
mechanism can be specified
– Binary Semaphore
– Mutual Exclusion Semaphores
– Counting Semaphores
14
8
47. INT SEMTAKE (SEMID)
IF A TASK CALLS THIS
FUNCTION
15
0
– this function will return if the semaphore is not taken already
– this function will block if the semaphore is taken already
Int semGive (SEMID)
if a task call this function and
– there is a task which blocked that task will continue
– if there is no task blocked the semaphore is free
49. • Message Queues
– Any task including the interrupt handler can
send message to message queues.
– Any task can get message from message
queues(excl. interrupt context).
– Full duplex communications between 2 tasks
requires two message queues
– Timeout can be specified for reading writing
and urgency of message is selectable
15
2
50. • Message Queues
– MSG_Q_ID msgQCreate (maxMsgs,
maxMsgLength, Options )
– maxMsgs
• max number of messages in the queue.
– maxMsgLength
• max size of messages
– options
• MSG_Q_FIFO or MSG_Q_PRIORITY
15
3
51. • STATUS msgQSend (msgQId, buffer,
nBytes, timeout, priority)
• int msqQReceive (msgQId, buffer, nBytes,
timeout )
• STATUS msgQDelete (msgQId );
15
4
52. • Pipes
– Named I/O device
– Any task can read from/write to a PIPE
– an ISR can write to a PIPE
– select () can used on a pipe
• N/W Intertask Communication
– Sockets (BSD 4.3)
– RPC
15
5
54. • Interrupt Service routines
– They can bound to user C code through
intConnect.
– intConnect takes I_VEC, reference to ISR and
1 argument to ISR
15
7
55. • All ISR use a common stack verify through
checkStack()
• Interrupts have no task control block and
they do not run in a regular task context.
15
8
56. • ISR must not invoke functions that might
cause blocking of caller like
– semTake(), malloc(), free(), msgQRecv()
– No I/O through drivers
• floating point co-processors are also
discouraged as the floating point registers are
not saved or restored.
15
9
57. • Stores the discriptions of the exception in a
special location in memory.
• System is restarted
• In boot ROM the presence of the exception
description is tested, if present it prints it
out.
• For re displaying ‗e‘ command in the boot
ROM can be used.
16
0
58. • ‗errno‘is a global int defined as a macro in
―errno.h‖
• This return the last error status
• Default expection handler of the OS merely
suspends the task that caused it and displays
the saved state of the task in stdout
16
1
59. • ti and tt can be used to probe into the status
• Unix compatible signals() facility is used to
tackle exception other than that of the OS
16
2
60. • Mechanism that allows arbitary C functions
to be executed after specified delay
• function is executed as an ISR at the inrrupt
level of the system clock
• All restrictions of ISR applies
16
3
61. • Creation of a WD timer is through
wdCreate()
• Deletion of a WD timer through wdDelete()
• Start a WD timer through wdStart()
• Cancel a WD timer through wdCancel()
16
4
62. • Normally uses Internet protocol over
standard ethernet connections
• Transperency in access to other
vxWorks/Unix systems thro‘ Unix
compatible sockets
• Remote command execution
• Remote Login
16
5
65. • vxWorks routines are grouped into libraries
16
8
• Each library has corresponding include files
• Library
– taskLib
– memPartLib
– semLib
– lstLib
– sockLib
• Routine
– taskSpawn
– malloc
– semTake
– lstGet
– send
• Include files
– taskLib.h
– stdlib.h
– semLib.h
– lstLib.h
– types.h,
sockets.h,
sockLib.h
66. • Any workstation (could run Unix)
• OS should support networking
• Cross/Remote Development Software
• Unix platform
– Edit, Compile, Link programmes
– Debug using vxWorks Shell or gdb
16
9
67. • Any H/W which is supported by vxWorks.
• Could be Custom Hardware also.
• Individual object code (.o files)
downloaded dynamically.
• Finished application could be burnt into
ROM or PROM or EPROM.
17
0
68. • Global system symbol table
• Dynamic loading and unloading of object
modules
• Runtime relocation and linking.
17
1
69. • Asingle copy of code executed by multiple
tasks is called shared code
• Dynamic linking provides a direct
advantage
• Dynamic stack variables provide inherent
reentrancy. Each task has ints own task. Eg
linked list in lstLib
17
2
70. • Global and static variables that are
inherently non-reentrant, mutual exclusion
is provided through use of semaphores eg.
semLib and memLib
• Task variables are context specific to the
calling task. 4 byte task vars are added to
the task‘s context as required by the task.
17
3
71. • Command Line interpreter allows execution
of C language expressions and vxWorks
functions and already loaded functions
• Symbolic evaluations of variables
17
4
72. • Commands
-> lkup ( ―stuff‖)
stuff 0x023ebfffe bss
value = 0 = 0x0
-> lkup(―Help‖)
17
6
_netHelp 0x02021a90
_objHelp 0x02042fa0
text
text
value = 0 = 0x0
73. • Commands
* sp creates a task with default options
* td deletes a task
* ts/tr Suspend/resume a task
* b set/display break points
* s single step a task
* c continue a task
* tt Trace a tasks stack
* i/ti give (detailed) task information
* ld load a module
* unld unload a module
17
7
74. • Commands
* period
* repeat
* cd (―/u/team3‖); the quotes are required
* ll shows directory contents
* ls() same as ll
17
8
75. • Commands
Shell redirection
-> < script
shell will use the input as from the file
-> testfunc() > testOutput
shell will execute the function and the
output will be stored in a file
―testOutput‖
17
9
76. • vxWorks provides Source level debugging
• Symbolic disassembler
• Symbolic C subroutine traceback
• Task specific break points
• Single Stepping
• System Status displays
18
0
77. • Exception handlers in hardware
• User routine invocations
• Create and examine variable symbolically
18
1
78. • Shell based debugging commands
*b funcName() will set a break point in
the beginning of the function
funcName()
*b 0xb08909f will set a break point at
the address 0xb08909f
*bd funcName() will delete the breakpoint
at the beginning of the function
funcName()
* l will disassemble the code
18
2
79. • tUsrRoot
– 1st task to be executed by the kernel
• File: usrConfig.c
• Spawns tShell, tLogTask, tExecTask, tNetTask and
tRlogind
• tShell
– TheApplication development support task
18
3
81. • tRlogind
– Rlogin support for vxWorks. Supports remote
user tty interface through terminal driver
• tPortmapd
– RPC Server support
• rRdbTask
– RPC server support for remote source level
debugging.
185
82. • Unix
– except QNX, most unices don‘t live up to the
expectation of Real Time situations
– Present day unix kernel scheduler do support
Realtime requirements
– So Unix kernel can prioritize realtime processes
– a flag to indicate a RT process is often provided
to this effect
18
6
83. • vxWorks does not provide resource
reclamation
– Deviation: user must write their own routine
when need.
• vxWorks has a smaller context switch and
restore
– Hence time taken to change context is much
smaller.
18
7
84. • vxWorks requires special care to be taken
when writing multitasking code
– Semaphore are used to achieve reentrancy
• vxWorks has a minimal interrupt latency
18
8
85. • vxWorks execute threads in a flat memory
architechure as part of OS
• vxWorks has no processes. The so-called
tasks are actually threads
• vxWorks scheduling could be on round-
robin time slicing or pre-emptive scheduling
with priorities.
18
9
86. • vxWorks networking is completely Unix
compatible. Portable to BSD4.2/4.3 Unix
supporting TCP/IP
• vxWorks support BSD sockets
• vxWorks does not distinguish between kernal
mode and user mode execution
– Hence minimal mode change overhead on a give
hardware
• vxWorks has Virtual memory model
19
0
87. • vxWorks is not ―
R
ealtime Unix‖ OS or even
a variant of Unix
• vxWorks and Unix enjoy a symbiotic
relationship
• vxWorks can use Unix as application
development platform
191
