Embedded System Development Lecture 12 4/4/2007 CS590 Embedded System Development Lecture 12 4/4/2007

Class Notes Homework #3 out next week (4/11). It will be due the following week (4/18). Final project report/demo April 25th.

Overview Embedded systems specification must address two different questions. What must the system do? How fast must it do it? Hard Real-Time Systems Soft Real-Time Systems

Overview To design effectively, you must know something about the hardware. You must also have some feel for the speed of your microprocessor. Knowing which computations will take long enough to affect other deadlines is a necessary design consideration. It is important to design with testing and debugging in mind.

Principles – General Operation Embedded systems very commonly have nothing to do until the passage of time or some external event requires a response. A very normal embedded system design technique is to have each of the RTOS tasks spend most of the time blocked, waiting for an interrupt routine or another task to send a message or cause an event or free a semaphore to tell the task that there is something for it to do.

Principles – Write Short Interrupt Routines In general, you will be better off if you write short interrupt routines rather than long ones. Since even the lowest-priority interrupt is executed in preference to the highest-priority task code, writing longer interrupt routines translates directly into slower task-code response.

Principles – Write Short Interrupt Routines Interrupt routines tend to be more bug-prone and harder to debug than task code. Example of receiving commands on a serial port.

Principles – How Many Tasks With more tasks you have better control of the relative response times of the different parts of your system’s work. With more tasks your system can be somewhat more modular. With more tasks you can sometimes encapsulate data more effectively.

Principles – How Many Tasks With more tasks you are more likely to have data shared among two or more tasks. With more tasks you are likely to have more requirements to pass messages from one task to another through pipes, mailboxes, queues and so on.

Principles – How Many Tasks Each task requires a stack; therefore, with more tasks (and hence more stacks) you will probably need more memory, at least for stack space, and perhaps for intertask messages as well. Each time the RTOS switches tasks, a certain amount of microprocessor time evaporates saving the context of the task that is stopping and restoring the context of the task that is about to run.

Principles – How Many Tasks More tasks probably means more calls to the RTOS. Moral: Other things being equal, use as few tasks as you can get away with; add more tasks to your design only for clear reasons.

Principles You need tasks for priority. One obvious reason for having multiple tasks is to be able to assign higher priorities to parts of the work with tighter response time requirements.

Principles You need tasks for encapsulation. It often makes sense to have a separate task to deal with hardware shared by different parts of the system.

Recommended Task Structure A good task structure to use is a task that remains in an infinite loop, waiting for an RTOS signal that there is something to do. One advantage is that the task only blocks in one place. When there is nothing for the task to do, the task will block and use up no processor time.

Recommended Task Structure Tasks in embedded systems are often structured as state machines: the state is stored in private variables within the task; it then acts on events, such as the receipt of a message.

Avoid Creating and Destroying Tasks Most RTOSs allow you to create and destroy tasks while the system is running. There are two good reasons to avoid this: The functions that create and destroy tasks are typically the most time-consuming functions in the RTOS. Whereas creating a task is a relatively reliable operation, it can be difficult to destroy a task without leaving little pieces lying around to cause bugs.

Consider Turning Off Time-Slicing Time-slicing is great when several human users have compute-intensive programs running on a single system. Fair is not an issue in embedded systems; on-time response is. Time-slicing causes more task switches and therefore cuts throughput. Some small minority of embedded systems can use time-slicing to advantage. However, unless you can pinpoint a reason that it will be useful in your system, you’re probably better off without it.

Consider Restricting Your Use of the RTOS Most RTOSs offer more services than you are likely to use on any given project. Since many RTOSs allow you to configure them and remove any services you don’t need, you can save memory space by figuring out a subset of the RTOS features that is sufficient for your system and using only that. Many embedded-system designers prefer to put a shell around the RTOS and have all the rest of their code call the shell rather than directly call the RTOS.

Hard Real-Time Scheduling Considerations One input to all calculations of response time is the worst case performance of each task. When considering hard real-time performance, being predictable is almost more important than being fast. For hard real-time systems it is important to write subroutines that always execute in the same amount of time or that have a clearly identifiable worst case.

Saving Memory Space Unlike desktop systems with their megabytes, embedded systems often have limited memory. In an embedded system, you may be short of code space, data space or both. When you are working on saving memory, you must make sure you are saving the right type.

Saving Memory Space One special consideration if you use an RTOS is that each task needs memory space for its stack. You should ensure that your system allocates only as much stack space as is needed. One method of determining this is by examining your code. Another way is experimental. This is easier but it is difficult to be sure you had the worst case.

Saving Memory Space Make sure you aren’t using two functions that do the same thing. Check that your development tools aren’t sabotaging you. Configure your RTOS to contain only the functions you need. Look at the compiler listings to see what assembly code is being produced.

Saving Memory Space Consider using static variables instead of variables on the stack. If you are using an 8-bit processor, consider using char variables instead of int variables. If all else fails, you can usually save a lot of space, at the cost of a lot of headaches, by writing your code in assembly language.

Saving Power Some embedded systems run on battery power, and for these systems, battery life is often a big issue. The primary method for preserving battery power is to turn off parts or all of the system whenever possible. Most embedded-system processors have at least one power-saving mode; many have several.

Saving Power The modes have names such as sleep mode, low-power mode, idle mode, standby mode, and so on. Each microprocessor is different and you need to check the manual to determine its power-saving characteristics. A very common power-saving mode is one in which the microprocessor stops executing instructions, stops any built-in peripherals, and stops its clock circuit.

Saving Power Another typical power-saving mode is one in which the microprocessor stops executing instructions but the on-board peripherals continue to operate. If you plan to have your software put your microprocessor into one of its power-saving modes, plan to write fast software.

Saving Power Another common method for saving power is to turn off the entire system and have the user turn it back on when it is needed. If your system needs to turn off any part of itself other than the microprocessor, then the hardware engineer must provide mechanisms for the software to do that. In general, parts that have lots of signals that change frequently from high to low and back draw the most power.

Class Project Any questions from last week? LCD Demo Code and Libraries