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

Tornado and VxWorks

Copyright © Wind River Systems, Inc. 2

Tornado-VxWorks ArchitectureTornado-VxWorks ArchitectureThe Real-Time, Multitasking OSIntertask Synchronization and CommunicationThe Project FacilityThe Debugging ToolsThe Networking Stack

Tornado and VxWorks


What is Tornado?

Real-Time,

Multitasking

OS

Development and Debugging

Tools

Networking


Tornado Architecture - HW Target

The tools, registry, and target server can run on different hosts

VxWorks

Target Agent

Tool

Tool

Tool

Host Target

Target

Server

Registry


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

Tool


Tornado ArchitectureThe Real-Time, Multitasking OSThe Real-Time, Multitasking OSIntertask Synchronization and CommunicationThe Project FacilityThe Debugging ToolsThe Networking Stack

Tornado and VxWorks


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 task’s entry point

• Functions execute within the context of tasks • The VxWorks routine taskSpawn() invokes the entry point function foo

and gives the task it’s thread of “liveness”

foo(){

for (;;){waitForData( );/* Until external event occurs */processData( );}

}


Creating a Task


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)


Task States


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


Kernel Operation

Scheduler


Multitasking Facilities


Tornado-VxWorks ArchitectureThe Real-Time, Multitasking OSIntertask Synchronization and CommunicationIntertask Synchronization and CommunicationThe Project FacilityThe Debugging ToolsThe Networking Stack

Tornado and VxWorks


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)


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


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 A Task B


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


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


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


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


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 task’s context and makes use of the task’s 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


Tornado-VxWorks ArchitectureThe Real-Time, Multitasking OSIntertask Synchronization and CommunicationThe Project FacilityThe Project FacilityThe Debugging ToolsThe Networking Stack

Tornado and VxWorks


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


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)


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 target’s 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


Project Facility Workspace Window 3 Workspace window views


Tornado-VxWorks ArchitectureThe Real-Time, Multitasking OSIntertask Synchronization and CommunicationThe Project FacilityThe Debugging ToolsThe Debugging ToolsThe Networking Stack

Tornado and VxWorks


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


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


WindShell


Browser

The browser monitors the state of a target It shows detailed information on

• Tasks • VxWorks objects (semaphores, message queues, ...)• Stack usage by all task on the target• Target CPU usage by task• Object-module structure and symbols• Interrupt vectors

The displays are snapshots, which can be updated interactively• Alternatively, the Browser can be configured to automatically

update its display at specified intervals


Browser


CrossWind

CrossWind is a source level, graphical, debugging front-end using an enhanced version of GDB as its debugging engine

It allows two debugging strategies• Task mode debugging

– One task runs under debug control, while other tasks are not affected

– CrossWind can either› Attach to a running task, or› Start a new task under debugger control

• System mode debugging– Whenever a task hits a breakpoint, the whole system stops– This is useful to debug tasks, interrupt service routines and

pre-kernel execution


CrossWind


WindView 2.2

WindView allows one to study dynamic interactions of all the elements of complex, real-time systems


WindView 2.2

The WindView graph provides manageable access to important application information

WindView allows• Scrolling the information forward and backward in time

• Zooming in/out

• Tailoring the display to only focus on the tasks and events of interest

• Setting locks on certain events and searching for their successive occurrences


WindView 2.2 Example


Problem Solving with WindView 2.2

WindView allows to• Detect race conditions, deadlocks, CPU starvation and other

problems related to task interaction

• Determine application responsiveness and performance

• See cyclic patterns in application behavior

• Conduct post-mortem analysis of failed systems

• Detect memory leaks


Tornado-VxWorks ArchitectureThe Real-Time, Multitasking OSIntertask Synchronization and CommunicationThe Project FacilityThe Debugging ToolsThe Networking StackThe Networking Stack

Tornado and VxWorks


VxWorks Network Components

IP

TCP UDP

Socketszbuf

Shared MemoryNetwork

PPPEthernet

MUX

ftp rsh telnet

Target server NFS

rlogin

netDrv

RPC

Application layer

Application programminginterface

Transport layer

Network layer

Link layer


Shared-Memory Backplane Network

This allows multiple processors to communicate over their common backplane as if they were communicating over a network by using a standard network driver

host

vx3

Ethernet

Shared-MemoryNetwork

Backplane (e.g. VME, PCI)

vx2 vx1


MUX – The Network Driver Interface

This interface decouples the link layer and the network layer• The network protocol does not need to be modified when adding

new network dirvers

• A new network protocol can be added without modifying the existing MUX-based network driver interfaces


TCP/IP Protocol Suite

Based on the 4.4 BSD TCP/IP release, the TCP/IP protocol suite comprises• UDP – User Datagram Protocol

– Low-overhead delivery mechanism of datagrams, used by several applications like BOOTP, DHCP, DNS, TFTP, ...

