8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.0 Introduction To design an ES, first pick a software architecture – Round Robin Round Robin with Interrupts Function-Queue-Scheduling RTOS ES design concept and techniques discussed in Chp 8 assumes the RTOS architecture Key RTOS mechanisms used include tasks, task management, intertask communication mechanisms (semaphores, queues, mailboxes, pipes), and interrupts

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.1 Overview Prior to design, we must construct a specification of the ES to meet such requirements / properties as: Completeness Time (timing constraints - response time, reactive time, deadlines – soft vs. hard) Properties of the target hardware (for effective design of the ES), e.g., a 9600-bps serial port that receives 1200 chars per second, requires an IR that handles interrupts 1200 times each second. If chars can be written to RAM using DMA, IR code will be different Knowledge of microprocessor speed – can the  proc run the IR 1200 times per sec? Need all the software engineering skill you have, plus such properties as: structures, encapsulation, info-hiding, modularity, coupling, cohesion, maintainability, testability Effective use of design tools and methodologies – RoseRT, OO, UML, YES-UML, … Testing and debugging ES requires specialized hardware tools and software tools and techniques

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.2 Principles – Design considerations ES is interrupt-driven and ES remains dormant until Time passes for an event to occur (timer interrupt) A need for a response to an external request/interrupt arises Interrupts create cascade of events, causing RTOS tasks act/behave accordingly ES design technique: Create all needed tasks, get them into blocked-state or idle state – waiting on interrupts (to be generated by an external event, e.g., frame-arrival at a network port) (See Fig 8.1 – network port and serial port comm via tasks that implement DDP and ADSP protocol stack)

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.2 Principles – 1 Write Short IR’s: Even lowest priority IR’s are handled before the highest priority task code (minimize task code response time) IR’s are error prone and hard to debug (due to hardware-dependent software parts) Parts IR code requiring immediate / quick response should be in the core of IR code; parts needing ‘longer’ processing and not-so-urgent response should be done a task (signaled by the IR)

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.2 Principles – 2 Consider the ff specs: A system responds to commands from a serial port All commands end with a carriage-return (CR) Commands arrive one at a time, the next arrives iff the preceding one is processed Serial port’s buffer is 1 character long, and characters arrive quickly (at X bps) System’s processing time per character is Y char per second Three possible designs: A. Let IR handle everything => long response time, big IR code, hard to debug errors B. Let skeletal IR code, with a command parsing task that queues commands (with all the attendant message/data queuing problems C. Better compromise: Let IR save chars in a mailbox-buffer until CR, then the command parsing task can work on the buffer (See Fig 8.2 – IR and parsing-task use different parts of the mail-buffer: tail and head)

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.2 Principles – 3 Problem Decomposition into Tasks – How many tasks? Considerations (‘ +’ if carefully decomposed and few tasks; and ‘–’ if there’s no choice ): +More tasks offer better control of overall response time +Modularity – different task for different device handling or functionality +Encapsulation – data and functionality can be encapsulated within responsible task - More tasks means data-sharing, hence more protection worries and long response time due to associated overheads - More task means intertask messaging, with overhead due to queuing, mailboxing, and pipe use - More tasks means more space for task stacks and messages - More tasks means frequent context switching (overhead) and less throughput - More tasks means frequent calls to the RTOS functions (major overhead – adds up)

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.2 Principles – 3 Priorities (advantage of using RTOS software architecture): Decomposing based on ‘functionality’ and ‘time criticality,’ separates ES components into tasks (naturally), for quicker response time using task prioritization – high priority for time-critical ones, and low priority for others Encapsulating functionality in Tasks A dedicated task to encapsulate the handling of each shared device (e.g., printer display unit) or a common data structure (e.g., an error log) (See Fig 8.3) Parts of a target hardware storing data in a flash memory – a single task encapsulates the handling of permission-to-write-to-flash (set / reset of flash at given times) (See Fig 8.4 – using POSIX standard RTOS functions: mq_open, mq_receive, mq_send, nanosleep)

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.2 Principles – 4 Other Tasks ? Need many small, simple tasks? But worry about data-sharing, intertask comm … Need a task per stimuli? Same problems! Recommended Task Structure Modeled/Structured as State-Machines – Tasks run in an infinite loop Tasks wait on RTOS for an event (expected in each task’s independent message queue) Tasks declare their own private data to use (fully encapsulated) Tasks block on in one place (RTOS signal), and not any other semaphore, no data sharing Tasks use no microprocessor time when their queues are empty

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.2 Principles – 5 Avoid Creating and Destroying Tasks Creating tasks takes more system time Destroying tasks could leave destroy pointers-to-messages, remove semaphore others are waiting on (blocking them forever) Rule-of-thumb: Create all tasks needed at start, and keep them if memory is cheap! Turn Time-Slicing Off Useful in conventional OS’s for ‘fairness’ to user programs In ES’s fairness is not an issue, response-time is! Time-slicing causes context switching – time consuming and diminishes throughput Where the RTOS offers an option to turn time-slicing off, turn it off!

8.0 BASIC DESIGN OF EMBEDDED SOFTWARE (ES) USING RTOS 8.2 Principles – 6 Restrict the use of RTOS functions/features Customize the RTOS features to your needs (Note: the RTOS and your ES gets linked and located together into same address space of ROM/RAM – See Chapter 9) If possible write ES functions to interface with RTOS select features to minimize excessive calls to several RTOS functions (increases opportunity for errors) Develop a shell around the RTOS functions, and let your own ES tasks call the shell (and not the RTOS directly) – improves portability since only the shell may be rewritten fro RTOS to RTOS

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.3 An Example – Designing an Underground Tank Monitoring ES System Summary of Problem Specification: System of 8 underground tanks Measures read: temperature of gas (thermometer) read at any time float levels (float hardware) interrupted periodically by the microprocessor Calculate the number of gallons per tank using both measures Set an alarm on leaking tank (when level slowly and consistently falls over time) Set an alarm on overflow (level rising slowly close to full-level) User interface: a) 16-button control panel, LCD, thermal printer System can override user display options and show warning messages Histories of levels and temperature over time can be requested by user (30-50 lines long) and user can queue up ‘several’ reports Issuing commands require 2 or 3 buttons, and system can prompt the display in the middle of a user command sequence Buttons interrupt the microprocessor One dedicated button turns alarm off (connected to the system) through software The printer prints one line at a time, and interrupts the microprocessor when done The LCD prints the most recent line; saves its display-data and doesn’t need the microprocessor to retrieve info (See Fig 8.7)

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.3 An Examples Issues that remain – incomplete specs: What is displayed? Timing info? Print-line length? How often is float-level read? What is the response time on push-button – user interface response? Printer speed – number of lines per second? What is the microprocessor speed? Which kind, 8-bit? The time to set/reset alarm? Compute-time for # of gallons? 4-5 sec? (influences code design and ‘tasking’ and kind of microprocessor – if no calc is required to set overflow alarm, that saves time!) Knowing # gallons, what is the tolerant time-interval, or response-time, to set alarm? Is reading a pair of temperature and float-level data for one tank at a time? How is software interface to alarm-set off done – write a bit flag to memory or power cutoff to the alarm device Does the microprocessor come with a timer?

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.3 An Example Which Architecture? If RTOS, meeting deadlines depends on dealing with the 4-5 secs time required to calculate the # of gallons – requires task suspensions, perhaps, with less IR’s usage; and above all, the microprocessor must support some RTOS If not RTOS, meeting deadlines requires the use of several interrupts (and IR’s)

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS An Example System Decomposition for Tasks One low priority task that handles all # gallons calculations and detects leaks as well (for all tanks – 1 at a time) A high priority overflow-detection task (higher than a leak-detection task) A high priority float-hardware task, using semaphores to make the level-calc and overflow-detection task wait on it for reading (semaphores will be simpler, faster than queuing requests to read levels) A high priority button handling tasks – need a state-machine model (an IR? with internal static data structures, a simple wait on button-signal, and an action which is predicated on sequence of button signals) since semaphores won’t work (See Fig 8.8) A high priority display task – to handle contention for LCD use [Turning the alarm bell on/off by the level-calc, overflow, and user-button is typically non-contentious – an atomic op – hence do not need a separate alarm-bell task] However, need a module with BellOn(), BellOff() functions to encapsulate the alarm hardware Low priority task to handle report formatting (one line at a time), and handle report queue (See Table 8.2)

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.3 An Example Moving System Forward – Putting it together as Scenarios System is interrupt driven via interrupt routines responding to signals, activating tasks to their work User presses button, button hardware interrupts the microprocessor, the button IR sends message to button-handling task to interpret command, which activates display task or printer task Timer interrupts, timer IR -> signal to Overflow-Detection task UML Activity Diagram UBTBHIBIRBHT DT PT [dt] [pt]

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS Moving System Forward – Putting it together as Scenarios – 1 User presses printer button, print IR signals print-formatting task -> which sends first line to printer; printer interrupts for print IR to send next line to printer; when all lines (for report) are done, print IR signals print-formatting task for next report A level task need to read, it interrupts the level-read-hardware routine; the level is read by the hardware and the IR interrupts the task to read the new float level Dealing with Shared Level-Data: Three tasks need this data: level-calc for leak detection; display task; print formatting task Reading level data and ‘processing’ it by given task takes a few msec or msec Use semaphores: let level-calc and display tasks read and process level in critical section (CS) and let formatting task copy level data in CS, release semaphore, and format outside CS See Fig 8.9 and code listing in Chap 11 – Black magic and wizardry!! SEng, an Art!

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.4 Encapsulating Semaphores and Queues Encapsulating Semaphores: Don’t assume that all tasks will use semaphore correctly (take/release), leading to errors Protect semaphores and associated data – encapsulate/hide them in a task Let all tasks call a separate module (acting as an intermediary) to get to the CS - this separate module/function will in turn call the task which encapsulates the semaphore (See Fig 8.10 – the correct code) (See Fig 8.11 – the incorrect alternative, which bypasses the intermediate function

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.4 Encapsulating Semaphores and Queues Encapsulating Queues: Writing to or reading from a flash memory using queues to enqueue messages, the correctness of Fig 8.4 implementation depends passing the correct FLASH_MSG type Can a message meant for the FLASH be enqueued elsewhere Exposing the flash queue to inadvertent deletion or destruction Extra layer of data queue for holding data read from the FLASH – could this auxiliary queue be referenced wrongly? Type compatible with the FLASH content? … Solution – Encapsulate the Flash Queue structure inside a separate module, flash.c; with access to it only through intermediate task vHandleFlashTask, which is supported by auxiliary functions vReadFlash and vWriteFlash. [The handle-task provides an interface for all other tasks to get to the queue] (See Fig 8.13)

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.5 Hard Real-Time Scheduling Considerations Guaranteeing that the system will meet hard deadlines – comes from writing fast code Issues: fast algorithms, efficient data structures, code in assembly (if possible) Characterizing real-time systems: Made of n tasks that execute periodically every T n units of time Each task worst case execution time, C n units of time and deadline of D n Assume task switching time is 0 and non-blocking on semaphore Each task has priority P n Question:  C n =  (D n + J n ) < T n, where J n is some variability in task’s time Predicting Cn is very important, and depends on avoiding ‘variability’ in execution times for tasks, functions, access time of data structures/buffers, semaphore blocking – any operation that can’t be done in the same time units on each execution/access

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.6 Saving Memory Space Considerations of limited memory space for ES systems Code is stored in ROM (loaded into RAM for execution), Data is stored in RAM (except for initialization/shadowing. The two memory space types are not interchangeable Trade-offs: packed data saves RAM space, but unpacking code takes ROM space Estimate space by: A. Tasks take stack space, fewer tasks take less RAM space, inspect code to estimate stack-bytes per task – local variables, parameters, function nesting-level, worst-case nesting of interrupt routines, space for the RTOS (or select features) from the manual B. Experimental runs of the code – not easy and won’t reflect worst-case behavior

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS 8.6 Saving Memory Space – 1 Techniques / Suggestions: Substitute or eliminate large functions, watch for repeated calls to large functions Consider writing your own function to replace RTOS functions, watch RTOS functions that call several others Configure or customize the RTOS functions to suit only the needs of the ES Study assembly listing of cross-compilers, and rework your C code or write your own assembly unit/task Use ‘static’ variable instead of relying on stack variables (push/pop and pointering takes space) Copy data structures passed to a function, via a pointer, into the function’s local, static variables – process the data and copy back into structures: trade-off – code is slower For an 8-bit processor, use char instead of int variable (int takes 2-bytes and longer in calculations than 1-byte chars) If ROM is really tight, experiment with coding most functions/tasks in assembly lang

8.0 BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS Saving Power Some embedded systems run on battery, turning battery off for some or all devices is good Generally, how to do you save power? Look for the power-saving modes (enablers) which the manufacturers provide Software can put microprocessor in one the modes – via special instruction or writing a code to special register in the processor. The software must be fast!! Power saving modes: sleep, low-power, idle, standby, etc. Typical: uproc stops running, all built-in devices, and clock circuit (but leave static RAM power on since the wattage is very small) Waking uproc up is done by special circuitry and software (to avoid restart and reset – write special code to RAM address and let software check if it is cold start or restart from power saving mode) Alternative: uproc stops running but all devices stay alive, uproc is resume by interrupt (this is less a hassle that stopping all devices) If software turns power of devices back on, status data for resumption must be in EEROM, and for those devices Turn off built-in devices that signal frequently from hi-low, low-hi – power hungry!