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.
Post on 03-Jan-2016
214 Views
Preview:
Transcript
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
UBT BHI BIR BHT
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 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.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!
top related