Transcript QNX for Automotive Audi – September 2001

Designing High-Performance,
Low-cost Embedded Systems
Jason Clarke,
Field Application Engineer
QNX Highlights
 Over 25 years of building brand value through
reliability and innovation
> Millions of installations worldwide
> Mission- and life-critical environments
> Standards compliance, protected IP
 Platform for leading-edge solutions
> Most reliable RTOS
> Fully integrated development tools
> Expert services for embedded systems
 Leader in innovative embedded technology
> Multitasking RTOS running with MMU support
> Founding member of Eclipse Consortium
> POSIX certified RTOS
> Long time member of the RapidIO Trade Association
Freescale and QNX
Extensive Freescale Support
MPC603, MPC603e, MPC604, MPC604e
Host Processors
MPC740, MPC745, MPC750, MPC750ex,
MPC755
MPC7400, MPC7410, MPC7450, MPC7451,
MPC7455
MPC5200
PowerQUICC Family
Boards
MPC821, MPC823e
MPC850, MPC855T MPC860, MPC860T(P)
MPC860DE (DT, DP, EN, SR)
MPC8240, MPC8245, MPC8255, MPC8260 MPC
8270/8280, MPC8540/60
Sandpoint, 82xx ADS, MVP, Discovery, Atlantis,
Multiple Vendor Boards (Artesyn, Force, MCG,
Embedded Planet, and others)
QNX Neutrino RTOS:
The Most Reliable Realtime
Operating System
Microkernel Architecture Benefits

Kernel space
Device Drivers
TCP/IP Stack
File-system
Application
Application
(re-startable)
Realtime Executive
> No MMU and no protection
> Applications, drivers,
and protocols are all
in Kernel space
Monolithic Kernel
(NT / Unix / etc)
> MMU with partial protection
> Applications are protected
Application


System wide corruption

Contained
User Space
Kernel space
System
wideStack
corruptionFile-system
Device Drivers
TCP/IP
TRUE Microkernel


Contained
Application
(re-startable)
(QNX Neutrino)
> MMU with full protection
> Applications, drivers,
and protocols are
protected
Application
Micro
Kernel
Contained
Device
Drivers
(re-startable)
File-system
TCP/IP Stack
Microkernel Architecture Benefits
 Development and Testing
> Immediate Isolation of Bugs
> Faster Develop Test Cycle
> Allows for Parallel Debugging with Limited Targets
> Memory Protection Forces Use of APIs (Cleaner & Better Code)
> POSIX Programming Through Out System, Even in Drivers
> High Code Reuse
> Easier Driver Level Development
> Regression of Component as Completed
 Release and Management
> Immediate Fault Recognition and Recovery
> High Availability Falls Out of Architecture
> Makes System Upgrades and Patches Easy to Deliver
> Upgrades and Patches can be done Live, Without Downtime
> System Can Scale With Out Software Re-Architecture
Hard Realtime Performance
 Multiple concurrent
scheduling algorithms
 FIFO, Round Robin, Sporadic
 Prioritized pre-emptable threads
 256 priority levels
 Fully pre-emptable and
deterministic kernel
 Prioritized and nested interrupts
 Interrupt handlers can schedule
a user thread or run custom
interrupt code
Priority 50
Thread C
Thread B
Priority 18
Thread A
Priority 12
Thread B
Thread A
IRQ x
Handler x
IRQ y (higher)
Handler y
Thread B
scheduled
Inter-Process Communication
 Processes communicate by sending messages
/dev/tcpip
Process
Manager
Network
Driver
Flash File
System
/dev/ser1
Graphics
Driver
Audio Driver
File System
Message-Passing Bus
Microkernel
Application
Shared Memory Large data sets and
hardware access
 Using
messages cleanly
decouples processes
 POSIX calls built on messages
fd = open(“/dev/tcpip”, ,,,)
read, write, stat, devctl, …
close
Application
 Other POSIX calls as well
> realtime signals
> pipes and POSIX mqueues
> mutexs, condvars, semaphores
> barriers, sleepon
> reader/writer locks
Scalability
Symmetric Multiprocessing
Route Manager
Thread A
File System
Thread B
Thread C
Ethernet Driver
Thread D
Thread E
QNX Neutrino Realtime Scheduler (OS)
Thread A
Thread B
Thread C
Thread D
Thread E
Priority
Thread B
 Multiple processors sharing
common hardware
> Common memory bus and
address space
> Access to all peripheral devices
and interrupts
> OS manages tasks running on
processors – true concurrency
 Transparent to application programs
Future
CPU
CPU
CPU
Future
CPU
 No application software
changes needed
Cache
Cache
Cache
Cache
 Automatic thread (~) scheduling
