Embedded System S/W Organization & Static Scheduling

Embedded System S/W Organization & Static Scheduling EE202A (Fall 2002): Lecture #3

Reading List for This Lecture • Required • [Melkonian00] Melkonian, Michael. Get by without an RTOS. Embedded Systems Programming, September 2000. • http://www.embedded.com/2000/0009/0009feat4.htm • [Hill00] Hill, J.; Szewczyk, R.; Woo, A.; Hollar, S.; Culler, D.; Pister, K. System architecture directions for network sensors. ASPLOS 2000. • http://webs.cs.berkeley.edu/tos/papers/tos.pdf • [Lee87] Lee, E.A.; Messerschmitt, D.G. Static scheduling of synchronous data flow programs for digital signal processing. IEEE Trans. on Computers, vol.C-36, (no.1), Jan. 1987. p.24-35. • Others • [Bhattacharyya99] Bhattacharyya, S.S.; Murthy, P.K.; Lee, E.A. Synthesis of embedded software from synchronous dataflow specifications. Journal of VLSI Signal Processing Systems for Signal, Image, and Video Technology, vol.21, (no.2), Kluwer Academic Publishers, June 1999. p.151-66. • http://ptolemy.eecs.berkeley.edu/publications/papers/99/synthesis/

Course Project Proposal Due Tuesday Oct 15, 6PM • One page proposal describing the proposed project, and listing reference material • talk to me for suggestions • Individually or groups of two • Project may cover any topic of interest in embedded and real-time systems • need not be on a topic covered in lectures • ties with your research are acceptable • A conference-style report and a project presentation on your results will be due at the end of the quarter • Submit as proj1.zip or proj1.tgz

Real-time Implementation in Software on a Single Processor • Typical implementation approaches • Synchronous • single program • Asynchronous • foreground/background system • multi-tasking

Example • A process controller with following modules • a clock tick comes every 20 ms when a clock module must run • a control module must run every 40 ms • three modules with soft constraints • operator display update • operator input • management information logs

Single Program Approach while (1) { wait for clock;do clock module; if (time for control) do control; else if (time for display update) do display; else if (time for operator input) do operator input; else if (time for mgmnt. request) do mgmnt. output; } • Must have t1 + max(t2, t3, t4, t5)  20 ms • may require splitting tasks… gets complex!

