5.

0 SURVEY OF SOFTWARE ARCHITECTURES

5.0 Overview

The basic computational model that helps structuring or organizing the components of your embedded software The underlying criterion is: how much (logical) control is needed to satisfy the required system response time. Other factors affecting response are: processor speed, system overhead Guides:

A simple architecture: if response time is not a major issue A complex architecture: if there are multiple, rapid deadline and priority reqs

Topics:

Round-robin - simple Round-robin with interrupts - fairly complex Function-queue-scheduling - complex Real-time operating system - very complex

5.0 SURVEY OF SOFTWARE ARCHITECTURES

5.1 Round-Robin Architecture Advantages:

Simple No interrupts and no shared data No response latency (and no overhead) More suitable for systems that require one-at-a-time operation (e.g., digital watches, microwave ovens with simple functionality) If any device or service/processing needs response in less time than it takes the microprocessor to complete processing any system component (e.g., a loop, a module, a basic functionality) then RR wont work Adding more functionality, devices, or service/processing introduces potential timing or response time problems, which weakens the RR arch

Disadvantages:

5.0 SURVEY OF SOFTWARE ARCHITECTURES

Fig 5.1 Fig 5.2 Fig 5.3

5.0 SURVEY OF SOFTWARE ARCHITECTURES

5.2 Round-Robin with Interrupts

Offers more control over priorities via hardware interrupts Interrupt handlers implement higher priority functions (allowing the assignment of levels of priority among devices/handlers) The handlers set flags, which are polled by the task code to continue when the handlers complete their job (e.g., fDeviceX, where X is device A, B, or Z Fig 5.4) Advantages:

Danger of having shared data solved using techniques discussed in Chapter 4 See Fig 5.4 Setting and controlling using priorities See Fig 5.5

Disadvantages:

5.0 SURVEY OF SOFTWARE ARCHITECTURES

5.2 Round-Robin with Interrupts Example: A Simple Bridge

RR w/I is powerful enough to handle simple to fairly complex systems Consider: A two port bridge, with bi-directional encrypted/decrypted data property Assumptions:

Characters arrives at the hardware I/O port, one at a time, causing interrupt routines to read/write out of the port No hard deadline, or speed requirement, for the time to read/write from/to the port Read/write routines do so from/into a queue for the bridge to encrypt/decrypt, one character at a time (the queue is a shared data, and it is handled in the task code to avoid problems)

The task code protects the shared queue-data structure The task code (simulating the bridge) is supported by vEncrypt and vDecrypt routines (See Fig 5.6 and Fig 5.7)

5.0 SURVEY OF SOFTWARE ARCHITECTURES

5.2 Round-Robin with Interrupts 2 Example Bar Code Scanner

The scanners (hardware) laser reads the bar code and transmits as radio waves Response time requirement is time for reading and transmitting signals Task code will be serviced quickly (making RR a sufficient architecture)

5.0 SURVEY OF SOFTWARE ARCHITECTURES

5.2 Round-Robin with Interrupts 3 Characteristics of the Round-Robin with Interrupts

Low priority tasks could experience longer delays, if higher priority tasks execute code (outside their critical section) which take a long time Ex: If task A takes 200 ms to execute code outside its CS, then the waiting/response time for lower priority tasks B, C, will be so increased Moving out-of-CS code for B and C into their interrupt handlers will help regain some time or indirectly increase their priority levels. Meaning, the handlers for B and C will also take 200 ms more to execute, increasing the overall response time for B and C One way to improve the response time of a task with lower priority is to check its status flag more frequently than others (typical RR technique in OS)

Summary: Any task which is a processor hog will not be good to model using a RR with interrupt architecture, since response time will be bad! [Ex. The laser printer task and the underground tank-monitoring task in Chapter 1]

5.0 SURVEY OF SOFTWARE ARCHITECTURES

5.3 Function-Queue-Scheduling Architecture

Improves the response time of higher priority tasks. Interrupt routines add function-pointers to a queue for the main task to execute The main task continuously scans the queue and executes the corresponding function Allows placing function-pointers in the queue based on preferred priority scheme (placement is done by a supporting/auxiliary routine invoked by the handlers) See Fig 5.8 Characteristics:

The worst-case response time for highest-priority tasks is: sum(longest task code, any interrupts this code generates), and not the sum of the response times of all the handlers The response time for lowest-priority tasks could be long when their code segments are long

5.0 SURVEY OF SOFTWARE ARCHITECTURES

5.4 Real-Time Operating Systems Architecture

In this architecture, the handlers signal the OS when their work is done. The OS then switches control to the task code (when appropriate) to continue its job The signaling and its code are part of the OS The OS can preempt any task code to run another See Fig 5.9 handler for Device A signals X, which causes Task 1 to run immediately (meaning zero waiting time for Task 1 except its handlers time) See Fig 5.10 Comparing the priority schemes of three architectures Differences:

Changing the size of the task code doesnt affect the length of the response time under the RTOS architecture, but the others will be affected RTOS comes with all the interrupt/signaling routines as well as debugging tools Overall system throughput is reduced (a little) by the time the OS takes for support functions

A hybrid architecture of RTOS and, e.g., RR with interrupts to poll slower devices, might be a good design (See Table 5.1)