RealTime Design Guidelines and Rules of Thumb Embedded
Real-Time Design Guidelines and Rules of Thumb Embedded Systems Conference Boston 2011 ESC-309 Dave Stewart, Ph. D Director of Research and Systems Integration In. Hand Electronics dstewart@inhand. com www. inhand. com (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 1 Embedded Systems Conference Boston, September 2011
Class Objective n To provide some guidelines and rules of thumb to quickly make the right decisions when designing and implementing real-time systems, even if you don’t have an in-depth theoretical or practical real-time systems experience. n Guideline: Generally a good practice to follow n Rule of Thumb: quick decision or approximation n Caution: Common Pitfall to Avoid (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 2 Embedded Systems Conference Boston, September 2011
Contents I. Choosing the Right Environment II. Software Decomposition III. Practical Real-Time Scheduling IV. Interprocess Communication V. Implementation Solutions (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 3 Embedded Systems Conference Boston, September 2011
I. Choosing the Right Environment n Hard vs. soft real-time n Predictable systems n Preemption n Operating systems vs. executives (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 4 Embedded Systems Conference Boston, September 2011
Terminology n Hard Real-Time n Timing requirements must be met precisely n n Failure to meet requirements leads to significant failure § catastrophic (system is destroyed) § damage to environment or injury to people § economic (product fails in the market place) Soft Real-Time n There is some flexibility in the timing constraints (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 5 Embedded Systems Conference Boston, September 2011
Hard or Soft? n Are these applications Hard or Soft real-time? n n n n Flight Control System Bottling Plant Production Line Anti-Lock Braking System DVD Playback Airline Reservation System Internet Video Cellular Phone RF Reception (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 6 Embedded Systems Conference Boston, September 2011
Hard or Soft? n Are these applications Hard or Soft real-time? n n n n Flight Control System Soft Bottling Plant Production Line Anti-Lock Braking System DVD Playback Airline Reservation System Internet Video Cellular Phone RF Reception Hard Soft Hard My Opinion Any Surprises? (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 7 Embedded Systems Conference Boston, September 2011
Soft Real-Time as a Spectrum n n Almost all applications can be soft real-time Sometimes, one or more timing constraints are hard n n n Right-most end of spectrum Rarely are all timing constraints hard Few applications are non-real-time n Left-most end of spectrum Soft Not RT Computer Simulation Hard User Interface Internet Video (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com Temperature Control 8 Flight Control Wireless Electronic Communication Engine Embedded Systems Conference Boston, September 2011
Real vs. Artificial Constraints n Real n n n Artificial n n n There is no flexibility in the timing constraint. If it is changed or relaxed, the system will fail. Eg. 150 msec window for filling bottle on conveyor belt. Timing constraint was determined somewhat arbitrarily. E. g. 40 Hz rate for cruise control. Important to distinguish between Real and Artificial: n n Artificial constraints can be refined, possibly improving other design factors (like cost & functionality) Real constraints must be met at any cost. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 9 Embedded Systems Conference Boston, September 2011
Terminology n Predictable n n n Deterministic n n n The system operates within known bounds. Exact order of operations is not always known. A special (extreme) case of predictable. The system operates with exact order of operations known at all times. A Real-Time System’s timing behavior needs to be Predictable, but seldom Deterministic (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 10 Embedded Systems Conference Boston, September 2011
Example n Dice: Predictable or Deterministic? (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 11 Embedded Systems Conference Boston, September 2011
How do we make a System Predictable? § Maximize periodic activities § Minimize aperiodic (random) activities § § § § Avoid unnecessary preemption Choose appropriate scheduling strategies Eliminate interrupts Use deferrable or sporadic server for aperiodic tasks Use only “guaranteed” soft real-time tasks Measure execution time to monitor resource usage Implement proper timing error detection and handling (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 12 Embedded Systems Conference Boston, September 2011
Terminology n Periodic n n Code that executes at regular intervals Rate refers to how often task executes: n n Period = 1/Rate. n n E. g. 50 Hz (50 times per second) E. g. 1/(50 Hz) = 20 msec. Aperiodic n n Code that executes irregularly or randomly. Minimum inter-arrival time is shortest amount of time between two successive aperiodic events. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 13 Embedded Systems Conference Boston, September 2011
Periodic n In Real-Life, is it easier to schedule? n n n 1 hr meeting at the same time each day? 1 hr meeting at the same time each week? 4 hr meeting at the same time each week? 1 hr meeting twice a week, but time changes? Real-Time is like real-life. It is easier to schedule: n n n Tasks that are periodic instead of irregular Less frequent tasks Shorter tasks (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 14 Embedded Systems Conference Boston, September 2011
KISS Principle n From the Jargon Dictionary: n n KISS Principle /kis' prin'si-pl/ n. “Keep it short and simple” Periodic Tasks help KISS. n n n Execute each task as slow as possible Execute each task for as little time as possible Anything else adds complexity (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 15 Embedded Systems Conference Boston, September 2011
Preemption n Do you need it? n Is it helping or hurting your application? (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 16 Embedded Systems Conference Boston, September 2011
Preemption: When it Helps n Wide variety of periods and execution times n n n If freq of fastest task < 100 * freq of slowest task, then the task set is likely schedulable without preemption Multiple applications sharing the processor RT and non-RT tasks sharing a processor Hard and soft RT tasks sharing the processor More tolerant to design-time mistakes n But this leads to laziness at design time (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 17 Embedded Systems Conference Boston, September 2011
Preemption: What it Costs n n n n n Reduces predictability Increases overhead (scheduling, context switch) Possible race conditions Introduces possibility of priority inversion Significant increase in overhead to avoid race conditions and priority inversion Reduces schedulable bound if blocking is allowed More difficult to test and debug Potential for deadlock if blocking occurs Estimate at least 25% increase in CPU usage for a preemptive system, compared to non-preemptive. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 18 Embedded Systems Conference Boston, September 2011
Preemption: Do You Need It? n Use KISS to decide: n n n If your application needs it, preemption can be a tremendous benefit to reduce complexity. If you don’t need it but use it, your application will be much more complex than necessary. The best compromise might be limited preemption. n more later (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 19 Embedded Systems Conference Boston, September 2011
Real-Time Operating Systems (RTOS) n Every RTOS provides preemption. n Why don’t any provide the option of non-preemption? (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 20 Embedded Systems Conference Boston, September 2011
Non-Preemptive RTOS n Called “Real-Time Executive” (RTE) n n n I don’t need preemption, so I don’t need an RTOS? n n There are no COTS RTEs because they can be implemented in 5 to 10 lines of code. You can’t sell 10 lines of code for $3000. Maybe I need preemption, so I need an RTOS? n Yes COTS: Commercial Off-The-Shelf (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 21 Embedded Systems Conference Boston, September 2011
COTS RTOS n When do I use an RTOS? n n n You determine preemption is necessary Lots of COTS input/output devices, like VGA monitor, USB serial ports, touchscreen, ethernet, etc. You are using advanced CASE tools to design and implement software CASE: Computer-Aided Software Engineering (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 22 Embedded Systems Conference Boston, September 2011
COTS RTOS n Roll my own RTOS vs. COTS RTOS n n If you don’t have a degree in RTOS design, always use COTS Roll your own only if you are an expert in the field, and there are extenuating circumstances requiring it. E. g. n n n Using RT mechanisms not available in commercial RTOS Domain-specific certifications require 100% control of source code If you roll your own, use a “free” RTOS as a starting point (eg u. COS, RTLinux) You are in the business of selling RTOS technology Licensing costs: n n Must compare cost of license(s) to cost of labor. More often than not, cost of labor is substantially higher (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 23 Embedded Systems Conference Boston, September 2011
Real-Time Executive n When do I use a Real-Time Executive? n n You determine preemption is not necessary Most or all of the I/O is custom You need 100% control of all code on the processor for software certification Extreme processor resource constraints n n RAM or ROM < 10 KBytes CPU speed < 10 MHz (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 24 Embedded Systems Conference Boston, September 2011
Real-Time Executive n Roll my own? n n Yes, because there are no commercial ones Use a Commercial or Free IDE that provides the compiler, standard libraries, and debugging tools Do NOT hard-code the process flow. That’s not an RTE, its just hacked code. An expert should design the core RTE engine, so that user tasks simply “plug in” to the framework. IDE: Integrated Development Environment (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 25 Embedded Systems Conference Boston, September 2011
II. Software Decomposition n Circular Dependencies are BAD n Use a Data Flow Architecture n Model of a Real-Time Task (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 26 Embedded Systems Conference Boston, September 2011
Circular Dependencies are BAD n Circular Dependencies are the primary cause of “spaghetti code” n Use Dependency Trees to spot and remove circular dependencies n Eliminating circular dependencies provides the following benefits: n n Component reusability Fault confinement Incremental testing Modularized performance and timing analysis (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 27 Embedded Systems Conference Boston, September 2011
Dependency Tree Example abc def ghi jkl mno pqr ghi stu uvw abc jkl mno pqr xyz def ghi stu uvw jkl mno pqr xyz stu uvw xyz A circular dependency changes the tree into a graph. Avoid circular dependencies at (almost) all costs. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 28 Embedded Systems Conference Boston, September 2011
Avoiding circular dependencies n Never have a single “globals. h” or equivalent file with all header information. n Instead, one. h file per “module” n n n Only put exported declarations in the. h file. Data structures that are private should be defined in the. c file, not in the. h file. If a module is dependent on another, only then should it include the. h file of the other module. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 29 Embedded Systems Conference Boston, September 2011
Breaking Circular Dependencies replace ghi with ghi jkl shared This is not always easy. It will force careful reconsideration of the design. Re-designing to satisfy dependency requirements will result in software that is substantially easier to maintain. Additional details is beyond the scope of this class. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 30 Embedded Systems Conference Boston, September 2011
Use a Data-Flow Architecture n Every task is independent n n Use the dependency tree to verify this Only use explicit Interprocess Communication to exchange data between tasks Bad task A task B task A (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com Good task A task B 31 task A task B ipc Embedded Systems Conference Boston, September 2011
Use a Data-Flow Architecture n Independent tasks enable use of real-time scheduling n Without real-time scheduling, timing constraints cannot be guaranteed (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 32 Embedded Systems Conference Boston, September 2011
Data Flow Architecture Example (Cruise Control System) f ra accel engine accelerator pedal brake + – split-pm = frb + – fde force to engine fdw wheels brake pedal ccui Ur fd vz control vr cruise control user interface position force to wheels xz dx/dt wheel position resolver (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com Start with outputs then produce diagram right to left. dashboard speedometer 33 odometer Embedded Systems Conference Boston, September 2011
Model of a Real-Time Task : Configuration Constants k 1 kp x 1 IPC Input : xm real-time task y 1 : IPC Output ym : r 1 rp Sensor Inputs and Control Outputs (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 34 Embedded Systems Conference Boston, September 2011
Model of a Real-Time Task Each task has a main loop that does the following: For periodic tasks, event is time-based. Wait for Event For other tasks, event could be an interrupt, message arrival, semaphore wakeup, or any other signal. Read Inputs/Events Do Processing Write Outputs (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 35 Embedded Systems Conference Boston, September 2011
Proper Implementation of Periodic Tasks n DO (use a framework and “wait until” to ensure no clock skew) nextstart = clock(); while (1) { nextstart += period; wait until period // wait for timer event call task->cycle() } n DON’T (implement timing inside task, and use sleep that causes clock skew) task. Main() { laststart = clock(); while (1) { delta = period – (clock() – lasttime); sleep(delta); // wait for timer event do stuff } } n Additional examples when real-time scheduling examples are presented. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 36 Embedded Systems Conference Boston, September 2011
Proper Implementation of Aperiodic Tasks n Use Aperiodic Servers n More details near end of this talk. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 37 Embedded Systems Conference Boston, September 2011
III. Practical Real-Time Scheduling n Your Life is a Real-Time System n Cyclic executives n Rate monotonic algorithm n Dynamic scheduling (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 38 Embedded Systems Conference Boston, September 2011
Practical Real-Time Scheduling n Now: Hard Real-Time Periodic Tasks n n n Non-Preemptive Fixed Priority Dynamic Priority Later: n n Interrupts Aperiodic servers Soft real-time tasks Limited preemption (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 39 Embedded Systems Conference Boston, September 2011
Your Life IS a Real-Time System (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 40 Embedded Systems Conference Boston, September 2011
Real-Life Scheduling n If you have 10 tasks to do, what order to you do them in? n If you go to the bank, in what order are you served? n If you need to catch a flight at 5 pm, how does that affect your schedule? n If it is lunch time and you have a report due at 3 pm, do you stop for lunch? n If the report is due at 7 pm, do you stop for lunch? n These same kinds of decisions must be made for each task in a real-time system. That’s real-time scheduling. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 41 Embedded Systems Conference Boston, September 2011
Basic Cyclic Executive n Everything executes at same rate n n Example: 3 Tasks Each task executes every 20 msec (TA=TB=TC=20) n n n A 0 Note: Ti=Period of Task i Execution time constraints: n n A B SCi < TA Note: Ci=Worst Case Execution Time of Task i C Suitable for simple control loops. B C A B C 20 (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com A 40 42 B C A 60 B C time (msec) Embedded Systems Conference Boston, September 2011
Basic Cyclic Executive Implementation typedef void (*funcptr)(void); void A(void) { // B and C defined similarly //code goes here } See paper for details on implementing the timer. funcptr cyclic[] = { A, B, C}; const int cycliclength = sizeof(cyclic)/sizeof(funcptr); A cyclicexec(funcptr cyclic[], int cycliclength, int cycletime) { int i; intr. Set. Period(20 msec); while (1) { intr. Wait(); for (i=0; i<cycliclength; ++i) cyclic[i](); } } A 0 B C A B C 20 (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com A 40 43 B B C C A 60 B C time (msec) Embedded Systems Conference Boston, September 2011
Multi-Rate Cyclic Executive n Tasks execute at different rates n n Example: 3 Tasks A executes every 20 msec (TA=20) B and C execute every 40 msec (TB=TC=40) Execution time constraints: n A 0 CA+CB < TA && CA+CC < TA B A C 20 (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com A 40 44 B A 60 C time (msec) Embedded Systems Conference Boston, September 2011
Multi-Rate Cyclic Executive Implementation typedef void (*funcptr)(void); void A(void) { // B and C defined similarly //code goes here } funcptr cyclic[] = { A, B, NULL, A, C, NULL}; const int cycliclength = sizeof(cyclic)/sizeof(funcptr); cyclicexec(funcptr cyclic[], int cycliclength, int cycletime) { int i; intr. Set. Period(20 msec); while (1) { for (i=0; i<cycliclength; ++i) { if (cyclic[i]==NULL) intr. Wait(); else cyclic[i](); } } A 0 B A C 20 (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com A 40 45 B A 60 C time (msec) Embedded Systems Conference Boston, September 2011
Multi-Rate Cyclic Executive n Rates for each task are constrained: n n Periods of each task must be harmonic To setup schedule, place fastest task in schedule first Then place next fastest, and so on. Execution time is constrained: n SCi for tasks executing each cycle must be less than period of interrupt. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 46 Embedded Systems Conference Boston, September 2011
Harmonic Task Set n Period of Task K is multiple of every faster task n n Examples of Harmonic: n n "k>1, Tk=nk*Tk-1, k, nk are integers 10, 20, 40, 80, 160 10, 30, 120, 480 20, 100, 2000 Examples of Non-Harmonic: n n n 10, 25, 50, 75 10, 30, 100, 500 20, 120, 2200 (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 47 Embedded Systems Conference Boston, September 2011
Dynamic Multi-Rate Cyclic Executive n Relaxes constraints on period and execution time n Uses Earliest-Deadline First (EDF) Algorithm n n n Rate/Period constraints: n n none Execution Time constraints: n n Task with earliest deadline executes next Deadline of current cycle is time task is ready for next cycle S(Ui) <1 (i. e. CPU not overloaded) Note: Ui=Ci/Ti=Utilization of Task I Ci for each task is < T 1/2 i. e. period of fastest task dictates max execution time for every other task Cost of using this method: n n Increased RTE complexity Requires more thorough analysis to guarantee scheduling feasibility (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 48 Embedded Systems Conference Boston, September 2011
Implementation of Dynamic Multi-Rate Cyclic Executive while (1) { do { etime. Clock(&now); // Move newly awoken tasks from Pause. Q to Ready. Q while (!task. Empty. Q(pause. Q) && Sched. Time(pause. Q), now) <= 0) { taskptr=task. Dequeue(&pause. Q); etime. Add(taskptr>schedtime, taskptr->period); task. Enqueue(&ready. Q, taskptr); } } while (ready. Q. next == NULL); etime. Compare(task // Head of ready. Q has earliest-deadline task. Dequeue(&ready. Q, taskptr); taskptr->func(args); task. Enqueue(&pause. Q, taskptr); } (note, some detail has been omitted) (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 49 Embedded Systems Conference Boston, September 2011
Preemptive Scheduling n Always execute task with highest priority, even if it means preempting a task with lower priority. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 50 Embedded Systems Conference Boston, September 2011
How are Priorities Assigned? n Fixed Priority n n Dynamic Priority n n Priorities assigned prior to execution Priorities are Constant E. g. Rate Monotonic Algorithm (RMA) Priorities change as a function of time E. g. Earliest-Deadline-First Algorithm (EDF) E. g. Minimum-Laxity-First Algorithm (MLF) Mixed Priority n n Priorities include both a fixed part and dynamic part E. g. Maximum-Urgency-First Algorithm (MUF) (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 51 Embedded Systems Conference Boston, September 2011
Terminology n Transient Overload: n n Guaranteed Task: n n The set of all tasks sharing a processor. Critical Task Set: n n A task is said to be guaranteed if it will always meet its deadlines, even in a transient overload situation. Hard real-time tasks must be guaranteed tasks. Task Set: n n The state of a real-time system when at least one task will fail to meet its timing constraints because of a lack of resources. The set of guaranteed tasks (a subset of the task set). Schedulable Task Set n n All tasks in the task set are guaranteed tasks. No task ever misses a deadline. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 52 Embedded Systems Conference Boston, September 2011
Preemptive Scheduling Example n Consider a very simple system with two tasks: n n n P 1: T 1= 50 msec, C 1=25 msec, U 1=50%. P 2: T 2=100 msec, C 2=40 msec, U 2=40%. U 1+U 2=90%. Since utilization is less than 100%, we would expect that both tasks can be scheduled without either missing deadlines. Using Fixed-Priority Scheduling, only two scenarios: n n Case 1: Priority P 1 > Priority P 2 Case 2: Priority P 1 < Priority P 2 missed deadline: a timing error where a task does not complete its execution in time. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 53 Embedded Systems Conference Boston, September 2011
Case 1 n Priority P 1 > Priority P 2 n n 0 10 P 1 P 2 P 1: T 1= 50 msec, C 1=25 msec, U 1=50%. P 2: T 2=100 msec, C 2=40 msec, U 2=40%. 20 30 40 50 60 70 80 1 st deadline P 1 meets 1 st deadline (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 100 110 2 nd deadline P 1 1 st deadline P 2 P 1 meets 2 nd deadline 54 90 P 2 meets 1 st deadline Embedded Systems Conference Boston, September 2011
Case 2 n Priority P 1 < Priority P 2 n n 0 P 1 P 2 P 1: T 1= 50 msec, C 1=25 msec, U 1=50%. P 2: T 2=100 msec, C 2=40 msec, U 2=40%. 10 20 30 40 50 60 1 st deadline P 1 meets 1 st deadline P 1 misses 1 st deadline P 1 restarts (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 55 70 80 90 100 110 2 nd deadline P 1 1 st deadline P 2 P 1 meets P 2 meets 2 nd deadline 1 st deadline Embedded Systems Conference Boston, September 2011
Rate Monotonic Algorithm (RMA) n An algorithm for assigning fixed priorities n n The higher the frequency (or shorter the period) of a task, the higher its priority. Case 1 was an example of using RMA assignments. n n Notice how Case 1 resulted in all tasks meeting their deadlines. Case 2 resulted in some one of the two tasks missing deadlines. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 56 Embedded Systems Conference Boston, September 2011
Rate Monotonic Algorithm (RMA) n Advantages n Optimal fixed priority scheduling algorithm n n n If a task set cannot be scheduled using RMA, then it cannot be scheduled using any other fixed priority assignment. If there is a transient overload, it is guaranteed that the lowest priority tasks not in the critical task set are the ones that can fail. Disadvantages n Schedulable bound often less than 100% if task set is not harmonic n n Schedulable bound is the maximum utilization of the critical task set. Example: See Case 3 (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 57 Embedded Systems Conference Boston, September 2011
Case 3: Like Case 1 but C 2 & T 2 Change; U 2 Unchanged n Priority P 1 > Priority P 2 n n 0 10 P 1 P 2 P 1: T 1= 50 msec, C 1=25 msec, U 1=50%. P 2: T 2= 75 msec, C 2=35 msec, U 2=40%. 20 30 40 50 60 70 80 1 st deadline P 2 1 st deadline P 1 90 100 110 2 nd deadline P 1 meets 1 st deadline P 2 misses 1 st deadline (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 58 Embedded Systems Conference Boston, September 2011
Rate Monotonic Algorithm (RMA) n Even though Utilization only 90% RMA cannot schedule this task set n RMA Rules of thumb: n n n To achieve 100% schedulable utilization using RMA, task set must be harmonic. If task set is not harmonic, schedulable utilization can be as low as 70%. To Achieve 100% Utilization with non-harmonic task sets, must use Dynamic Scheduling n For example, see Case 4. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 59 Embedded Systems Conference Boston, September 2011
Deadline Monotonic Algorithm n A Variation of RMA, except that deadline of a task can be earlier than start of next period. n n Designed to reduce jitter of executing tasks. Problems with Deadline Monotonic Algorithm: n n n Schedulable bound lower than RMA In my experience 99% of the time, jitter is not an issue. Don’t use it! (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 60 Embedded Systems Conference Boston, September 2011
Case 4: Like Case 3 but use EDF Scheduling n Priority P 1, P 2 = F(deadline) n n 10 P 1 P 2 P 1: T 1= 50 msec, C 1=25 msec, U 1=50%. P 2: T 2= 75 msec, C 2=35 msec, U 2=40%. 20 30 40 50 60 70 80 90 100 110 1 st deadline 2 nd deadline P 2 P 1 P 1 meets P 2 meets 2 nd deadline 1 st deadline 2 nd deadline (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 61 Embedded Systems Conference Boston, September 2011
Earliest Deadline First n Advantages n Schedulable bound is always 100%. n n Optimal dynamic priority scheduling algorithm n n All tasks are in critical set if utilization < 100% If a task set cannot be scheduled using EDF, then it cannot be scheduled using any other algorithm. Disadvantages n If there is a transient overload, there is no control over which task fails. n None of the tasks are in critical set if utilization >= 100% (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 62 Embedded Systems Conference Boston, September 2011
Mixed Priority Scheduling n Combines the Advantages of RMA and EDF n n n Various Options to Mixed-Priority Scheduling n n n Schedulable bound of 100% for critical task set In case of transient overload, critical task set can still be guaranteed E. g. Maximum-Urgency-First (MUF) E. g. Limited Preemption Rate Groups Mixed-priority scheduling is a more advanced topic; more discussion later. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 63 Embedded Systems Conference Boston, September 2011
Baseline Scheduling What Method Should You Use? n Non-Preemption n n n n Basic cyclic executive Multi-rate cyclic executive Dynamic cyclic executive Rate monotonic algorithm Earliest-deadline-first algorithm More complex mixed-priority algorithm Answer: KISS Principle Pick the simplest one that meets your needs. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 64 Embedded Systems Conference Boston, September 2011
Other Considerations n Other design needs may alter the choice of a basic scheduling method. For example: n n n n Interprocess communication Aperiodic events Soft real-time support Interaction with non-real-time systems Dynamic system configuration changes Overloaded resources I/O requirements These and other issues discussed next. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 65 Embedded Systems Conference Boston, September 2011
IV. Interprocess Communication n Race conditions n Semaphores n Priority inversion n Real-time IPC mechanisms (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 66 Embedded Systems Conference Boston, September 2011
Interprocess Communication n Real-Time Applications are built as collections of tasks executing at one or more rates. n Tasks exchange data through IPC. n If done incorrectly, IPC is one of the primary sources of problems in RT Systems. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 67 Embedded Systems Conference Boston, September 2011
Non-Preemptive Environments n Use Shared Memory between tasks. n n Fastest form of IPC No RTE overhead to access shared data No concern of race conditions since tasks accessing the shared data cannot be preempted. If there are interrupts, they can preempt non-preemptive tasks. n Must be treated as a preemptive environment from an IPC perspective, if the interrupt handler shares memory or resources with any of the tasks. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 68 Embedded Systems Conference Boston, September 2011
IPC in Preemptive Environments n Shared Memory and Resources Cause Problems. n This includes: n n n Global variables Static local variables Shared memory segments I/O device registers Library functions that are not “Multi-Tasking Safe” (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 69 Embedded Systems Conference Boston, September 2011
Race Conditions n The main problem with sharing in preemptive environments is ensuring data does not get corrupted due to a race condition. The One Lane Bridge is Shared. It is an analogy for a shared variable. If Trains do not take special precautions, an accident will occur. If software doesn’t take precautions, data corruption will occur. This is a Race Condition. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 70 Embedded Systems Conference Boston, September 2011
Semaphores n A “Semaphore” is a traffic light The One Lane Bridge is Shared. It is an analogy for a shared variable. If Trains do not take special precautions, an accident will occur. If software doesn’t take precautions, data corruption will occur. This is a Race Condition. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 71 Embedded Systems Conference Boston, September 2011
Semaphores n Semaphores are a common solution in operating systems to deal with race conditions. n In real-time systems they lead to priority inversion. n In fact, any IPC mechanism that involves blocking, including monitors, condition variables, and message passing, can lead to priority inversion. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 72 Embedded Systems Conference Boston, September 2011
Priority Inversion n Blocking of a high priority task due to a lower priority task locking a shared resource. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 73 Embedded Systems Conference Boston, September 2011
Priority Inversion Shown by Example n Assume 3 Tasks: n n n PH: A high priority task PM: A medium priority task PL: A low priority task (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 74 Embedded Systems Conference Boston, September 2011
Priority Inversion Shown by Example (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 75 Embedded Systems Conference Boston, September 2011
Solutions to Priority Inversion n There are two fundamental ways to deal with race conditions while avoiding priority inversion: n n Use a mechanism that adjusts priorities of low-priority tasks holding resources. Use a non-blocking mechanism. WARNING! Many RTOS provide blocking IPC mechanisms that do not adjust priorities. Do NOT use these mechanisms in Real-Time Systems! (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 76 Embedded Systems Conference Boston, September 2011
Adjusting Priorities: Priority Inheritance Protocol n Warning: For demonstration only. Not a good protocol. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 77 Embedded Systems Conference Boston, September 2011
Adjusting Priorities: Priority Inheritance Protocol PL gets R 1 PL starts PH needs R 1 PH starts PL PH releases ends R 1 PM PH starts releases R 1 PM ends PL ends PH PM PL ^^^^^^^^^^^^^^^^^^^^ PM does not execute, because priority of PL is temporarily higher due to priority inversion PL assumes priority of PH (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 78 state of task suspended ready to running blocked, waiting for R 1 ^^^^^ holding R 1 Embedded Systems Conference Boston, September 2011
Adjusting Priorities Priority Ceiling Protocol (PCP) n Highest Locking Protocol (HLP) is very similar. n n n Advantage: n n Similar to Priority Inheritance, except that each resource is given a priority ceiling, which is the priority of the highest-priority task that may lock the resource. When a resource is locked, task immediately inherits the priority ceiling. It Works Disadvantages: n n n Significant RTOS overhead Significant reduction in schedulable bound due to blocking Many RTOS do not provide this mechanism (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 79 Embedded Systems Conference Boston, September 2011
Non-Blocking RT IPC n The alternative to PCP is to use a non-blocking form of communication. Some examples: n n State variable mechanism Non-blocking message passing Triple-buffer mechanism FIFOs (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 80 Embedded Systems Conference Boston, September 2011
State Variable (SVAR) Communication n n Different versions for different environments Used in state-based design to store “states. ” n n E. g. “velocity” of a vehicle can be a state variable in a cruise control system, because only the current speed is important. Key attribute of states: n n Only the most recent data is needed. Allows tasks executing at different rates to communicate with each other: n n If a producer is faster than a consumer, then the consumer may miss some variable changes. If a producer is slower than a consumer, then the consumer may read the same value multiple times. State data is “small”, so that a task can lock out interrupts (thus preventing preemption) for a few microseconds to update the state. Each module reads the state and makes a local copy before executing each cycle, then updates the state after completion of its cycle. It does not access the state variables at any other time. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 81 Embedded Systems Conference Boston, September 2011
SVAR Architecture Non-Preemptive Environment Global Table Intr A 1 (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com task A 2 82 task Ak Embedded Systems Conference Boston, September 2011
SVAR Architecture Non-Preemptive with Interrupts Global Table local table task A 2 task Ak Intr A 1 (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 83 Embedded Systems Conference Boston, September 2011
SVAR Architecture Preemptive Single Processor Global Table local table task A 1 task A 2 task Ak (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 84 Embedded Systems Conference Boston, September 2011
Example Consider following Data-Flow ndof xm dh gfwdkin ndof xm tball qm cinterp xd vr ginvkin rmms xr from trackball (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com dh qr from sensors 85 wm to actuators Embedded Systems Conference Boston, September 2011
SVAR Global and Local Tables Contain Data as Follows Global Table: xd Local Tables: PBOs: vr xd tball xr. xd xm xr xr cinterp (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com qm qr xm xr DH NDOF ginvkin 86 qr wm DH NDOF q m. NDOF DH xm q r qm. DH NDOFwm gfwdkin rmms Embedded Systems Conference Boston, September 2011
SVAR Architecture Multiprocessor Shared Memory Environment Global Table memcpy() or DMA local table task A 1 Task Aj Task K 1 Task kj Processor A (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com Processor L 87 Embedded Systems Conference Boston, September 2011
SVAR Architecture Network Environment Processor X data server Global Table network messages data client local table Task K 1 Task kj Processor A (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com Processor L 88 Embedded Systems Conference Boston, September 2011
Non-Blocking Message Passing n Just Like Regular Message Passing, Except: n n n Sending: if message queue is full, abort operation and continue. Receiving: if message queue is empty, return immediately without data. In such cases, it is important to design the system to properly handle the above cases. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 89 Embedded Systems Conference Boston, September 2011
Messages vs. States n In most cases, messages can be converted to states, and vice versa. n Messages are best used for real-time client/server architectures. n States are best used in feedback control applications. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 90 Embedded Systems Conference Boston, September 2011
Using Messages, “Apply Brake”: “apply brake” RECEIVE (&message) IF message == apply “ brake ” “apply brake” activate brake RECEIVE (&message) ELSE IFmessage == apply “ brake ” : activate brake ELSE SEND(“apply brake ”). . . : brake 2 brake 1 control module Using States, “The Brakes Should be ON”: brake ON global table (shared memory) brake ON local table brake = ON. . . control module (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com brake ON local table IF brake == ON activate brake ELSE. . . brake 1 91 IF brake == ON activate brake ELSE. . . brake 2 Embedded Systems Conference Boston, September 2011
Triple Buffer Mechanism n n n Used for point-to-point state communication Does not require any hardware or RTOS support Three (or more) copies of the data exist. No two tasks ever read and write from the same copy at the same time. When a writer finishes, it marks the buffer as ‘new’, and moves on to a different buffer. Always at least one buffer not being used by other tasks. n This eliminates the need to tightly synchronize readers and writers. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 92 Embedded Systems Conference Boston, September 2011
Triple Buffer Mechanism (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 93 Embedded Systems Conference Boston, September 2011
FIFOs (First-In-First-Out) n n Similar to triple-buffer mechanism, except that it guarantees all data is available. Similar to message passing, but with less overhead and suitable for large volume of data. On average, consumer must be at least as fast as producer, otherwise data loss can occur. Can be used for communication between real-time and non-real-time tasks. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 94 Embedded Systems Conference Boston, September 2011
Other RT IPC n There are hundreds (or thousands) of real-time IPC mechanisms described in the literature. n Most RTOS only implement zero to one or two of them. You may find you need to implement your own. n Consider IPC in conjunction with scheduling. If scheduling can prevent race conditions, then you don’t need complex IPC. Instead, you can just use simple shared memory. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 95 Embedded Systems Conference Boston, September 2011
V. Implementation Solutions n Timing failure detection and handling n Soft real-time scheduling n Interrupts and aperiodic events n Dynamic system configuration changes n Timing anomalies (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 96 Embedded Systems Conference Boston, September 2011
Timing Failure Detection and Handling n Examples of Timing Errors: n n n n Missed deadline Using too much execution time End-to-end response time too long Incorrect sampling or control rate Clock skew Too much jitter Inaccurate system or real-time clock (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 97 Embedded Systems Conference Boston, September 2011
Online Timing Error Detection and Handling n An RTOS, RT Executive, or component framework may include built-in mechanisms to detect some timing errors. n n Example to follow considers missed deadline and using too much execution time. Used as the basis for implementing guaranteed soft real-time tasks and aperiodic servers. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 98 Embedded Systems Conference Boston, September 2011
Timing Failure Handler (TFH) Implementation n n Requires a Spare Timer Each time a new task is being swapped in, scheduler programs timer with lesser of the following two values: n n n task’s deadline; set type to DEADLINE estimated remaining execution time; set type to MAXEXEC Interrupt handler for this timer is defined as follows: n (see next slide) (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 99 Embedded Systems Conference Boston, September 2011
TFH Implementation tfhhandler(int type) { switch (type){ case DEADLINE: /* missed deadline */ set_priority(Ph); nextstart += Tds; set_deadline(nextstart, Cds, Tds); return; case MAXEXEC: /* execution time used up */ set_priority(Pl); return; } /* end switch */ } n n D. B. Stewart and P. K. Khosla, “Mechanisms for Detecting and Handling Timing Errors, ” Communications of the ACM, v. 40, n. 1, pp. 87 -94, January 1997. http: //www. embedded-zone. com/bib/mags/cacm 97. shtml (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 100 Embedded Systems Conference Boston, September 2011
TFH Implementation n If DEADLINE error n n Ensure task has its normal priority. This task will continue executing in time allotted for its next period. Thus it now has a new deadline at end of next period. Task will be forced to skip its next period to reclaim the time, resulting in a missed cycle. If MAXEXEC error n n The amount of reserved execution time by this task has been used up. Lower priority of task, so that other high priority tasks can execute. If there is leftover CPU time, then this task will execute. When it is done, its priority gets raised back to normal on next cycle. If there is insufficient CPU time, a DEADLINE error will follow. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 101 Embedded Systems Conference Boston, September 2011
Timing Failure Handler Uses n Guaranteed Soft Real-Time Tasks n n Aperiodic Servers n n Use the TFH to detect missed timing constraints, then update the tasks accordingly Use the TFH to detect aperiodic events that use more than budgeted capacity, and use that to manage priorities and schedule Above items are described next. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 102 Embedded Systems Conference Boston, September 2011
Soft Real-Time Scheduling n Soft real-time systems are always one of the following two: n n n Accidental Soft Real-Time Guaranteed Soft Real-Time Most systems claimed to be soft real-time are accidental soft real-time (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 103 Embedded Systems Conference Boston, September 2011
Accidental Soft Real-Time n These are systems that are claimed to be soft real-time, but in reality they do not provide any real-time guarantees. n Typical “features” of such systems: n n System can usually keep up to real-time. If the system fails to meet its timing requirement, the system does not crash, but the result still appears to meet requirements. Tried to get hard real-time, but failed. Possible starvation of the soft real-time tasks. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 104 Embedded Systems Conference Boston, September 2011
Guaranteed Soft Real-Time n It is acceptable for the primary timing constraints to not always be met. n There is a secondary set of timing requirements that are always met. n Guarantee of no starvation of any soft real-time task. n Actively modify scheduling to provide degraded performance during transient overloads. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 105 Embedded Systems Conference Boston, September 2011
Using TFH to Implement Guaranteed Soft Real-Time Tasks n Suppose a task has the following execution profile: 100% 80% 50% 0% 0 10 26 20 30 40 exec time WCET=40 msec. 80% of the time, task uses 26 msec or less. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 106 Embedded Systems Conference Boston, September 2011
Using TFH to Implement Guaranteed Soft Real-Time Tasks n Suppose a task has the execution profile on previous slide: n n n n If task is hard real-time, then 40 msec must be reserved. If task has a period of 60 msec, then utilization for the task U=40/60=66. 7%. If task is soft real-time, then set its capacity to 26 msec. Then U=26/60=43%. If execution takes less than 26 msec (as happens 80% of the time), then task will meet its deadline. If execution takes more than 26 msec, MAXEXEC error is generated. Task gets lower priority for any execution time greater than 26 msec until its deadline time is reached. If task misses deadline, then in worst case it has 14 more msec to execute, during its next period. It is guaranteed to meet its next cycle, and thus will never miss two deadlines in a row. The net effect of such guaranteed soft real-time tasks is that in the worst-case, when the CPU is fully loaded, the task will execute at half rate. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 107 Embedded Systems Conference Boston, September 2011
Interrupts n n n n Since interrupts cannot be scheduled, they always have highest priority. This could lead to priority inversion. Periodic interrupts (like a regular timer interrupt) can be treated in RT analysis as the highest priority periodic tasks. WCET must be known. To maximize schedulable utilization, the period must be less than the period of the fastest task in the system. Randomly arriving interrupts can create undesired effects. If they are necessary, keep execution as small as possible. For longer execution, use an aperiodic server, with the interrupt handler sending a signal to trigger execution of the server. “Well-behaved” interrupts only come occasionally, with a known MIAT. In analysis, randomly arriving interrupts are defined to have period T=minimum inter-arrival time. WCET must be known. A predictable system cannot be built if interrupts do not have a minimum inter-arrival time. Must use aperiodic servers instead. MIAT = minimal inter-arrival time (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 108 Embedded Systems Conference Boston, September 2011
Aperiodic Servers n n n Aperiodic servers offer the ability to predictably deal with randomly arriving events. Predictability is achieved by reserving some CPU time to handle aperiodic events. TFH is used to managed that reserved CPU time. A Deferrable Server uses the same TFH Handler as soft real-time tasks. Sporadic Server is more complex to implement. Not much of an improvement over Deferrable Server. D. B. Stewart and P. K. Khosla, “Mechanisms for Detecting and Handling Timing Errors, ” Communications of the ACM, v. 40, n. 1, pp. 87 -94, January 1997. http: //www. embedded-zone. com/bib/mags/cacm 97. shtml (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 109 Embedded Systems Conference Boston, September 2011
Aperiodic Server Implementation n An aperiodic server can be implemented just like a soft real-time periodic task. n n Period T = “Replenishment Time” WCET C = “Capacity” Worst-case utilization U=C/T. Depending on the objectives of the aperiodic server, there are different ways to define T and C. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 110 Embedded Systems Conference Boston, September 2011
Aperiodic Servers Types n Hard Real-Time requiring fastest response time possible. n n n MIAT and WCET must be known. Period Taperiodic =MIAT/K; C=WCET/K. K is selected such that Taperiodic < Tfastest_task. Disadvantage: U=C/T could be significant, as this task will have highest priority in the system. If possible, design system to relax the ‘fastest response time possible. ’ (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 111 Embedded Systems Conference Boston, September 2011
Aperiodic Servers Types n Hard real-time, with deadline. n n n Immediate response is not needed, but execution must complete by a given deadline. Set Taperiodic =MIAT, C=WCET. U=C/ Taperiodic is same as previous case and could still be significant, but this server might have lower priority than some other hard real-time tasks thus improving overall schedulability. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 112 Embedded Systems Conference Boston, September 2011
Aperiodic Servers Types n Soft real-time. n n n If MIAT not known or WCET not known, then aperiodic server must be soft real-time. Decide what percentage of CPU to reserve for processing the aperiodic event. Thus U defined first. Set Taperiodic =desired response time. Set C=U* Taperiodic. If event arrives, then aperiodic server will attempt to process it within the desired response time. If unable, it will continue processing as soon as possible, but not using more than the reserved amount of CPU time (unless no other real-time tasks with reserved execution time are ready to run). (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 113 Embedded Systems Conference Boston, September 2011
Aperiodic Servers Types n Soft real-time. n Priority of the aperiodic server can be controlled: n n n To increase priority: decrease both T and C by a factor of K (K>1). To decrease priority: increase both T and C by a factor of K (K>1). If desired response time rarely being achieved, then increase U, the reserved CPU utilization for the server. (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 114 Embedded Systems Conference Boston, September 2011
Dynamic System Configuration Changes n n n n Many real-time systems are implemented with multiple modes of operation Each mode might execute a different set of tasks Create a finite state machine (FSM) to define modes as states, and mode changes as transitions. Only change set of executing tasks when mode changes. Thus each state can be defined to have a specific task set. Analyze RT performance for each state. Changing the period of a task is equivalent to a mode change. Use dynamically reconfigurable software to change states in realtime. n n As one example, see D. B. Stewart, “Software Components for Real. Time Systems, ” Embedded Systems Programming, December 2000. http: //www. embedded-zone. com/bib/mags/esp 2000. shtml (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 115 Embedded Systems Conference Boston, September 2011
Summary - Objective n To provide some guidelines and rules of thumb to quickly make the right decisions when designing and implementing real-time systems, even if you don’t have an in-depth theoretical or practical real-time systems experience. n Guideline: Generally a good practice to follow n Rule of Thumb: quick decision or approximation n Caution: Common Pitfall to Avoid (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 116 Embedded Systems Conference Boston, September 2011
Summary - Content I. Choosing the Right Environment II. Software Decomposition III. Practical Real-Time Scheduling IV. Interprocess Communication V. Common Problems and Solutions (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 117 Embedded Systems Conference Boston, September 2011
Additional Resources n n n Publications on Embedded Research Solutions Website n http: //www. embedded-zone. com/publications. shtml Embedded Systems Conference Proceedings n http: //www. esconline. com/papers. htm Embedded Systems Programming Magazine Archive n http: //www. embedded. com/archive. htm Real-Time Systems Symposium (RTSS) [for theory] n http: //www. computer. org/proceedings/proceed_r-z. htm#r n Requires IEEE Computer Society membership for access EG 3 Embedded Systems Portal n http: //www. eg 3. com/ In. Hand Electronics n http: //www. inhand. com/ (c) 2011 Dave Stewart - In. Hand Electronics - www. inhand. com 118 Embedded Systems Conference Boston, September 2011
- Slides: 118