Another Example int main(void) { Init_All(); for (;;) { IO_Scan(); IO_ProcessOutputs(); KBD_Scan(); PRN_Print(); LCD_Update(); RS232_Receive(); RS232_Send(); TMR_Process(); } // should never ever get here // can put some error handling here, just in case return (0); // will keep most compilers happy}

Observations on the Single Program Approach • Each function called in the infinite loop represents an independent task • Each of these tasks must return in a reasonable time, no matter what thread of code is being executed • We have no idea at what frequency our main loop runs. • In fact, the frequency is not constant and can significantly change with the changes in system status (as we are printing a long document or displaying a large bitmap, for example) • Mix of periodic and event-driven tasks • Most tasks are event driven • e.g. IO_ProcessOutputs is an event-driven task • dedicated input event queue associated with them • e.g. IO_ProcessOutputs receives events from IO_Scan, RS232_Receive, and KBD_Scan when an output needs to be turned on • Others are periodic • No trigger event, but may have different periods, and may need to change their period over time

Observations on the Single Program Approach (contd.) • Need some simple means of inter-task communications • e.g. may want to stop scanning the inputs after a particular keypad entry and restart the scanning after another entry • require a call from a keypad scanner to stop the I/O scanner task • e.g. may also want to slow down the execution of some tasks depending on the circumstances • say we detect an avalanche of input state changes, and our RS-232 link can no longer cope with sending all these messages • like to slow down the I/O scanner task from the RS-232 sending task • May need to perform a variety of small but important duties • e.g. dim the LCD exactly one minute after the very last key was pressed, flash a cursor on the LCD at a periodic, fixed and exact frequency. • dedicating a separate task to each of these functions is definitely overkill – so handled through timers and TMR_Process

Handling Periodic Tasks with Multiple & Variable Rates [Melkonian00] • Two variables, execution counters and reload value, associated with tasks volatile unsigned int LCD_ReloadValue = LCD_TASK_DEFAULT_SPEED;volatile unsigned int LCD_ExecCounter = LCD_TASK_DEFAULT_SPEED; • How it works? • execution counter counts down from reload value • in exact timing system, the execution counter is decremented in a fixed frequency interrupt routine • in relative timing system, the task itself decrements the counter • when it reaches zero, the task is called, otherwise the entry function to the task exits without further processing • using a variable rather than a constant for reload value is that this helps us to dynamically manipulate the execution speed of the task • setting execution counter to special value TASK_DISABLED prevents task execution • can be set by any other task • Issues • fair bit pf processing in the interrupt handler • need mutually exclusive access to execution counter by task and interrupt code • task must be written so that they return in a reasonable time – may need to split

Handling Event-driven Tasks • Each event driven task has an input event queue • e.g. ring buffer with asynchronous GetEvent and PutEvent • Unique input event structure for each task typedef unsigned int word;typedef struct { word InPtr; /* Head of buffer */ word OutPtr; /* Tail of buffer */ word Count; /* Counter */ EVENT_TYPE Store[BUFFER_SIZE]; /* buffer space */} INPUT_EVENT_QUEUE_TYPE;

Event-driven Tasks (contd.) • Sending an event // somewhere in RS232 moduleOUTPUT_EVENT_TYPE OutputEvent; OutputEvent.NewState = 1; // new state - on OutputEvent.Number = 1; // turn on output # 1OUTPUT_PutEvent(&OutputEvent); // inject an event • Example event-driven task // this task is called from main control loopvoid IO_ProcessOutputs(void) { word ret; OUTPUT_EVENT_TYPE OutputEvent; // normal execution counter processing goes here.. // .. // end of execution counter processing if ((ret = OUTPUT_GetEvent(&OutputEvent) != EMPTY) { // buffer not empty - process OutputEvent & // turn on/off the required output IO_OutputStateChange(OutputEvent.Number, OutputEvent.NewState) } }

Handling Simple Periodic Actions • Many actions that require events to happen at a fixed time once or periodically, e.g. • a blinking cursor • an output that needs to be periodically toggled • show a user message that will disappear or change after a fixed period • need to light up the keypad or the LCD and turn it off after a period of inactivity • Making each of them periodic tasks too heavy wieight • lots of execution counters to handle in interrupt handler • A solution: Software Timers

Software Timers • Tasks install a user-defined timeout function for each timer • TMR_Start and TMR_Stop functions • Timers maintained in “delta list” so that only the timer to be next handled is decremented in the interrupt list\ • e.g. timers that are set to expire in 10, 60, & 200 clock ticks will be stored as • 10 50 (= 60 - 10) 140 (= 200 - 60) • but, more processing when we add or remove a timer to/from the delta queue

Foreground/Background Systems Foreground (interrupt) on interrupt { do clock module; if (time for control) do contro; } Background while (1) { if (time for display update) do display; else if (time for operator input) do operator; else if (time for mgmnt. request) do mgmnt.; } • Decoupling relaxes constraint: t1 + t2  20 ms

Multi-tasking Approach • Single program approach: one “task” • Foreground/background: two tasks • Generalization: multiple tasks • also called processes, threads etc. • each task carried out in parallel • no assumption about # of processors • tasks simultaneously interact with external elements • monitor sensors, control actuators via DMA, interrupts, I/O etc. • often illusion of parallelism • requires • scheduling of these tasks • sharing data between concurrent tasks

Task Characteristics • Tasks may have: • resource requirements • importance levels (priorities or criticalness) • precedence relationships • communication requirements • And, of course, timing constraints! • specify times at which action is to be performed, and is to be completed • e.g. period of a periodic task • or, deadline of an aperiodic task

Preemption • Non-preemptive: task, once started, runs until it ends or has to do some I/O • Preemptive: a task may be stopped to run another • incurs overhead and implementation complexity • but has better schedulability • with non-preemptive, quite restrictive cobstraints • e.g. N tasks, with task j getting ready every Tj, and needs Cj time during interval Tj then: Tj C1 + C2 + … + CN in the worst case because all other tasks may already be ready i.e. period of every thread  sum of computation times!

How to organize multiple tasks? • Cyclic executive (Static table driven scheduling) • static schedulability analysis • resulting schedule or table used at run time • TDMA-like scheduling • Event-driven non-preemptive • tasks are represented by functions that are handlers for events • next event processed after function for previous event finishes • Static and dynamic priority preemptive scheduling • static schedulability analysis • no explicit schedule constructed: at run time tasks are executed “highest priority first” • Rate monotonic, deadline monotonic, earliest deadline first, least slack

How to schedule multiple tasks? (contd.) • Dynamic planning-based scheduling • Schedulability checked at run time for a dynamically arriving task • “admission control” • resulting schedule to decide when to execute • Dynamic best-effort scheduling • no schedulability checking is done • system tries its best to meet deadlines

Performance Characteristics to Evaluate Scheduling Algorithms • Static case: off-line schedule that meets all deadlines • secondary metric: • maximize average earliness • minimize average tardiness • Dynamic case: no a priori guaranteed that deadline would be met • metric: • maximize # of arrivals that meet deadline

Cyclic Executive, or Static Table-driven Scheduling • Applicable to tasks that are periodic • aperiodic tasks can be converted into periodic by using worst case inter-arrival time • A table is constructed and tasks are dispatched accordingly repeatedly • feasible schedule exists iff there is a feasible schedule for the LCM of the periods • heuristics such as earliest deadline first, or shortest period first • Predictable, but inflexible • table is completely overhauled when tasks or their characteristics change

Mechanics of Cyclic Executive • Time organized into minor cycles, and a timer triggers a task every minor cycle (frame) • Non-repeating set of minor cycles comprise a major cycle that repeats continuously • Operations are implemented as procedures, and placed in a pre-defined list covering every minor cycle • When a minor cycle begins, the timer task calls each procedure in the list • No preemption: long operations must be broken to fit frames • E.g. four functions executing at rates of 50, 25, 12.5, and 6.25 Hz (10, 40, 80, and 160 ms) can be scheduled by a cyclic executive with a frame of 10 ms as below:

Priority-based Preemptive Scheduling • Tasks assigned priorities, statically or dynamically • priority assignments relates to timing constraints • static priority attractive… no recalculation, cheap • At any time, task with highest priority runs • if low priority task is running, and a higher priority task arrives, the former is preempted and the processor is given to the new arrival • Appropriate assignment of priorities allow this to handle certain types of real-time cases

Example • Task1: T1=2, C1=1; Task2: T2=5, C2=2. • Consider: Priority1 > Priority2 • Consider: Priority 2 > Priority 1 • Which works?

Some Priority-based Preemptive Scheduling Approaches • Rate Montonic algorithm by Liu & Layland • static priorities based on periods • higher priorities to shorter periods • optimal among all static priority schemes • Earliest-deadline First • dynamic priority assignment • closer a task’s deadline, higher is it priority • applicable to both periodic and aperiodic tasks • need to calculate priorities when new tasks arrives • more expensive in terms of run-time overheads • Key results on schedulability bounds!

Dispatching Cost • Normally dispatching cost assumed a small constant or is ignored during schedulability analysis • In reality, quite complicated • preemption, context-switching, readying preempted task for future resumption

Dynamic Planning-Based Approaches • Flexibility of dynamic approaches + predictability of approaches that check for feasibility • On task arrival, before execution begins • attempt made to create schedule that contains previously admitted tasks and the new arrival • if attempt fails, alternative actions

Dynamic Best Effort Approaches • Task could be preempted any time during execution • Don’t know whether timing constraint is met until the deadline arrives, or the task finishes

Other Scheduling Issues • Scheduling with fault-tolerance constraints • Scheduling with resource reclaiming • Imprecise computations

Scheduling with Fault-tolerance Constraints • Example: deadline mechanism to guarantee that a primary task will make its deadline if there is no failure, and an alternative task (of less precision) will run by its deadline in case of failure • if no failure, time set aside for alternative task is reused • Another approach: contingency schedules embedded in primary schedule, and triggered when there is a failure

Scheduling with Resource Reclaiming • Variation in tasks’ execution times • some tasks may finish sooner than expected • Task dispatcher can reclaim this time and utilize it for other tasks • e.g. non-real-time tasks can be run in idle slots • even better: use it to improve guaranteeability of tasks that have timing constraints

Imprecise Computation • Basic idea: structure computation such that if more time is given, the quality of result improves • if less time, then still have a poor quality result instead of nothing • More in a later lecture...

Implementation in Real-time OSs • Small, fast, proprietary kernels (commercial, home grown) • Real-time extensions to commercial OSs • Research OSs • Part of language run-time environments • Ada • Java (embedded real-time Java) • Monolithic kernel vs. Microkernel

Application Application Application I/O Services Device Drivers Network Drivers Kernel Mode TCP/IP Stack Hardware Comparison of Various RTOS Organizations: Cyclic Executive

Comparison of Various RTOS Organizations: Monolithic Kernel Application Application Application User Mode (protected) Kernel Mode Graphics Subsystem Filesystems I/O Managers Device Drivers Network Drivers Graphics Drivers Other…. Hardware Interface Layer Hardware

Comparison of Various RTOS Organizations: Microkernel Hardware Network Manager Network Drivers Application Graphics Drivers Photon Application Device Manager Device Drivers Application Filesystem Manager Filesystem Drivers User Mode (protected) Kernel Mode Kernel (tiny)

Some Examples • For tiny systems • PALOS • TinyOS • For mid-size systems • µCOS-II • eCos • For large-size systems • VxWorks • Real-time Linuxes

Example I: PALOS • Based on [Melkonian00] • Structure – PALOS Core, Drivers, Managers, and user defined Tasks • PALOS Core • Task control: slowing, stopping, resuming • Periodic and aperiodic handlers • Inter-task Communication via event queues • Event-driven tasks: task routine processes events stored in event queues while (eventQ != isEmpty){dequeue event; process event;} • Drivers • Processor-specific: UART, SPI, Timers.. • Platform-specific: Radio, LEDs, Sensors

Tasks in PALOS • A task belongs to the PALOS main control loop • Each task has an entry in PALOS task table (along with eventQs) • Execution control • A task counter is associated with each task • Counters are initialized to pre-defined values • 0: normal • Large positive: slowdown • -1: stop • non-negative: restart • Counters are decremented 1) every main control loop iteration (relative timing) 2) by timer interrupts (exact timing) • When counter reaches zero, the task routine is called. The counter is reset to reload value.

