Transcript csl.skku.edu

OS for Embedded Systems
What is an Embedded OS?
•
An "embedded system" is any computer system or computing device that performs a
dedicated function or is designed for use with a specific embedded software
application.
•
Embedded systems may use a ROM-based operating system or they may use a diskbased system, like a PC. But an embedded system is not usable as a commercially
viable substitute for general purpose computers or devices.
Introduction to Embedded Systems
2
What makes a good Embedded OS?
•
•
•
•
•
•
•
Modular
Scalable
Configurable
Small footprint
CPU support
Device drivers
etc, etc, etc...
Introduction to Embedded Systems
3
What is Real Time?
“A real time system is one in which the correctness of the
computations not only depends upon the logical correctness of the
computation but also upon the time at which the result is produced.
If the timing constraints of the system are not met, system failure is
said to have occurred.”
- Donald Gillies
“Real time in operating systems:
The ability of the operating system to provide a required level of
service in a bounded response time.”
- POSIX Standard 1003.1
Introduction to Embedded Systems
4
What makes a good RTOS?
•
•
•
•
Multi-threaded and pre-emptible
Thread priority has to exist because no deadline driven OS exists
Must support predictable thread synchronization mechanisms
A system of priority inheritance must exist
Introduction to Embedded Systems
5
Why use an RTOS?*
•
An RTOS enables a design team to create a complex system that responds
to every event with the right action at the right time, every time.
-
•
•
Provides mechanisms to precisely synchronize a large number of tasks
Reliable
An RTOS provides mechanisms to handle faults, bugs, and other
unexpected events that inevitably affect any system of embedded software
When the level of complexity of an embedded system is such that
partitioning the software into smaller, independently executing modules
significantly lowers the overall design complexity and leads to greater
system reliability
-
Time-to-market pressure balances cost of the RTOS
* Mal Raddalgoda, QNX Software Systems, Ltd
Introduction to Embedded Systems
6
Pre-emptive schedule
• General purpose operating systems are very democratic
- Every task or process has equal access to the CPU
- Scheduling decisions are based upon time sharing
- Tasks get to execute without interruption until their time slice is up
- Problem: If a less important task is running and a more important,
deadline dependent task is pending, then the higher priority task
must wait its turn
• RTOSes are different!
- Pre-emptive scheduling allows the higher priority task to take over the
CPU from lower priority tasks
- Extends from application level code to drivers and interrupts
Introduction to Embedded Systems
7
Predictability
•
•
RTOSes must provide the designers with predictable performance data for
system latencies
Need to know best case and worst case scenarios for
-
-
Task switching times
- Elapsed time from the completion of the last instruction of the prior task to
the beginning of execution of the first task of the replacement process
- Measure of the overhead caused by the RTOS
Interrupt handling
- Elapsed time from the arrival of the interrupt signal to the beginning of
execution of the first instruction of the interrupt handler
- Worst case timing for a lower priority interrupt must take into account the
time required to process all higher priority interrupts
Introduction to Embedded Systems
8
Selecting an RTOS - economic factors
•
Generally, we view RTOSes as intellectual property
-
•
Cost of tools
-
•
Pay a royalty to RTOS vendor for each copy of the RTOS that you deliver in your
application ( annuity )
Example: WinCE royalty ~$15 per copy volumes > 10000
Some RTOS vendors supply complete development and debug environments for
their customers
- One-stop shopping
- Products are well-integrated and work together
Board support packages (BSP)
-
Integrating an RTOS with your hardware platform ( target system ) is a nontrivial exercise
Requires expert knowledge of the O/S and hardware
Is there an existing BSP for your hardware?
- Pay the O/S vendor to do it? ( $50K - $1M )
Introduction to Embedded Systems
9
Selecting an RTOS - CPU issues
• Has an RTOS been written and fine-tuned to your CPU choice?
- Take advantage of specialized performance hardware on CPU?
- Example:
- May contain shadow registers for rapid task switching
- May contain special registers for storing task tables context
switching.
- Key kernel functions written in assembly language for maximum
performance
• Has performance of RTOS been fully characterized with your CPU?
• Does the RTOS support the peripheral register set on your
microcontroller?
- Example: PowerPC 860 contains 200 registers for peripheral devices (
timers, ethernet ports, other O/S relevant I/O devices) require support
• Support for virtual and protected memory management?
Introduction to Embedded Systems
10
Selecting an RTOS - Application support
•
•
•
How many simultaneous tasks can the RTOS support?
How many interrupts can be supported?
Does RTOS vendor provide support services for specialized applications?
-
•
FAA and FDA certification of O/S for mission critical applications
Protocol stacks for telecomm and datacomm ( TCP/IP )
Architecture of RTOS
-
Flat
-
memory model
Applications and RTOS are built and linked as a single executable
Entire address space of processor is available to O/S and all applications
Generally fast, but very suceptible to crashes due to buggy code
- Errant pointers can overwrite critical kernel code
Introduction to Embedded Systems
11
Selecting an RTOS - Application support-2
•
Microkernel architecture ( QNX )
-
-
-
Designed to support processors with on chip MMU’s
- Pentium, 386, 486, PowerPC, 68030-68060
Keeps a small portion of the RTOS, microkernel, in non-protected memory
- All other O/S services and applications are handled as tasks in protected
memory
- Managed through the MMU ( See next slide )
Since each task is now isolated in its own protected memory space, errant
pointers cannot crash the O/S
- Can write exception handlers to deal with buggy software
Software executables can be built as a separate application programs,
simplifying software development
May be slower due to overhead of transferring from protected mode to
microkernel services
Introduction to Embedded Systems
12
Task management with MMU
Logical address space
Segmented MMU
Physical address space
Introduction to Embedded Systems
13
Microkernel RTOS
• A microkernel RTOS implements a small
set of core services within the kernel itself
• Additional system services are provided
through add-on processes.
• Every driver, protocol, I/O manager, file
system, graphics systems and GUI run in
there own memory-protected address
space
• Task switch takes 1.95 uSEC on a 133
MHz Pentium CPU
Source: QNX
Introduction to Embedded Systems
14
WindRiver Products
Consulting
Hardware
Reference Boards
Professional Services
Vision Click Probe
Doctor Design Systems
Vision ICE Probe
Software Development Tools
SUPPORT
RealTime Software
VxWorks OS
Tornado Tools
VxWorks AE OS
Prism Tools
Hardware Software Int. Tools
pSOS OS
BSPs and Device Drivers
Networks stacks & Protocols
Introduction to Embedded Systems
15
Why use an RTOS in the first place?
•
•
•
•
•
•
Application isolation
Overrun protection
Managing shared resources
Memory management
Predictability
Reliability
Introduction to Embedded Systems
16
Application Isolation
• Why use a Real Time Operating
System?
- Answer: application isolation
Heap
App 1
Heap
App 2
Q1
Q2
App
Task 2
Sem 1
App
Task 1
App
Task 3
• Why Isolate?
- easier integration/debugging
- protection of critical applications
- decoupled design of apps
• Elements of Isolation
- Code/Data Corruption
- Exception Processing
Kernel
Tasks
Introduction to Embedded Systems
Kernel
Objects
17
Overrun Protection
• Why Protect Resources
- stack overruns
- heap overruns
- CPU lockouts
Heap
App 1
Q1
• Applications are configured with
limits on their memory and CPU
resources
App
Task 2
App
Task 1
• Overrunning will not damage other
applications
Introduction to Embedded Systems
19
Resource Reclamation
• Issues Addressed
Shared Data
- avoid writing application clean up
code
- avoid resource reclamation errors
when an app completes
• Resources released when an
application completes
-
Heap memory
Stack memory
Shared Code memory (hidden)
Shared Data memory (hidden)
Heap
App 1
Q1
App
Task 2
App
Task 1
Shared Code
Kernel
Tasks
Introduction to Embedded Systems
Kernel
Objects
20
System Calls
• What is a system call?
- We define a system call as
being a call from a user mode
protection domain to a kernel
function
• How do they work?
Shared Data
User
App
#1
- Linkage is via a linkage table in
each PD to entry point
- An exception is generated
which allows the OS to promote
the task to supervisor mode
User
App
#2
Link
Table
Shared Code
Kernel
Introduction to Embedded Systems
21
But, How do We Share Code?
Shared Library Protection Domain
fooLib.o
int fooVal;
Application
Domain 1
void fooSet(int x)
{
fooVal = x;
}
Application
Domain 2
fooVal = 4
fooVal = 99
Task A
Task B
fooSet (4)
fooSet(99)
Introduction to Embedded Systems
22
VxWorks AE Overlapped Memory Model
Unmapped
Shared Data
Modules
Reserved
Unmapped
SL PD
Shared Library
Modules
Shared Data
Modules
Unmapped
Shared Library
Modules
Application 1 Heap
Application 2
Modules
Application 2 Heap
Unmapped
Application 2 Heap
Unmapped
Unmapped
Application PD1
Kernel
SD PD
Reserved
Application PD2
Application 1
Modules
Application 1
Modules
Application 2
Modules
Unmapped
Application 1 Heap
Unmapped
Kernel
Kernel
Kernel
Application 1
Context
Physical Memory
Application 2
Context
Kernel
Introduction to Embedded Systems
23
Complexity Forcing Standardization
Companies can’t afford (the time or the money) to choose and
integrate a new supplier and a new software platform for
every new project.
Circa 1995
Vendor Selection
System Integration
Development
Test
Manufacture
Circa 2001
0%
20%
40%
60%
80%
100%
Introduction to Embedded Systems
24
Products for Every Phase of Development
Embedded Development Cycle
Hardware
Bringup
Driver & BSP
Development
RTOS
Integration
Application
Development
System
Integration
Manufacturing
and QA
WindLink Partner Products
UGL, PersonalJWorks, and Zinc
VxWorks, VxWorks AE, pSOSystem
RTA Suite, WindView, and ESP
SNiFF+
Services
Tornado and pRISM+
DIAB and GNU Compilers
visionICE & visionPROBE emulation, visionCLICK & SingleStep Debuggers
Reference Designs and Evaluation Boards
visionWare
visionWare
Introduction to Embedded Systems
visionWare
25
Inside an RTOS Development Environment
Wind River Systems’ Tornado
Introduction to Embedded Systems
26
Tornado II Architecture
Host: PC or UNIX
Target
VxWorks 5.4
Scalable Run-time
Standard Tornado Tools
Real-time Embedded Application
WindView
GUI
Launcher
ScopePak, PerformancePak
LOOK!
WFCs
Target Server
Tornado Plug-ins:
File Systems
Embedded Internet
Graphics
Networking
Multi-processing
Memory Protection
POSIX Library
CodeTEST
wind Microkernel
3rd Party Tools
SNiFF+
SingleStep (PPC)
Debug Agent
BSP
Diab Compiler & RTA (PPC)
Simulation Environment
VxSim
Introduction to Embedded Systems
27
Cross-Development

