This document provides an overview of real-time operating systems and VxWorks. It discusses key concepts such as real-time performance, deterministic execution, multitasking, task scheduling and inter-task communication methods. VxWorks is introduced as a real-time OS that supports multitasking, priorities, interrupts and inter-task communication using mechanisms like shared memory, semaphores and message queues. The document also covers task management functions and interrupt handling in VxWorks.

1. 10
3

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

6. Memory
Mgmt
Device
Drivers
10
8
Network
Stack
Kernel

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

10. • Multitasking
• Intertask communications
• Deterministic response
• Fast Response
• Low Interrupt Latency
11
2

11. • SampleApplication
11
3

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

14. • Task State Transition
Pending Ready Delayed
Suspended
11
6
taskInit()

15. 11
7

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

26. text
data
bss
RAM
tTaskA
fooSet(10)
fooSet(10)
tTaskB
fooLib
int fooV
al;
void fooSet(int x)
{
fooVal = x;
}
12
8

27. • All tasks run in privileged mode
12
9

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

30. 13
2

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

33. TASKSPA
WN
Stack TCB
foo ( )
{
….
}
13
5

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

40. taskDelete (tid)
• Deletes the specified task.
• Deallocates the TCB and stack.
14
2

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

46. foo.h
extern char buffer[512];
extern int fooSet();
extern char *fooGet();
149
foo.c
#include foo.h
char buffer[512];
fooSet
{
}
fooGet()
{
}
taskA()
{
…
fooSet();
….
}
taskB()
{
…
fooGet()
…
}

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

48. taskA taskB
Semaphore
Time
15
1

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

53. • Interrupt handling Capabilities
• Watchdog Timer
• Memory management
15
6

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

63. • Remote Procedure calls
• Remote debugging
• Remote File access
• ProxyARP
16
6

64. Development Host
TARGET
PLATFORM
16
7
Ethernet LAN
RS-232

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

80. • tLogTask
– Log message hander task
• tNetTask
– Network support task
• tTelnetd
– Telenet Support task
18
4

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