Top Banner

Click here to load reader

of 54

Tornado and VxWorks. Copyright © Wind River Systems, Inc.2 Tornado-VxWorks Architecture The Real-Time, Multitasking OS Intertask Synchronization and Communication

Apr 01, 2015

ReportDownload

Documents

  • Slide 1

Tornado and VxWorks Slide 2 Copyright Wind River Systems, Inc.2 Tornado-VxWorks Architecture The Real-Time, Multitasking OS Intertask Synchronization and Communication The Project Facility The Debugging Tools The Networking Stack Tornado and VxWorks Slide 3 Copyright Wind River Systems, Inc.3 What is Tornado? Real-Time, Multitasking OS Development and Debugging Tools Networking Slide 4 Copyright Wind River Systems, Inc.4 Tornado Architecture - HW Target The tools, registry, and target server can run on different hosts VxWorks Target Agent Tool Host Target Server Registry Slide 5 Copyright Wind River Systems, Inc.5 Tornado Architecture - Simulator Target VxWorks runs as a process under the host OS The simulator architecture provides no emulation of instruction, native compilers are used Registry Target Server VxWorks Target Agent Tool Host Tool Slide 6 Copyright Wind River Systems, Inc.6 Tornado Architecture The Real-Time, Multitasking OS Intertask Synchronization and Communication The Project Facility The Debugging Tools The Networking Stack Tornado and VxWorks Slide 7 Copyright Wind River Systems, Inc.7 What is a Task? A task is a Kernel object dynamically created at runtime Logical entity consisting of a Task Control Block (TCB) data structure and stack space An independent thread of execution A task is not a function However, a special purpose function (typically designed with an endless loop) is used for the tasks entry point Functions execute within the context of tasks The VxWorks routine taskSpawn() invokes the entry point function foo and gives the task its thread of liveness foo() { for (;;) { waitForData( );/* Until external event occurs */ processData( ); } } Slide 8 Copyright Wind River Systems, Inc.8 Creating a Task Slide 9 Copyright Wind River Systems, Inc.9 Multitasking Separate tasks are created to perform different system requirements For example, data acquisition and data computation Each task alternates between ready and waiting A task manager (the multitasking kernel) is therefore required VxWorks allows a task to wait for A specified time delay (Delay) An event such as an interrupt (Pend) Slide 10 Copyright Wind River Systems, Inc.10 Task States Slide 11 Copyright Wind River Systems, Inc.11 Multitasking Kernel The wind kernel is that part of VxWorks which directly manages tasks It allocates the CPU to tasks according to the VxWorks scheduling algorithm It uses Task Control Blocks (TCBs) to keep track of tasks One per task Declared as WIND_TCB data structure in taskLib.h O.S. control information state, task priority, delay timer,breakpoint list, error status,I/O redirections CPU Context Information PC, SP, CPU registers, FPU registers Slide 12 Copyright Wind River Systems, Inc.12 Kernel Operation Scheduler Slide 13 Copyright Wind River Systems, Inc.13 Multitasking Facilities Slide 14 Copyright Wind River Systems, Inc.14 Tornado-VxWorks Architecture The Real-Time, Multitasking OS Intertask Synchronization and Communication The Project Facility The Debugging Tools The Networking Stack Tornado and VxWorks Slide 15 Copyright Wind River Systems, Inc.15 Intertask synchronization In a multitasking environment, facilities to achieve mutual synchronization are needed Producer-consumer architecture Client-server architecture In VxWorks, intertask synchronization is achieved using Binary Semaphores Message Queues Events Pipes Some intertask synchronization facilities (queues and pipes) also enable data transmission (intertask communication) Slide 16 Copyright Wind River Systems, Inc.16 Binary Semaphores Binary semaphores exist in one of two states Full (synchronizing event has occurred) Empty (synchronizing event has not occurred) Intertask synchronization is obtained by creating an empty, binary semaphore for the synchronizing event The task waiting for the event calls semTake( ) and blocks until the semaphore is given The task or interrupt service routine detecting the event calls semGive( ), which unblocks the waiting task Slide 17 Copyright Wind River Systems, Inc.17 Message Queues Message queues are kernel objects used for passing information between tasks Message queues provide a FIFO buffer of messages The task waiting for the synchronization message calls msgQueueReceive( ) and blocks until a message is on the queue The task sending the synchronization message calls msgQueueSend( ), which unblocks a pending task Task ATask B Slide 18 Copyright Wind River Systems, Inc.18 Pipes Pipes provide an alternative interface to the message queue facility in the VxWorks I/O system Tasks block When they read from an empty pipe, until data is available When they write to a full pipe, until there is space available Similar to their use of message queues, interrupt service routines can write to a pipe, but cannot read from it Slide 19 Copyright Wind River Systems, Inc.19 Events VxWorks events are means of synchronization between Tasks and tasks Interrupt service routines and tasks VxWorks objects (binary semaphores and message queues) and tasks Only tasks can receive events, whereas tasks, interrupt service routines or VxWorks objects can send events Events are synchronous in nature The receiving task pends while waiting for the events to be sent Events allow a task to wait simultaneously on multiple resources For example, events can be sent by semaphores, message queues and other tasks Slide 20 Copyright Wind River Systems, Inc.20 Mutual Exclusion Semaphores Mutually exclusive access to shared resources is provided in VxWorks by mutual-exclusion semaphores (mutexes) VxWorks mutexes are designed to address issues inherent to mutual exclusion, like Priority inversion Deletion safety Recursive access to the shared resource Semaphore ownership Each critical section of the code has to be protected with mutexes, by having a task Take the mutex before accessing the code Give the mutex after having accessed it Slide 21 Copyright Wind River Systems, Inc.21 Counting Semaphores Counting semaphores are similar to binary semaphores, except that they keep track of the number of times the semaphore is given or taken Every time the semaphore is given, the count is incremented Every time the semaphore is taken, the count is decremented When the count reaches zero, a task that tries to take the semaphore is blocked Counting semaphores are useful for guarding multiple copies of resources Slide 22 Copyright Wind River Systems, Inc.22 Signals Signals asynchronously alter the control flow of a task An interrupt service routine or a task can send a signal to a task The task which has received the signal will asynchronously execute a signal handler The signal handler executes in the receiving tasks context and makes use of the tasks stack If no signal handler is installed, the received signal is ignored Since signals are asynchronous in nature, they are more appropriate for error and exception handling than as a general-purpose intertask communication mechanism Slide 23 Copyright Wind River Systems, Inc.23 Tornado-VxWorks Architecture The Real-Time, Multitasking OS Intertask Synchronization and Communication The Project Facility The Debugging Tools The Networking Stack Tornado and VxWorks Slide 24 Copyright Wind River Systems, Inc.24 Projects The project facility allows one to manage two project types Bootable projects To configure and build a VxWorks image Downloadable projects To build and download application modules to a running target Projects can be grouped together in Workspaces For each project more than one build specification can be used Slide 25 Copyright Wind River Systems, Inc.25 Bootable projects Bootable projects are used to create a new, customized VxWorks image The system image consists of all desired system modules linked together in a single, non-relocatable object module with no unresolved external references The image can be customized by adding or removing VxWorks components from the Workspace GUI A bootable project is created specifying A BSP A toolchain (GNU or Diab) Slide 26 Copyright Wind River Systems, Inc.26 Downloadable Projects Downloadable projects are used to create relocatable object modules that can be downloaded and dynamically linked to VxWorks Module downloading and dynamic linking is performed by the Target Server, which maintains a host-resident targets symbol table Downloadable projects Are created by specifying a toolchain GNU or Diab Allow on the fly development Modules can iteratively be downloaded, tested and debugged without rebooting the target system Slide 27 Copyright Wind River Systems, Inc.27 Project Facility Workspace Window 3 Workspace window views Slide 28 Copyright Wind River Systems, Inc.28 Tornado-VxWorks Architecture The Real-Time, Multitasking OS Intertask Synchronization and Communication The Project Facility The Debugging Tools The Networking Stack Tornado and VxWorks Slide 29 Copyright Wind River Systems, Inc.29 Host-Resident Debugging Tools WindShell Command Shell Provides command-line based, interactive access to all run-time facilities Browser System-object viewer, graphical companion to WindShell CrossWind Debugger Remote source-level debugger Extended version of the GNU source-level debugger (GDB) WindView Software Logical Analyzer Dynamic visualization tool Slide 30 Copyright Wind River Systems, Inc.30 WindShell WindShell allows one to Access all VxWorks facilities by allowing calls to any VxWorks routines For example, Spawning tasks Creating VxWorks objects like semaphores, message queues, and pipes Download object modules to the target system Perform assembly-level debugging Create and examine variables symbolically Examine and modify memory Slide 31 Copyright Wind River Systems, Inc.31 WindShell Slide 32 Copyright Wind River Systems, Inc.32 Browser The browser monitors the state of a target It shows detailed information on Tasks VxWorks objects (semaphores, messa