Tornado and VxWorks

Download Report

Transcript Tornado and VxWorks

Tornado and VxWorks
Tornado and VxWorks
Tornado-VxWorks Architecture
The Real-Time, Multitasking OS
Intertask Synchronization and Communication
The Project Facility
The Debugging Tools
The Networking Stack
Copyright © Wind River Systems, Inc.
2
What is Tornado?
Development and
Debugging
Real-Time,
Multitasking
Tools
OS
Networking
Copyright © Wind River Systems, Inc.
3
Tornado Architecture - HW Target
Host
Target
Registry
Tool
VxWorks
Tool
Target
Server
Target Agent
Tool

The tools, registry, and target server can run on different
hosts
Copyright © Wind River Systems, Inc.
4
Tornado Architecture - Simulator Target
Host
Registry
Tool
VxWorks
Target
Tool
Server
Target Agent
Tool


VxWorks runs as a process under the host OS
The simulator architecture provides no emulation of
instruction, native compilers are used
Copyright © Wind River Systems, Inc.
5
Tornado and VxWorks
Tornado Architecture
The Real-Time, Multitasking OS
Intertask Synchronization and Communication
The Project Facility
The Debugging Tools
The Networking Stack
Copyright © Wind River Systems, Inc.
6
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
foo()
{
}
for (;;)
{
waitForData( );/* Until external event occurs */
processData( );
}
• 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”
Copyright © Wind River Systems, Inc.
7
Creating a Task
Copyright © Wind River Systems, Inc.
8
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)
Copyright © Wind River Systems, Inc.
9
Task States
Copyright © Wind River Systems, Inc.
10
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
Copyright © Wind River Systems, Inc.
11
Kernel Operation
Scheduler
Copyright © Wind River Systems, Inc.
12
Multitasking Facilities
Copyright © Wind River Systems, Inc.
13
Tornado and VxWorks
Tornado-VxWorks Architecture
The Real-Time, Multitasking OS
Intertask Synchronization and Communication
The Project Facility
The Debugging Tools
The Networking Stack
Copyright © Wind River Systems, Inc.
14
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)
Copyright © Wind River Systems, Inc.
15
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
Copyright © Wind River Systems, Inc.
16
Message Queues


Message queues are kernel objects used for passing
information between tasks
Message queues provide a FIFO buffer of messages
Task A


Task B
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
Copyright © Wind River Systems, Inc.
17
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
Copyright © Wind River Systems, Inc.
18
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
Copyright © Wind River Systems, Inc.
19
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
Copyright © Wind River Systems, Inc.
20
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
Copyright © Wind River Systems, Inc.
21
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
Copyright © Wind River Systems, Inc.
22
Tornado and VxWorks
Tornado-VxWorks Architecture
The Real-Time, Multitasking OS
Intertask Synchronization and Communication
The Project Facility
The Debugging Tools
The Networking Stack
Copyright © Wind River Systems, Inc.
23
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
Copyright © Wind River Systems, Inc.
24
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)
Copyright © Wind River Systems, Inc.
25
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
Copyright © Wind River Systems, Inc.
26
Project Facility Workspace Window

3 Workspace window views
Copyright © Wind River Systems, Inc.
27
Tornado and VxWorks
Tornado-VxWorks Architecture
The Real-Time, Multitasking OS
Intertask Synchronization and Communication
The Project Facility
The Debugging Tools
The Networking Stack
Copyright © Wind River Systems, Inc.
28
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
Copyright © Wind River Systems, Inc.
29
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
Copyright © Wind River Systems, Inc.
30
WindShell
Copyright © Wind River Systems, Inc.
31
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
Copyright © Wind River Systems, Inc.
32
Browser
Copyright © Wind River Systems, Inc.
33
CrossWind


CrossWind is a source level, graphical, debugging frontend 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 prekernel execution
Copyright © Wind River Systems, Inc.
34
CrossWind
Copyright © Wind River Systems, Inc.
35
WindView 2.2

WindView allows one to study dynamic interactions of all
the elements of complex, real-time systems
Copyright © Wind River Systems, Inc.
36
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
Copyright © Wind River Systems, Inc.
37
WindView 2.2 Example
Copyright © Wind River Systems, Inc.
38
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
Copyright © Wind River Systems, Inc.
39
Tornado and VxWorks
Tornado-VxWorks Architecture
The Real-Time, Multitasking OS
Intertask Synchronization and Communication
The Project Facility
The Debugging Tools
The Networking Stack
Copyright © Wind River Systems, Inc.
40
VxWorks Network Components
Target
NFS server
RPC
zbuf
netDrv
rlogin telnet
Application layer
rsh
ftp
Application
programming
interface
Sockets
TCP
UDP
IP
MUX
Ethernet
PPP
Transport layer
Network layer
Shared Memory
Network
Copyright © Wind River Systems, Inc.
Link layer
41
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
Ethernet
vx3
vx2
vx1
Shared-Memory
Network
Backplane (e.g. VME, PCI)
Copyright © Wind River Systems, Inc.
42
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
Copyright © Wind River Systems, Inc.
43
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
Copyright © Wind River Systems, Inc.
44
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
Copyright © Wind River Systems, Inc.
45
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
Copyright © Wind River Systems, Inc.
46
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
Copyright © Wind River Systems, Inc.
47
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
Copyright © Wind River Systems, Inc.
48
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
Copyright © Wind River Systems, Inc.
49
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
Copyright © Wind River Systems, Inc.
50
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
Copyright © Wind River Systems, Inc.
51
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
Copyright © Wind River Systems, Inc.
52
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
Copyright © Wind River Systems, Inc.
53
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
Copyright © Wind River Systems, Inc.
54