Transcript Chapter 1 -- Introduction - Real

CSE 522
Real-time Embedded Systems
Computer Science & Engineering Department
Arizona State University
Tempe, AZ 85287
Dr. Yann-Hang Lee
[email protected]
(480) 727-7507
Real-time Embedded Systems
 Embedded system
 the software and hardware component that is an
essential part of another system
 Real-time system
 provide well-timed
computation
 deadlines, jitters,
periodicity
Reference
input
A/D
Controller
D/A
A/D
Control-raw
computation
sensor
Plant
actuator
 temporal dependency
2
Embedded Systems -- Examples
3
Emerging Embedded Systems
4
Hardware Platform
 Organization
 buses to connect
components – PCI, ISA,
PC104+
memory
 Package
 standard chips on PC
 processor + ASIC
 SOC
I/O
I/O
CPU
(microprocessor)
I/O
Timer
I/O
5
SW Development for RT ES
 To write the control software for a
smart washer




initialization
initialize
read keypad or control knob
read sensors
take an action
 System current state
 state transition diagram
 external triggers via
external trigger?
ISR: to set/clear
events
Take actions
polling or ISR
 If there are multiple triggers and
external conditions – single or
multiple control loops
Change system state
6
Periodic Tasks
 Invoke computation periodically
 Adjust pressure valves at a 20 Hz rate
Task initialization
(set up periodic
timer interrupts)
Task initialization
start_time=time( )
wait for the interrupt
event
computation
computation
Sleep(period ( time( ) -start_time) )
7
SW Development for RT ES
 In the example of smart washer
 Never-ending in a single control loop
 Single execution threat and one address space
 Event triggering and state transitions
 Small memory footprint
 What are missing:
 no concurrency (real-world events occur in parallel)
 no explicit timing control (let’s add a timer)
 difficult to develop and maintain large embedded systems –
verifiable, reusable, and maintainable
8
RT ES vs. General Software
 Multi-tasking for concurrent events
 Machine dependence and portability
 Software abstraction, modular design
 information hiding, OO, separate compilation, reusable
 a sorting procedure -- function, input, output specification
 Control timing
 predictable actions in response to external stimuli
 deadline (absolute or relative), and jitter
 Resource constraints and sharing
 CPU time, stack, memory, and bandwidth
 Scheduling
9
Timing Constraints and Multi-threading
 Given input x1 at time t1, produce output y1 at time t2
 Non-deterministic operation, Time-dependent
behavior, and race condition
 difficult to model, analyze, test, and re-produce.
 Example: NASA Pathfinder spacecraft
 Total system resets in Mars Pathfinder
 An overrun of data collection task 
a priority inversion in mutex semaphore 
failure of communication task 
a system reset.
 Took 18 hours to reproduce the failure
in a lab replica  the problem became
obvious and a fix was installed
10
Trends of RT Embedded Systems
Applications
 Wide-spreading, distributed, connected, and heterogeneous
 Mission and safety critical
 High-end consumer products
 cell phone, HDTV, home network, PDA, GPS, appliances
 Quality of the products
 portable/reusable, reliable/dependable, interoperable, predictable
(schedulable), and secured
 Software extensive
 A new S-class Mercedes-Benz
 over 20 million lines of code
 nearly as many ECUs as the new Airbus A380 (excluding the plane's
in-flight entertainment system).
11
Embedded System Development
 Need a real-time (embedded) operating system ?
 Need a development and test environment ?
 Use the host to edit, compile, and build application programs,
and configure the target
 At the target embedded system, use tools to load, execute,
debug, and monitor (performance and timing)
Development workstation
Embedded systems
(Workstation, embedded
system development tools)
Simulated signal source
(workstation, interface cards),
& test harness
Ethernet
12
From Source to Executable
 Compiler, linker, and loader
 In ELF: executable, relocatable, shared library, and core
 information for relocation, symbol, debugging
 linker resolves symbol reference
 Link script or link command file
 assigns absolute memory addresses (program area, static data,
bss, stack, vector table, etc.)
 Startup code to disable interrupts, initialize stack, data, zero