across all CPUs
High-Bandwidth CPU Bus
Memory
Transparent Distributed Processing
Message Bridge (Ethernet, fabric, interconnect…)
Internet
Networking
Stack
Message
Queues
Flash File
System
Message-Passing Bus
Microkernel
Application
Database
Flash File
System
Applications/servers can be
network-distributed without
special code
> Message queues
> File systems
> Services
Microkernel
Application
> Databases
> …
fd =
fdopen(“/net/$HOSTNAME/etc/log_file.dat”,…);
= open(“/etc/log_file.dat”,…);
write(fd,
write(fd,
…);…);
High Availability
What is High Availability
Availability = The probability that a system or subsystem
will perform its intended function at a given instant of time.
AVAILABILITY =
MTBF
MTBF + MTTR
• 99.999% Availability = Fewer than 5.25 minutes of Annual Downtime
• As MTTR approaches 0, Availability reaches 100%
MTBF: mean time between failure
MTTR: mean time to repair
Critical Process Monitor
 Critical Process Monitor (HAM) monitors components and sends
notification of component failure
 Heartbeat services detect component ‘hang’
 Core file on crash can be created for debugging and analysis
 Recovery from crash can be:
> Controlled shutdown or system restart
> Restart of only the failed subsystem (driver)
System Upgrades
Flash Layout (8260ADS)
BOOT BOOT
BOOT
IMAGE
1 IMAGE 2
IMAGE
FLASH
FLASH
FILESYSTEM
FILESYSTEM
IPL
IPL
 Boot Image
> Contains Kernel
> Requires only Flash Filesystem to be in Image
 Flash Filesystem
> Fault Tolerant POSIX Compliant Filesystem
> Once Filesystem is Loaded Everything Else Can be Loaded from the
Filesystem, Even Drivers
 IPL (Initial Program Loader)
> Sets Up Board and Loads Boot Image
> Sits at Reset Vector
System Upgrade
Process
Manager
Flash File
System
Network
Driver
Application 1
Server
Application 2
Graphics
Driver
Microkernel
Application 1.1
 Add New Features or Processes on the Fly
> Download New Binary into Filesystem or Ram
> Load New Binary into RAM
Replace Existing Processes Without Reboot
>Download New Binary to Filesystem
>Remove Process Running in RAM
>Load New Binary From the Filesystem
Zero Down Time Upgrade
Client
Server
V1.0
/dev/service
New Client
Server
V1.1
/dev/service
New version of the server attaches to the same name
New clients connect to new server
Old server exits when all old clients are gone
QNX Momentics:
The Most Productive Tools
Momentics is Built on Eclipse
www.eclipse.org
QNX sits on the Board
and leads the C/C++
project.
QNX Momentics Tool Suite –
At at a Glance
IDE Tools
Other Tools
and Kits
Command Line
GCC Tools
(GCC v3.3.1)
Board Support
Packages
(Binary)
C, C++ Code
Developer
Choose your host
Windows, Linux, Solaris, QNX Neutrino
Choose your target
Source Debugger
ARM, MIPS, PPC, SH4, XScale, x86
Target System Tools
Choose your language
C, C++, Java
Memory Analysis
Driver
Development
Kits
Choose your BSPs
Application Profiler
BSPs for many popular boards and
reference platforms
System Builder
Application
Builder
System Profiler
Choose command line or IDE
IDE and command line tools interoperate
Code Coverage
Choose 3rd party tools
Growing ecosystem of tools vendors
supporting Eclipse
Development Host OS:
Windows, Linux, Solaris, QNX Neutrino
QNX Momentics Plug-ins
 Code Development Tools
>
>
>
>
>
C, C++, Embedded C++
Power wizards
Code editors
Source navigator
Local history
>
Source control tools
>
Makefile structures
>
Build tools
>
Launch configuration wizard
 Code Coverage
>
>
>
Use coverage data to validate test plan
Multi-run coverage amalgamation
Runtime launch integration into IDE
 Source Debugger
>
Concurrently debug multiple C and C++ applications
 Target System Tools
>
>
>
> Target navigation view
System builder
Target agent
> Target system information tool
Detailed information on all processes and threads
 Application Builder
>
>
Create QNX Photon microGUI applications
Drag and drop widgets
QNX Momentics Plug-ins - Continued
Performance Optimization Tools
> Application Profiler
 Statistical sampling
 Call counting and call pair tracking
 Visual call graph
 Shared-library aware
> Memory Analysis
 Detect double free, non-initialized use
 Overrun/underrun and memory leaks
 Kill/freeze/debug/ignore on error
> System Profiler
 Software logic analyzer
 Analyze events from instrumented kernel
