CSE 522 Real-time Embedded Systems

CSE 522Real-time Embedded Systems Computer Science & Engineering DepartmentArizona State University Tempe, AZ 85287 Dr. Yann-Hang Leeyhlee@asu.edu(480) 727-7507

Controller A/D Control-raw computation Reference input D/A A/D sensor Plant actuator 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 • temporal dependency

Embedded Systems -- Examples

Emerging Embedded Systems

Organization buses to connect components – PCI, ISA, PC104+ Package standard chips on PC processor + ASIC SOC I/O I/O I/O I/O memory CPU (micro- processor) Timer Hardware Platform

SW Development for RT ES • To write the control software for a smart washer • initialize • read keypad or control knob • read sensors • take an action • System current state • state transition diagram • external triggers via polling or ISR • If there are multiple triggers and external conditions – single or multiple control loops initialization external trigger? ISR: to set/clear events Take actions Change system state

Periodic Tasks Task initialization (set up periodic timer interrupts) Task initialization start_time=time( ) wait for the interrupt event computation computation Sleep(period - ( time( ) -start_time) ) Invoke computation periodically • Adjust pressure valves at a 20 Hz rate

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

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

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

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).

Development workstation Embedded systems Simulated signal source (workstation, interface cards), & test harness (Workstation, embedded system development tools) Ethernet 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)

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

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

Real-time Operating System • Functions: • task management, • scheduling, dispatcher • communication (pipe, queue) • synchronization (semaphore, event) • memory management • time management • device driver • interrupt service External interrupt Interrupt dispatch Interrupt service Scheduling & dispatcher Timer interrupt Time service & events Task execution Services (create thread, sleep, notify, send,…) System calls (trap) kernel

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)

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

Task Management in vxWorks • Task structure: • task control block -- • 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 executing Execution pending ready delayed Ready Blocked suspended taskInit()

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

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 ( ); ..... } myFunc ( ) { ..... ..... } taskTwo ( ) { ..... myFunc ( ); ..... }

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

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 ioctlroutines 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( )

Signals • To register a handler -- signal (signo, sigHandler) void sigHandler ( int sig, int code, structsigcontext * pSigCtx); • Exception: issues a signal to the running task • if no signal handler, suspend the task • hardware dependent • return with exit(), taskRestart(), longjump() normal program { . . . . } sigHandler { . . . . } signal

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

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

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);

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 callprintf() to output message to console, please use logMsg() and other functions defined in logLib

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

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

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 • When to call a device driver • configuration, I/O operations, and interrupt OS specific code I/O class specific code device driver Hardware specific code I/O adapters

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

“/tty0/” 1 “/pty0/” 1 “/xx1/” 3 Device list (of device descriptors) Device- dependent data Structure of Device Driver 0 1 2 3 File descriptor table Driver table (function pointers)

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 BSP Network Driver Hardware Ethernet Controller Clock Timer SCSI Controller Serial Controller

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.

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.

Boot Sequence • vxWorks boot sequence romInit.s : romInit() Disables interrupts, puts the boot type on the stack, clears caches The text and data segments are copied from ROM to RAM bootInit.c : romStart() Cache initialization, zeroing out the system bss segment, initializing interrupt vectors and initializing system hardware to a quiescent state usrConfig.c and bootConfig.c : usrInit() Initiates the multitasking environment: disables round-robin mode, creates an interrupt stack, creates root stack and TCB Libcuptoolvx.a : kernelInit() Initializes the I/O system, installs drivers, creates devices, and then sets up the network as configured in configAll.h and config.h usrCofig.c and bootConfig.c : usrRoot()

CSE 522 Real-time Embedded Systems