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.

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



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)



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)



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)



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



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


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


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

UBT BHI BIR BHT

DT

PT

[dt]

[pt]


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.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.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.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 Tn units of time Each task worst case execution time, Cn units of time and deadline of Dn

Assume task switching time is 0 and non-blocking on semaphore Each task has priority Pn

Question: Cn = (Dn + Jn) < Tn, where Jn 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.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.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


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!

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.

Documents

basic design

embedded software es

effective design

software tools

big ir code

skeletal ir code

ir handle

task code response timeirs