EmbeddedSys Nri Unit-VII

8/17/2019 EmbeddedSys Nri Unit-VII

1/36

UNIT – 7

Basic Design Using RTOS

Principles- An example, Encapsulating semaphores and Queues. Hard real-time schedulingconsiderations – Saving Memory space and power. Hardware software co-design aspects inembedded systems.

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


2/36


3/36

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)

Figure 8.2 Keeping Interrupt Routine Short

#define SIZEOF_CMD_BUFFER 200 char a_chCommandBuffer[SIZEOF_CMD_BUFFER];

#define MSG_EMPTY ((char*) 0) char *mboxCommand- MSG_EMPTY; #define MSG_COMMAND_ARRIVED ((char*)1)

void interrupt vGetCommandCharacter (void) {

static char *p_chCommandBufferTail -a _chCommandBuffer; int iError;

*p_chCommandBufferTail - !! Read received character from hardware;

if (*p_chCommandBufferTail -- '\r')


4/36

sc_post (&mboxCommand, MSG_COMMAND_ARRIVED , &iError);

I* Advance the tail pointer and wrap if necessary*/ ++p_chCommandBufferTail; if (p_chCommandBufferTail -•

&a_chCommandBuffer[SIZEOF_CMD_BUFFERJ)

p_chCommandBufferTail -a_chCommandBuffer;

!! Reset the hardware as necessary.

void vinterpretCommandTask (void) (

static char *p_chCommandBufferHead -a_chCommandBuffer;

int tError;

while (TRUE)

{

I* Wait for the next command to arrive. *I

sc_pend


5/36


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 taskprioritization – high priority for time-critical ones, and low priority forothers

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)

Figure 8.3 A Separate Ta k Helps Control Shared Hardware

Paper handling

task

"Out of Paper" Display task makes

decisions

about what

"For m = 66 li nes,

Button

handling task

to display.

'''

'', Hardware ' ', display

PRINTER

MELTDOWN

Figure 8.4 A Separate Task Handles a Flash Memory

typedef enum

{

FLASH_READ,

FLASH_WRITE

) FLASH_OP;

#define SECTOR_SIZE 256 typedef struct

{


6/36

FLASH_OP eFlashOp; I* FLASH_READ or FLASH_WRITE */ mdt_q sQueueResponse; /*

Queue to respond to on reads */ int iSector: /* Sector of data */

BYTE a_byData[SECTOR_SIZE];

/* Data in sector */

)FLASH_MSG;


7/36

void vlnitFlash (void) {

I* This function must be called before any other. preferably in the startup code. */

I* Create a queue called 'FLASH' for input to this task*/

mq_open ("FLASH", O_CREAT, 0,NULL); }

void vHandleFlashTask (void) {

mdt_q sQueueOurs;

FLASH_MSG sFlashMsg; int

iMsgPriority;

/* Handle of our input queue */

I* Message telling us what to do. */ /* Priority of received message */

sQueueOurs - mg_open ("FLASH", O_RDONLY, 0. NULL);

while (TRUE) {

/* Get the next request. */

mq_receive (sQueueOurs. (void*)&sFlashMsg, sizeofsFlashMsg, &iMsgPriority);

switch (sFlashMsg.eFlashOp)

{


8/36

Figure 8.4 (continued)

case FLASH_REAO:

!! Read data from flash sector sFlashMsg.iSector !! into sFlashMsg.a_byData

/* Send the data back on the queue specified by the caller with the same

priority as the caller sent the message to us. */

mq_send


9/36

I* We need to write data to the flash */

I* Set up the data in the message structure */

!! Write data to sFlashMsg.a_byData sFlashMsg.iSector-

FLASH_SECTOR_FOR_TASK_A; sFlashMsg.eFlashOp- FLASH_WRITE;

I* Open the queue and send the message with priority 5 *I sQueueFlash- mq_open

("FLASH", O_WRONLY.0, NULL); mq_send (sQueueFlash,

(void*)&sFlashMsg, sizeof sFlashMsg, 5);

mq_close (sQueueFlash);

}

void vTaskB


10/36


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-slicingoff, turn it off.


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)


11/36

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


12/36

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?


13/36

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

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


14/36

need a separate alarm-bell task] However, need a module with

BellOn(),BeiiOff() 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)

Figure 8.8 A Semaphore Can't Protect the Display Properly

void vlevelCalculationTask (void)

{

if(!! Leak detected> {

TakeSemaphore (SEMAPHORE_DISPLAY); !! Write "L EAK!!/" to disp1ay ReleaseSemaphore (SEMAPHORE_DISPLAY);

)

}

void vButtonHandlingTask


15/36

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


16/36

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


17/36

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


18/36

Figure 8.10 Encapsulating a Semaphore

I * File: tmrtask.c */

static long int l SecondsToday;

void vTimerTask (void)

{

GetSemaphore


19/36

Figure 8.11 The Wretched AJternative

I* File: tmrtask.c *I

I* global *I long int lSecondsToday;

vod) vTimerTask (voi d)

GetSemaphore (SEMAPHORE_TIME_OF_DAY); ++lSecondsToday; if (lSecondsToday -- 60 * 60* 24)

lSecondsToday - OL; GiveSemaphore (SEMAPHORE_TIME_OF_DAY);

I* File: hacker.c *I

extern long int lSecondsToday;

void vHackerTask (void)

I* (Hope he remembers to use the semaphore)* I lDeadline - lSecondsToday + 1800L;

I* (Here, too) */

if (lSecondsToday > 3600 * 12)

}

I* File: junior.c */


void vJuniorProgrammerTask (void)

{

I*


20/36

I* File: hacker.c *I


void vHackerTask (void)

I* (Hope he remembers to use the semaphore)* I lDeadline - lSecondsToday + 1800L;

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)


21/36

Figure 8.13 Encapsulating a Message Queue

I* File: flash.h */

#define SECTOR_SIZE 256

typedef void (*V_RD_CALLBACK)(BYTE *p_byData); void vWriteFlash (int iSector, BYTE *p_byData);

void vReadFlash (int iSector. V_RD_CALLBACK vRdCb);

/* File: flash.c */

typedef enum (

FLASH_READ.

FLASH_WRITE

} FLASH_OP;

typedef struct {

FLASH_OP eFlashOp; /* FLASH_READ or FLASH_WRITE */ V_RD_CALLBACK *vRdCb; /* Function to callback on read. */ int iSector; /* Sector of data */ BYTE a_byData[SECTOR_SIZE];

/* Data in sector */ } FLASH_MSG ;


22/36

#include "flash.h"

static mdt_q sOueueFlash; I* Handle of our input queue *I

void vlnitFlash (void)

{ I* This function must be called before any other , preferably in the startup code.*I

I* Create a queue called 'FLASH' for input to this task *I

sQueueFlash- mq_open ("FLASH". O_CREAT, 0,NULL);

void vWriteFlash (int iSector. BYTE *p_byData) {

FLASH MSG sFlashMsg;

sFlashMsg.eFlashOp - FLASH_ RITE;sFlashMsg.vRdCb - NULL; sFlashMsg.iSector-i Sector ;

memcpy (sFlashMsg.a _byData, p_byData. SECTOR_SIZE);

mq_send (sQueueFlash. (void*)&sFlashMsg.sizeof sFlashMsg, 5);

void vReadFlash (int iSector, V RD_CALLBACK *vRdCb)

(

FLASH_MSG sFlashMsg;

sFlashMsg.eFlashOp= FLASH_REAO;

sFlash Msg.vRdCb - vRdCb;

sFlashMsg.iSector- iSector;

mq_send (sQueueFlash.

(void*)&sFlashMsg, sizeof sFlashMsg, 6);

}

void vHandleFlashTask (void)

( FLASH_MSG sFlashMsg;

int iMsgPriority;

I* Message telling us what to do. */

/* Priority of received message */


23/36

while (TRUE) {

I* Get the next request. *I mq_receive (sQueueFlash. (void *) &sFlashMsg,

sizeof sFlashMsg, &iMsgPriority);

switch (sFlashMsg.eFlashOp) {

case FLASH_READ: !! Read data from flash sector sFlash Hsg.iSector

!I into sFlashHsg.a_byData

I* Send the data back to the task that sent the message

to us.*I sFlashMsg.vRdCb


24/36

Figure 8.13 (continued)

I* File: taska.c */

/ti ncl ude "fl-ash.h" void vTaskA

(void) {

BYTE a_byData[SECTOR_SIZE]; I* Place for flash data *I

I* We need to write data to the flash */

vWriteFlash (FLASH_SECTOR_FOR_TASK_A, a_byData);

}


25/36

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: SCn = S(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


26/36


27/36

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!


28/36

RECOMMENDED QUESTIONS

UNIT – 7 & 8

Basic Design Using RTOS

1. Explain the basic operation of telegraph system under embedded system .

2. How to avoid creating and destroying of tasks.

3. Explain underground tank monitoring system.

4. How do you encapsulate a semaphore. Explain

5. What are considerations in real time scheduling consideration.

6. How to save memory space in embedded system design.

7. Explain the techniques to save power.


29/36


30/36

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)


31/36

Figure 8.3 A Separate Task Helps Control Shared Hardware

Paper handlingtask

"Out of Paper"

"Form = 66 line ,

Display task

makes decisions

· about what to

display.

Button

handling ta k

'

''

'', Hardware ' ', display

PRINTER

MELTDOWN

Figure 8.4 A Separate Task Handles a Flash Memory

typedef enum

{

FLASH_READ,

FLASH_WRITE

) FLASH_OP;

#define SECTOR_SIZE 256 typedef struct

{

FLASH_OP eFlashOp; I* FLASH_READ or FLASH_WRITE */ mdt_q sQueueResponse; /*

Queue to respond to on reads */ int iSector: /* Sector of data */

BYTE a_byData[SECTOR_SIZE];

/* Data in sector */ )FLASH_MSG;


32/36

Q4. How to avoid creating and destroying of tasks.

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-slicingoff, turn it off.


33/36

Q5. Explain the design of underground tank monitoring system.

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)


34/36

\

Q6. How to encapsulate 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? …


35/36

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)

Q8.Waht are the techniques to save power and memory.

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


36/36

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 fro m hi-low, low-hi –

power .

Documents

EmbeddedSys Nri Unit-VII