Typical scenario:
1. Boot target.
2. Attach target server.
3. Edit & compile.
4. Download object module.
5. Test & Debug.
6. Return to 3 or 1 as necessary!
Ethernet
RS-232
Development Host
VxWorks Target
Introduction to Embedded Systems
28
Developer’s Work Bench
Host
Target
Win, Linux, Solaris
ARM, MIPS, Pentium, PPC
Connections
Host-Based Tools
• Tornado Tools 3
• Compilers
• Debuggers
• Code Browsers
• Project Manager
• OS Configuration
• Analysis Tools
• Simulators
Virtual
Serial
BDM/JTAG
Run-Time Components
• Board Support Package
• VxWorks AE
• Networking Stacks
• Other Components
• Your Application
Hardware Debug Tools
• Target Ref Boards
• BDM/JTAG Debuggers
Ethernet
Only Wind River can provide complete, end-to-end
software & hardware development solutions!
Introduction to Embedded Systems
29
Target Server / WDB Agent
Development Host
Target
WindSh
WTX Protocol
VxWorks
CrossWind
Target
Server
Browser
WDB Protocol
(Ethernet, serial,
netrom, custom)
WDB
Application
3rd Party
WTX = Wind River Tool eXchange
Introduction to Embedded Systems
WDB = Wind DeBug
30
VxWorks RTOS
Memory
Management
Device
Support
Scheduling &
System Clock
Facilities
Synchronization
& Intertask
Communication
I/O
system
Mutual
Exclusion
File
Systems
...
Networking
Support
Introduction to Embedded Systems
31
Board Support Package
• Most of VxWorks is independent of the particular target board used.
- The board-specific code for initializing and managing a board’s hardware
is called the BSP.
• The BSP provides VxWorks with standard hardware interface functions
which allow it to run on a board.
• The primary BSP source file, sysLib.c, lives in the BSP directory
target\config\bspName. This is also the directory in which VxWorks
may be reconfigured and rebuilt.
Introduction to Embedded Systems
32
VxWorks
• VxWorks is a multitasking operating system optimized for real-time
and embedded applications.
-
Low interrupt and context switch latency.
Low “system call” overhead.
Scalable.
Portable: well defined BSP.
• VxWorks consists of core kernel facilities and peripheral facilities
which depend on the kernel.
- Loosely, kernel functions are those which can directly change the states of
tasks.
Introduction to Embedded Systems
33
What is a VxWorks Task?
• A task is a context of execution. It has:
- a program counter (current location of execution).
- private copies of CPU registers.
- a stack for local variables, function arguments, and function call chain
information.
• As VxWorks is a uniprocessor system, only one task is actually
executing at any given time.
- When a task is not executing, its context is stored in its Task Control Block
(TCB) and stack. The TCB is the data structure which the kernel uses to
represent and control the task.
Introduction to Embedded Systems
34
Performance Optimizations
• All tasks execute in the same address space:
RAM
fooLib.c
static int x;
text
data
bss
void fooSet (int arg)
{
x = arg;
}
tTaskA
fooSet(4)
tTaskB
fooSet(99)
• All tasks execute at highest CPU privilege level.
Introduction to Embedded Systems
35
Task State Transition Diagram
PENDED
PENDED &
SUSPENDED
READY
EXEC.
SUSPENDED
Introduction to Embedded Systems
DELAYED
DELAYED &
SUSPENDED
36
Preemptive Priority Scheduling
At any time, the
highest priority
task ready to run,
runs!
A higher priority
task which is made
ready preempts the
executing task.
Interrupts preempt
any task.
Notes: On this board, INT 6 is the system clock, INT 3 is the network interrupt.
Introduction to Embedded Systems
37
Context Switches
• When one task stops executing and another task starts, a context
switch has occurred.
• Context switches occur:
- If a higher priority task becomes ready to run
- made ready by executing task.
- made ready in an interrupt, or times out on a blocking call.
- If the executing task makes a blocking kernel call (moving into a pended,
delayed, or suspended state).
• What happens:
- CPU registers for outgoing task stored in its TCB.
- CPU registers for incoming task retrieved from its TCB.
Introduction to Embedded Systems
38
Interrupt Service Routines
• An ISR is a piece of code which is connected to a particular hardware
interrupt. When the hardware interrupt occurs, the ISR runs.
• ISR’s have an effective priority higher than any task.
• Whether and how ISRs can preempt each other is board dependent.
• An ISR has no permanent context; it is NOT a task.
- An ISR may call only a limited set of VxWorks functions.
- Basic rule of thumb: If a routine could block, an ISR cannot call it.
Introduction to Embedded Systems
39
Semaphores
• Semaphores are VxWorks kernel objects which allow blocking and
unblocking of tasks, to coordinate tasks’ actions with those of other
tasks and with external events.
• VxWorks provides three varieties of semaphores:
- Binary (synchronization) semaphores.
- Counting semaphores.
- Mutex (mutual exclusion) semaphores.
• Each type of semaphore is intended primarily for a particular kind of
programming problem.
Introduction to Embedded Systems
40
Binary Semaphores
• Binary semaphores allow tasks to wait for an event without taking up
CPU time polling.
• The event might be an interrupt, or the action of another task.
• Usage:
- Create the binary semaphore using semBCreate()
- A task which wishes to wait for the event calls semBTake() to block until the
event occurs (or a specified time-out expires).
- Whichever ISR or task detects or creates the event calls semBGive() to
allow a waiting task to proceed.
Introduction to Embedded Systems
41
Mutex Semaphores
• Mutex semaphores are used when multiple tasks share a resource
(data structure, file, hardware).
• When used correctly, mutex semaphores prevent multiple tasks from
accessing the resource at the same time, and so corrupting it.
• Usage:
- Create mutex for the resource with semMCreate().
- A task wanting to use the resource first calls semMTake() to block until
the resource is available (or time-out expires).
- When done with the resource, a task calls semMGive() to allow other
tasks to use the resource.
Introduction to Embedded Systems
42
Counting Semaphores
• Binary semaphores keep track of whether or not an event has
occurred, but not how many times the event has occurred (since the
last time the event was serviced).
• Counting semaphores keep a count of how many times the event has
occurred, but not been serviced.
• May be used to ensure that the event is serviced as many times as it
occurs.
• May also be used to maintain an atomic count of multiple equivalent
available resources.
Introduction to Embedded Systems
43
Message Queues
• FIFO buffers of bounded length messages.
• Synchronization and mutual exclusion built in.
- A task pends reading from empty queue, or writing
to full queue. A time-out may be specified.
tConsumer
msgQReceive(...)
tProducer
msgQSend (…)
Introduction to Embedded Systems
44
Watchdogs
• Watchdogs allow a routine to run after a specified delay, as part of
the system clock tick ISR.
• Used for high-reliability periodic polling, and deadline-miss
detection.
Periodic Execution
Deadline-miss Recovery
wwd = wdCreate();
wd = wdCreate();
FOREVER
{
wdStart (wd, deadline,
panicWd, arg);
doWork();
}
...
void panicWd (int param)
{ /* Handle deadline miss */
}
wdStart (wd, period,
myWdISR, arg);
...
void myWdISR (int param)
{
wdStart (wd, period,
myWdISR, param);
doIt (param);
}
Introduction to Embedded Systems
45
VxWorks I/O System
• Provides a consistent, familiar interface to various I/O devices and file
systems.
- Open a file/device by name with open().
- Use the integer file descriptor returned from open() in later calls to
read(), write(), and ioctl().
- File descriptors may be shared among multiple tasks.
- When all tasks are done with a file descriptor, have one task call close()
so that the file descriptor may be reused.
• Global or task-specific redirection of standard input, standard output,
and standard error is possible.
Introduction to Embedded Systems
46
Additional I/O Support
• VxWorks supports the Standard C buffered I/0 library (ansiStdio,
header file stdio.h):
- fopen(), fclose(), fread(), fwrite(), getc(), putc(), etc.
• Built on top of VxWorks Basic I/O system.
• Since the basic I/O system calls reach driver level very quickly (no
protection boundary crossing overhead), buffered I/O may be less
important.
• VxWorks implements printf() in a separate library fioLib as an
unbuffered call. This allows formatted output without support for
buffering.
• C++ Iostreams library provided.
Introduction to Embedded Systems
47
Local File Systems
• VxWorks provides an implementation of the DOS file system,
dosFsLib.
• Compatible with MS-DOS up to release 6.2.
• File system may be used with local block devices such as SCSI, ATA,
or floppy disk drives; or RAM disks.
• To access the raw block device via the I/O system, rawFsLib may be
used.
• The module tapeFsLib may be used to access a SCSI sequential
device (tape drive).
Introduction to Embedded Systems
48
VxWorks Network Support
• Network interfaces:
-
Ethernet
PPP/SLIP/CSLIP
Shared Memory Network (VME backplane)
Custom
• Network Programming API’s:
- 4.3 BSD sockets.
- zbuf (Zero-copy TCP/UDP) sockets.
- Sun RPC.
Introduction to Embedded Systems
49
Network File Access
• VxWorks can act as client or server for remote file access:
Client
Server
VxWorks
Remote Host
Server
Client
VxWorks
Remote Host
Client: VxWorks target accesses
files on remote host via NFS, FTP
or RSH.
• NFS
nfsDrv
• FTP or RSH
netDrv, ftpLib
Server: Remote host accesses files
local to VxWorks target via NFS or
FTP.
• NFS
nfsdLib, mountLib
• FTP
ftpdLib
Introduction to Embedded Systems
50
Software creation process
•
Objective: build an executable image of the source software given the
constraints of an embedded system
-
•
May or may not have operating system services
Various code storage methods
- Mask ROM, EPROM, FLASH, Disk, distributed, On-chip
Must account for variations in:
- Size of memory
- Boot-up procedures
- ROM-based or RAM-based execution
- Location of peripheral devices
- Memory mapped or I/O mapped
Integrate the code modules ( files ) written by different team members
-
Building code images from many different files
- MAKEFILES are a major source of burning resources
Introduction to Embedded Systems
51
Non-volatile storage
•
The vast majority of embedded systems do not have disk storage
-
-
•
Code is typically held in non-volatile, solid-state memory
- EPROM: Electrically Programmable Read Only Memory
- EEPROM: Electrically Erasable Read Only Memory
- FLASH: Modern variant of EEPROM
- MASK ROM: Code is designed in at fabrication
- For cost-sensitive, high-volume applications ( N64 )
Code may be held in local disk memory
- Similar to PC’s
Code may be remotely transferred from server or remote host
- Telecommunication systems
- Embedded controllers within computer systems
- Internet appliances
Let’s look at this technology:
Introduction to Embedded Systems
52
Other Than VxWorks?
•
Wind River Systems
-
•
Windows CE (CE.NET)
-
•
Internet devices
Pocket PC 2002
-
Handheld PC’s and PDA’s
VRTX
Palm Computing
-
•
•
“Real-time” control
Mentor Graphics
-
•
Integrity
Embedded NT/XP
-
QNX
Green Hills Software
-
•
pSOS
QNX Software Systems
-
•
•
PalmOS
Symbian
-
SymbianOS
Introduction to Embedded Systems
53
Commercial Embedded Linux
•
AMIRIX Embedded Linux
-
•
•
•
SAMBA based file, print, CD server
supports real time and high availability
apps
general purpose embedded solution
MontaVista Linux
-
general purpose embedded solution
low latency enhanced kernel
Tuxia TASTE
-
•
for multimedia, wireless, RT on DSP
TimeSys Linux GPL
-
•
runs from DiskonChip or CompactFlash
RidgeRun DSP Linux
-
•
general purpose embedded solution
RedSonic Red-Ice Linux
-
•
LynuxWorks BlueCat
-
•
400K, designed for wireless apps
Internet appliance and multimedia
Red Hat Embedded Linux
-
•
Red Hat derived for information
appliances
PalmPalm Tynux
-
kernel can be as small as 143KB
Lineo Embedix
-
•
•
KYZO Pizza Box Linux
-
•
combines Linux and Java for Internet
apps
Esfia RedBlue Linux
-
Neoware NeoLinux
-
Coventive Xlinux
-
•
derived from Debian
Coollogic Coollinux
-
•
•
distro targets Internet appliances
Vital Systems vLinux
-
for ARM based embedded apps
Introduction to Embedded Systems
54
Open Source Embedded Linux
•
Embedded Debian Project
-
•
ETLinux
-
•
for PC104 SBC’s
uCLinux
-
•
convert Debian to an embedded OS
for microprocessors that don’t have MM
uLinux (muLinux)
-
distro fits on a single floppy
Introduction to Embedded Systems
55
Commercial Linux RTOS
•
•
•
•
•
•
FSMLabs - Open RT Linux
Lineo - Embedix Realtime
LynuxWorks - BlueCat RT
MontaVista Software - Real Time Extensions
REDSonic - REDICE Linux
TimeSys - Linux/Real-Time
Introduction to Embedded Systems
56
Open Source Linux RTOS
•
•
•
•
•
ART Linux - real time extension based on RTLinux
KURT - event schedules with 10us resolution
Linux-SRT - for soft real time apps like multimedia
Qlinux - provides Quality of Service guarantees
RTAI - “hard” Real Time Application Interface
Introduction to Embedded Systems
57
RTLinux
•
•
•
•
•
•
A “hard real-time” mini operating system
runs Linux as it’s lowest priority execution thread
Linux thread completely preemptible
Real time threads and interrupt handlers never delayed by non-realtime
operations
Supports user level programming
MiniRTL implementation fits on a floppy
Introduction to Embedded Systems
58
What’s so special about Linux?
•
•
•
•
•
•
•
Multiple choices vs. sole source
Source code freely available
Robust and reliable
Modular, configurable, scalable
Superb support for networking and Internet
No runtime licenses
Large pool of skilled developers
Introduction to Embedded Systems
59
What’s so special about Linux?
Introduction to Embedded Systems
60
What’s special about Open Source?
Introduction to Embedded Systems
61
Flies in the Ointment
•
•
•
•
•
•
Lack of hardware device drivers
Competing and/or lacking standards
No formalized qualification testing
No single source for marketing
GPL license issues
Startup vendors with shaky futures
Introduction to Embedded Systems
62
Projected Target CPU’s
Introduction to Embedded Systems
63
Any Development Tools Available?
•
•
•
•
•
•
QT/Embedded
Other GUI/Windowing toolkits
Arcom Control Systems
GNUPro Tools
Vendor specific
Standard Linux toolset
Introduction to Embedded Systems
64
C or C++ for Development?
• In general C is a better choice
-
Advanced OOP features can cause code bloat
C++ compilers can generate many routines for a single function
Virtual methods and polymorphism slow program launch times significantly
• Size really does matter
Introduction to Embedded Systems
65
What’s It Being Used For?
•
•
•
•
•
•
•
Control and Monitoring Applications
Industrial Controllers
TV Set Top Boxes (TiVO)
Handheld PDA’s
Automobile Computers
Telecomm and Networking Hardware
Myriad and sundry other uses...
Introduction to Embedded Systems
66
Target Applications
Introduction to Embedded Systems
67
The Embedded OS Market 2001
Introduction to Embedded Systems
68
The Embedded OS Market 2002
Introduction to Embedded Systems
69
Growth of Embedded Linux
Introduction to Embedded Systems
70
For Further Info
Web Sites
•
•
•
•
LinuxDevices.com
http://www.linuxdevices.com/
Embedded Linux Consortium http://www.embedded-linux.org/index.php3
All Linux Devices
http://alllinuxdevices.com/
Embedded Linux StarGate
http://linux-embedded.com/
Introduction to Embedded Systems
71
For Further Info
Web Sites/Magazines
•
Dr. Dobbs Embedded Systems
http://www.ddjembedded.com/about/
•
Embedded Linux Journal
http://embedded.linuxjournal.com/
•
Embedded Systems Programming http://www.embedded.com/mag.htm
Introduction to Embedded Systems
72