• TCP – Transmission Control Protocol– Reliable, end-to-end transmission mechanism, used by Telnet,

Rlogin, FTP, ...• IP – Internet Protocol

– Hop-by-hop protocol to transmit datagrams• ICMP – Internet Control Messagge Protocol

– Reports unexpected events in data transfer, used by ping• IGMP – Internet Group Management Protocol

– Used to support multicasting


Sockets

Sockets allow processes to communicate within a single CPU, across an Ethernet, across a backplane or across any connected combination of networks

VxWorks provides• BSD Sockets

– Datagram Sockets (UDP)

– Stream Sockets (TCP)

– Raw Sockets

• Zbuf Sockets

– An alternative set of sockets based on a data abstraction called zbuf, zero-copy buffer

– Applications can read and write BSD sockets without copying data between application buffers and network buffers


Remote Access Applications

RSH – Remote Command Execution• Allows a VxWorks application to run commands on a remote

system and receive the command results on standard output and error over socket connection– Only the client side implementation is provided– A server running on the remote system is assumed

FTP – File Transfer Protocol• Both client and server applications are provided

NFS – Network File System• Server component

– A target running VxWorks act as a file server for any system that runs an NFS client

• Client component– A target running VxWorks can mount a remote file system


Remote Access Applications (cont’d)

TFTP – Trivial File Transfer Protocol• Client and Server applications are provided• Unlike FTP or RSH, TFTP does not require any authentication

Rlogin – Remote Login• On a VxWorks terminal, rlogin( ) gives users the ability to log in to

remote systems on the network• The remote login daemon, rlogind( ), allows remote users to log

in to VxWorks Telnet

• The server application only is provided RPC – Remote procedure call

• RPC implements a client-server model of task interaction• A client requests a remote service from a server and waits for a

reply


DNS and SNTP

DNS – Domain Name System• DNS is a distributed database used by TCP/IP applications that

maps hostnames to IP addresses

SNTP – Simple Network Time Protocol • Client and server components are provided

– The client is normally used to maintain its system internal clock accuracy based on time values reported by one or more servers

– The server provides time information to other systems


BOOTP – Bootstrap Protocol

The BOOTP server• Retrieves boot information from the Bootp Database (bootptab)

• Supplies an Internet host with an IP address and related configuration information

– The IP address is permanently assigned The BOOTP client

• Uses broadcasts to discover an appropriate server

• Lets a target retrieve a set of boot parameters like an IP address and a filename of the bootable image

Both client and server components are provided BOOTP is implemented on top of UDP


DHCP – Dynamic Host Configuration Protocol Like BOOTP, DHCP allows the permanent allocation of

configuration parameters to specific clients However, DHCP also supports the assignment of a

network address for a finite lease period VxWorks includes a DHCP client, server, and relay agent The client can retrieve one or more sets of configuration

parameters from either a DHCP or BOOTP server The server can process both BOOTP and DHCP

messages The DHCP relay agent provides forwarding of DHCP and

BOOTP messages across subnet boundaries


IP Routing

If the destination is directly connected to the sender (e.g., a point-to-point link) or on a shared network (e.g., Ethernet), then IP datagrams are sent directly to the destination • Otherwise, the sender sends the IP datagrams to a default router,

and lets the router deliver them to destination Each router maintains a routing table, which is used to

deliver the IP datagrams to either • A local IP address, for a direct route, or

• The next-hop router IP address, for an indirect route


Dynamic Routing Protocols

Dynamic routing occurs when routers talk to adjacent routers, informing each other of what network each router is connected to

Entries in the routing tables change dynamically as routes change over time

The Routing Information Protocol (RIP) is provided with VxWorks• This is intended for small to medium-sized networks

– The longest path must be less than 16 hops

• It uses a distance-vector protocol

– It contains a vector of distances as the hop count

• RIP version 1 and 2 are supported


Summary

Tornado’s three components• VxWorks, real-time, multitasking operating system

– Priority-based, preemptive scheduling algorithm

– Intertask synchronization and communication services

• Project facility and debugging tools

– Bootable and downloadable projects

• Networking

– Connects hosts and targets during development and debugging

– TCP/IP stack

– Rich set of network applications and protocols


References

Manuals available either in the Tornado on-line help, or via the Wind River Bookstore at: www.windriver.com/windsurf/bookstore• Tornado User’s Guide

• WindView User’s Guide and User’s Reference

• VxWorks Programmer’s Guide

• VxWorks OS Libraries

• VxWorks Network Programmer’s Guide

http://www.windriver.com/windsurf/bookstore/e



http://PID_2.0_WS_Agenda.ppt/

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

Documents

copyright wind river

vxworks slide

waiting task slide

wind kernel

tornadovxworks architecture

task states

task priority

task alternates