QNX for Automotive Audi – September 2001
Download
Report
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