Event Handlers in PALOS • Periodic or aperiodic events can be scheduled using Delta Q and Timer Interrupt • When event expires appropriate event handler is called

PALOS Features • Portable • CPUs: ATmega103, ATmega128L, TMS320, STrongThumb • Boards: MICA, iBadge, MK2 • Small Footprints • Core (compiled for ATMega128L) • Code Size: 956 Bytes , Mem Size: 548 Bytes • Typical( 3 drivers, 3 user tasks) • Code Size: 8 Kbytes, Mem Size: 1.3 Kbytes • Task execution control • Provides means of controlling task execution (slowing, stopping, and resuming) • Scheduler: Multiple periodic, and aperiodic functions can be scheduled • Preliminary version v0.11 available from sourceforge https://sourceforge.net/project/showfiles.php?group_id=61125

Messaging Component Internal State Internal Tasks Commands Events Example II: TinyOS • OS for UC Berkeley’s Motes wireless sensor nodes • System composed of • Tiny scheduler • Graph of components • Single execution context • Component model • Basically FSMs • Four interrelated parts of implementation • Encapsulated fixed-size frame (storage) • A set of command handlers • A set of event handlers • A bundle of simple tasks (computation) • Modular interface • Commands it uses and accepts • Events it signals and handles • Tasks, commands, and event handlers • Execute in context of the frame & operate on its state • Commands are non-blocking requests to lower level components • Event handlers deal with hardware events • Tasks perform primary work, but can be preempted by events • Scheduling and storage model • Shared stack, static frames • Events prempt tasks, tasks do not • Events can signal events or call commands • Commands don’t signal events • Either can post tasks