Code Editors
Identify keywords, syntax, and
matching brackets at a glance
Insert
bookmarks
and to-do’s
Set
breakpoints
before you
compile
Identify
compile
errors and
warnings at a
glance
Track all
errors and todo’s from a
central task
list
Use the
outline view to
jump to any
point in your
source file
Simply
double-click
to build for
any target
Hover over
any function
to view its
arguments
and required
headers.
Hover over
any variable
to view its
type
Source Debugger
Use the debug
toolbar to start,
stop, or restart
processes, and
to define
breakpoints
Click here to
view
breakpoints,
variables, watch
points, memory,
registers, etc.
Track each
thread
independently or
trace control
from thread to
thread
Jump directly to
any point in your
source
Edit source
directly from the
debugger view
Simply doubleclick to set
breakpoints
Hover over any
variable to view
its contents
Application Profiler
Utilize call
pairing to
highlight your
program’s
execution
structure, then
use the
information to
make your code
more efficient
View results by
total time,
percentage of
total time, call
count, etc.
Identify at a
glance which
functions need
optimization
Pinpoint which
source lines
consume the
most CPU time
Memory Analysis
Detect invalid
pointer
references and
jump directly to
the source
Identify the
location and
nature of any
memory error
View memory
leaks and
allocations as
they occur
Inspect a call
stack trace
leading back to
the origin of the
error
Instrumented Kernel
 The instrumented kernel logs events which are filtered and stored into buffers
which are captured and analyzed.
Process/thread
creation
System
calls
Interrupts
On/Off filters
Static event filters
User defined filters
Events
Microkernel
Event buffers
State
changes
E1 E2 E3 E4 E5 E6
System Profiler
Network
Capture
File
System Profiler
Zoom in on a
time range,
select processes
of interest, and
create custom
views
Annotate log files
with custom
bookmarks
Search for
specific event
types, and jump
directly to any
event
View event
details at a
glance, including
owner, type, and
event data
Examine summary statistics of
thread states, including duration
QNX Momentics:
System Profiler Example
Case: High Resource Contention
 Problem definition:
> Application is taking too long to send required number of
messages
> System has multiple threads, but all require access to a shared
hardware resource – protected by a mutex
 Approach:
> Search on mutex blocking to see if there is high contention
Server Function
static pthread_mutex_t global_mutex;
void costly_function(void)
{
int i;
/* faked up hardware access */
for ( i = 0; i < 100; i++ ) {
nanospin_ns( 500 );
}
/* The do something with the result */
delay(1);
}
void *server_thread(void *arg)
{
int rcvid, chid;
chid = (unsigned)arg;
while(1) {
rcvid = MsgReceive( chid, NULL, 0, NULL );
pthread_mutex_lock( &global_mutex ); /* protect access to hardware */
costly_function();
pthread_mutex_unlock( &global_mutex );
MsgError( rcvid, EOK );
}
return NULL;
}
Initial Timeline View
Use Condition Statistics View
Configure Conditions
Add Search Conditions
Condition Statistics View
Minimize the Mutex
static pthread_mutex_t global_mutex;
void costly_function(void)
{
int i;
/* faked up hardware access */
pthread_mutex_lock( &global_mutex ); /* protect access to hardware */
for ( i = 0; i < 100; i++ ) {
nanospin_ns( 500 );
}
pthread_mutex_unlock( &global_mutex );
/* The do something with the result */
delay(1);
}
void *server_thread(void *arg)
{
int rcvid, chid;
chid = (unsigned)arg;
while(1) {
rcvid = MsgReceive( chid, NULL, 0, NULL );
costly_function();
MsgError( rcvid, EOK );
}
return NULL;
}
Ahhh….That’s Better!
QNX Momentics:
System Profiler Evolution
System Profiler – CPU Activity
Porting to QNX
VxWorks Porting Guide
 Available as free download on www.qnx.com
 Porting VxWorks 5.x to QNX Neutrino v6.x
 Most in-depth VxWorks porting guide available, with over 80 pages
of technical content, including:
> Architectural comparisons between VxWorks and QNX Neutrino
> Memory accessibility differences
> IPC differences with code examples for:
 Message queues
 Shared memory
 Watchdog timers
> Exception handling
> Startup code
> Hardware input/output, including device driver discussion
> Networking
> Build environments
> Recommended porting methodologies
In Conclusion…
 QNX technology is proven in mission-critical and lifecritical environments
 Scales from small single board computer to massive
high performance systems using Neutrino’s unique SMP
and Distributed capabilities
 High-availability framework protects against software
failures
 Architecture allows for easy and flexible upgrade
strategy
 Integrated tool suite accelerates development
Contact QNX
George Logaras (Regional Sales Manager)
> T : (613) 271-9330
> E : [email protected]
Jason Clarke (Field Applications Engineer)
> T : (613) 591-0931
> E : [email protected]
Online
> [email protected]
> www.qnx.com