uninitialized data area, and call main().
asm
ld
cc
13
Real-time Operating System
 Use the computer hardware efficiently
 To manage system resource through
 system calls -- issued by tasks
 interrupts -- timer and external events
 Typical requirements
 Support for scheduling of real-time tasks and interrupt handlers
 Inter-process communication
 I/O support -- driver
 User control of system resource -- memory and file system
 Thread or process for task execution:
 smallest execution units that can be scheduled
 lives in a virtual, insulated environment
 uses or owns system resources
14
Real-time Operating System
 Functions:
 task management,


 scheduling, dispatcher
 communication (pipe, queue)

 synchronization (semaphore, event)

External
interrupt
Timer
interrupt
System calls
(trap)
Interrupt
dispatch
memory management
time management
device driver
interrupt service
Interrupt
service
Time service &
events
Scheduling
&
dispatcher
Task
execution
Services (create thread,
sleep, notify, send,…)
kernel
15
RTOS Structures
 Small, fast, proprietary kernels
 Monolithic kernels that contains all services
 Component-based kernels or micro-kernel
 contain the minimal services
 small (10K bytes) and modular
 configurable by selecting components to compose a kernel
 RT extensions (to extend Unix or Windows)
 Why -- richer environment, more functionality, familiar interfaces
 Compliant kernel (LynxOS) -- Takes an existing RTOS and make it
execute other UNIX binaries
 Dual kernels– add an RTOS kernel between the hardware and the
OS. (RTLinux)
 OS kernel modifications – use patches to make Linux kernel more
deterministic (Real-time Linux distributions)
16
RTOS vs. OS
 Often used as a control device in a dedicated
application
 Well-defined fixed-time constraints
 The system allows access to sensitive resources with defined
response times.
 interrupt latency and time for context switch
 worst-case and average response times
 Requirements of RTOS
 predictable (??)
 upper bounds for system calls and memory usage
 configuration of memory layout and kernel data structures
 fine grain interrupt control
17
Task Management in vxWorks
executing
Execution
pending
Ready
delayed
Blocked
 Task structure:
 task control block -


ready
taskInit()
suspended
priority(initial and inherited), stack frame, task current state,
entry point, processor states (program counter, registers)
callback function (hook) pointers for OS events
 Create and initialization
 taskInit, taskActivate, taskSpawn
 task_id = taskSpawn (name, priority, options, stacksize, main, arg1,…,
arg10);
 Task control and deletion: taskDelay (nanosleep), taskSuspend,
taskResume, taskRestart, exit, taskDelete
18
Scheduling Mechanism
 Priority-driven and round-robin with timeslicing
 taskPrioritySet (tid, priority), kernelTimeSlice
 taskLock, taskUnlock -- disable and enable scheduling (preemption)
 0 (highest) to 255 (lowest) in vxWorks
19
Shared Code and Reentrancy
 A single copy of code is invoked by different concurrent
tasks must reentrant
 pure code
 variables in task stack (parameters)
 guarded global and static variables (with semaphore or taskLock)
 variables in task content (taskVarAdd)
taskOne ( )
{
.....
myFunc ( );
.....
}
taskTwo ( )
{
.....
myFunc ( );
.....
}
myFunc ( )
{
.....
.....
}
20
Inter-task Communication
 Shared memory
 vxWorks has all tasks in a single address space
 simple and unprotected
 direct access as long as the address is known
 Message queue - multiple senders and receivers
 msgQCreate( ), msgQDelete( ), msgQReceive( )
 status = msgQSend(msgQId, buffer, nBytes, timeout, priority )
 queue size, message size, timeout parameters
 msg_pri_normal -- to be added to the queue tail
 msg_pri_urgent -- to be added to the queue head
 ISR cannot read a message queue
 mq_notify( ) in POSIX -- notification to a single task when a new