TinyOS Key Claims/Facts • Stylized programming model with extensive static information • Compile time memory allocation • Easy migration across h/w -s/w boundary • Small Software Footprint • 3.4 KB • Two level scheduling structure • Preemptive scheduling of event handlers • Non-preemptive FIFO scheduling of tasks • Bounded size scheduling data structure • Power-aware: puts processor to sleep when tasks are complete • Rich and Efficient Concurrency Support • Events propagate across many components • Tasks provide internal concurrency • At peak load 50% CPU sleep • Power Consumption on Rene Platform • Transmission Cost: 1 µJ/bit • Inactive State: 5 µA • Peak Load: 20 mA • Efficient Modularity • Events propagate through stack <40 µS • Programming in C with lots of macros, now moving to NestC • http://webs.cs.berkeley.edu

/* Messaging Component Declarations *///ACCEPTS:char TOS_COMMAND(AM_send_msg)(int addr, int type, char* data);void TOS_COMMAND(AM_power)(char mode);char TOS_COMMAND(AM_init)();//SIGNALS:char AM_msg_rec(int type, char* data);char AM_msg_send_done(char success);//HANDLES:char AM_TX_packet_done(char success);char AM_RX_packet_done(char* packet);//USES:char TOS_COMMAND(AM_SUB_TX_packet)(char* data);void TOS_COMMAND(AM_SUB_power)(char mode);char TOS_COMMAND(AM_SUB_init)(); Example of a TinyOS Component