message arrives at an empty queue
21
Inter-task Communication
 Pipe -- virtual I/O, built on top of msgQ
 pipeDevCreate (name, nMessages, nBytes) -- create a named
pipe in the global file descriptor table
 open, read, write, and ioctl routines for device control
 select( ) -- wait for input from multiple pipes (with a timeout)
 Network Inter-task communication
 Socket and RPC of vxWorks -- compatible with BSD 4.3 Unix
 Signals (for asynchronous events)
 between tasks and ISR -- to execute signal handler of a task
 bind a handler to a signal, send a signal (kill(tid, signo)), signal
masks
 sigqueue( ) in POSIX
 sigInit( ), sigqueueInit( )
22
Signals
 To register a handler -- signal (signo, sigHandler)
void sigHandler ( int sig, int code, struct sigcontext * pSigCtx);
 Exception: issues a signal to the running task
 if no signal handler, suspend the task
 hardware dependent
 return with exit(), taskRestart(), longjump()
signal
normal program
{
.
.
.
.
}
sigHandler
{
.
.
.
.
}
23
Synchronization and Mutual Exclusion
 Semaphores in vxWorks:
 binary
 mutual exclusion -- addresses inheritance, deletion safety and recursion
 counting
 Routines: semBCreate( ), semMCreate( ), …, semDelete( )
 semTake( ), semGive( ), semFlush( ) (broadcasting)
 Semaphore id, queue type (SEM_Q_PRIORITY or SEM_Q_FIFO),
and timeout on waiting




SEM_ID sem = semBCreate (SEM_Q_PRIORITY, SEM_FULL);
semTake(sem, WAIT_FOREVER);
.....
semGive(sem);
 Synchronozation:
 ISR calls semGive( ) to signal an event
 task calls semTake( ) to wait for the event
24
Synchronization and Mutual Exclusion
 Mutual Exclusive -- restriction:
 can be given by the task took it (owns it)
 cannot be given from an ISR
 no flush
 Priority inheritance: set flag = SEM_Q_PRIORITY |
SEM_INVERSION_SAFE
 Deletion Safety: delete a task while it is holding a semaphore
 SEM_DELETE_SAFE: protect from deletion
 Recursion: (task ownership count)
 take a semaphore more than once by the task that owns it
 released when it is given the same number of times
 POSIX semaphore (counting)
 unnamed -- malloc a semaphore struct and use * to operate
 named --open a semaphore in OS, shared among processes
25
Interrupt Service Routines (1)
 Interrupt service routines (ISRs) run outside of any task’s
context. Thus they involves no task context switch.
 intConnect ( ) -- to install user-defined ISR_routine
 If intConnect() is used for PowerPC, it is not needed to explicitly disable
the current interrupt source and do interrupt acknowledgement.
handler wrapper
Save registers
set up stack
check interrupt source (vector)
invoke routine
restore registers and stack
exit
user ISR
ISR_routine ( )
{
....
....
}
intConnect(INUM_TOIVEC(someIntNum), ISR_routine, someVal);
26
Interrupt Service Routines (2)
 Interrupt stack -- a suitable size of maximum interrupt
nesting depth
 Whenever the architecture allows it, all ISRs use the
same interrupt stack
 The stack is allocated as system starts up
 Must be large enough to handle the worst case
 Limitations to ISRs
 ISR should not be blocked
 don’t take a semaphore (malloc() and free() takes a semaphore),
giving semaphore however is permitted
 don’t perform I/O via vxWorks drivers that can get blocked
 ISRs cannot call printf() to output message to console, please
use logMsg() and other functions defined in logLib
27
Interrupt Service Routines (3)
 Interrupt-to-task communications
 Interrupt events usually propagate to task-level code.
 The following techniques can be used to communicate from
ISRs to task-level code
 Shared memory and ring buffers. ISRs can share variables,




buffers, and ring buffers with task level code
Semaphores. Giving semaphores is permitted
Message queues. ISR can send messages to message queues
for tasks to receive
Pipes. ISRs can write messages to pipes that tasks can read
Signals. ISRs can signal tasks, causing asynchronous
scheduling of their signal handlers
28
Timer and Clock
 Clock tick
 Watchdog timer in vxWorks -- mantained by the
system clock ISR
 wdCreate( ), wdDelete( ), wdStart( ), wdCancel( )
 Typically invokes a callback function when the delay is
expired (at the interrupt level of the system clock)
 real-time clock - POSIX timer
 create, set and delete a timer that signals tasks when goes off
 Delay a period:
 taskDelay( ) in vxWork
 nanosleep( ) in POSIX
29
Device Driver
 Purpose:
 a well defined and consistent interface to handle requests for device
operations
 isolate device-specific code in the drivers
 A software interface to hardware devices
 resides in kernel or user spaces
 Classification
 character device (terminal)
 block (disk) -- with buffer cache
 network
 pseudodevice
OS specific
code
I/O class
specific code
device
driver
Hardware
specific code
 When to call a device driver
 configuration, I/O operations, and interrupt
I/O adapters
30
Interaction with I/O Devices
 Polling - Read status until the device is ready, and then read/write data
 Check flags which are set by ISR –
 Interrupts when a new input arrives or the device completes an output
operation
 If the flag is set, proceed to do the I/O operation
 Use driver –
 Build input/output buffers in the driver
 If an new input arrives, ISR reads the data and saves in the buffer (if a
write is completed, ISR triggers the next write if the output buffer is not
empty)
 Application reads from (or write to) the corresponding buffer
31
Structure of Device Driver
0
1
2
3
File descriptor
table
Device list
(of device descriptors)
Driver table
(function pointers)
“/tty0/”
1
drvnum value
2
2
1
*dev
3
“/pty0/”
1
“/xx1/”
3
Devicedependent
data
drvnum create remove
0
**
**
1
2
3
open
close
read
write
ioctl
32
Board Support Package
 Most of RTOS’s are independent of the particular target board.
 The board-specific code for initializing and managing a board’s
hardware is called the BSP. The BSP provides RTOS with
standard hardware interface functions which allow it to run on a
board.
Hardware-Independent Software
Tools - Applications
I/O System
vxWorks Libraries
TCP/IP
File Systems
Hardware-Dependent Software
wind Kernel
SCSI Driver
SCSI Controller
BSP
Hardware
Clock Timer
Serial Controller
Network Driver
Ethernet Controller
33
Remote Target Boot Process
 Basic initialization code exits in ROM.
 This code can initialize the serial port or ethernet controller
 allows the user to set the target parameters like the name of
kernel image , target IP address, host IP address etc needed
initially to pull over the kernel image into target .
 It can perform TFTP and other serial port transfers.
Host
Target
RS-232
VxWorks
Ethernet
34
Boot ROM
 Target’s boot ROM code executes on power up.
 The boot ROM code containing a bootloader:
 Allows setting of boot parameter.
 Downloading & executing kernel image.
 Default Boot ROM’s does not contain the VxWorks
system.
 Replace board manufacturer’s ROMs with vxWorks
bootloader
 Downloads VxWorks into target memory via the network
(TFTP) or serial port
 Starts executing VxWorks.
35
Boot Sequence
 vxWorks boot sequence
romInit.s : romInit()
Disables interrupts, puts the boot type on the
stack, clears caches
bootInit.c : romStart()
The text and data segments are copied
from ROM to RAM
usrConfig.c and
bootConfig.c : usrInit()
Cache initialization, zeroing out the system bss
segment, initializing interrupt vectors and
initializing system hardware to a quiescent state
Libcuptoolvx.a :
kernelInit()
usrCofig.c and
bootConfig.c : usrRoot()
Initiates the multitasking environment: disables
round-robin mode, creates an interrupt stack,
creates root stack and TCB
Initializes the I/O system, installs drivers,
creates devices, and then sets up the network
as configured in configAll.h and config.h
36