Example of an Event Handler Bit_Arrival_Event_Handler State: {bit_cnt} Start Yes Send Byte Eventbit_cnt = 0 bit_cnt==8 bit_cnt++ Done No

Complete TinyOS Application Ref: from Hill, Szewczyk et. al., ASPLOS 2000

Example III: µCOS-II • Portable, ROMable, scalable, preemtpive, multitasking RTOS • Up to 63 statically declared tasks • Services • Semaphores, event flags, mailboxes, message queues, task management, fixed-size memory block management, time management • Source freely available for academic non-commercial usage for many platforms • http://www.ucos-ii.com • Value added products such as GUI, TCP/IP stack etc. • Book “MicroC/OS-II: The Real-Time Kernel” describes the internals

Example IV: eCos • Embedded, Configurable OS • Open-source, from RedHat • Designed for devices lower-end than embedded Linux • Several scheduling options • bit-map scheduler, lottery scheduler, multi-level scheduler • Three-level processing • Hardware interrupt (ISR), software interrupt (DSR), threads • Inter-thread communication • Mutex, semaphores, condition variables, flags, message box • Portable • Hardware Abstraction Layer (HAL) • Based on configurable components • Package based configuration tool • Kernel size from 32 KB to 32 MB • Implements ITRON standard for embedded systems • OS-neutral POSIX compliant EL/IX API

Example V: Real-time Linuxes • Microcontroller (no MMU) OSes: • uClinux - small-footprint Linux (< 512KB kernel) with full TCP/IP • QoS extensions for desktop: • Linux-SRT and QLinux • soft real-time kernel extension • target: media applications • Embedded PC • RTLinux, RTAI • hard real time OS • E.g. RTLinux has Linux kernel as the lowest priority task in a RTOS • fully compatible with GNU/Linux • HardHat Linux

Embedded System S/W Organization & Static Scheduling