Multi–state task
Context
● You are developing an embedded application using one or more members of the 8051 family of microcontrollers.
● The application has a time-triggered architecture, constructed using a scheduler.
Problem
How do you replace multiple tasks in an application with a single task that performs different activities depending on the current state of the system (and why is it, some- times, a good idea to do so)?
Background
See CO – OPERA TIVE SCHEDULER [page 255] and MUL TI – S TAT E TA S K [page 317] for relevant background information.
Solution
MUL TI – S TAT E TA S K encapsulates a system architecture that is apparent in many well- designed embedded applications.
To understand the need for this architecture, consider a simple washing machine control system (Figure 16.4).
Here is a brief description of the way in which we expect the system to operate:
1 The user selects a wash program (e.g. ‘Wool’, ‘Cotton’) on the selector dial.
2 The user presses the ‘Start’ switch.
3 The door lock is engaged.
4 The water valve is opened to allow water into the wash drum.
5 If the wash program involves detergent, the detergent hatch is opened. When the detergent has been released, the detergent hatch is closed.
6 When the ‘full water level’ is sensed, the water valve is closed.
7 If the wash program involves warm water, the water heater is switched on. When the water reaches the correct temperature, the water heater is switched off.
8 The washer motor is turned on to rotate the drum. The motor then goes through a series of movements, both forward and reverse (at various speeds) to wash the clothes. (The precise set of movements carried out depends on the wash program that the user has selected.) At the end of the wash cycle, the motor is stopped.
9 The pump is switched on to drain the drum. When the drum is empty, the pump is switched off.
The description is simplified for the purposes of this example, but it will be ade- quate for our purposes here.
Based on this description we will try to identify some of the functions that will be required to implement this system. A provisional list might be as shown in Figure 16.5.
Now, suppose we wish to identify the tasks to be scheduled (co-operatively) in order to implement this application. Based on our list, it may be tempting to con- clude that each of the functions listed in Figure 16.5 should become a task in the system. While it would be possible to work in this way it would be likely to lead to a complex and cumbersome system implementation.
To see why this is so, take one example: the function Control_Water_Heater(). We want to heat the water only at particular times during the wash cycle. Therefore, if we want to treat this as a task and schedule it, say every 100 ms, we need to creation an implementation something like the following:
What this task does when it is executed is to check a flag: if it is necessary to heat the water, it starts to do so: otherwise, it stops the heating process.
There are two problems with creating the program in this way:
● We are going to end up with large numbers of tasks (very large numbers in a more substantial application), most of which – like this task – actually do very little. In applications without external memory this is a particular problem, because each task will consume some of the limited memory (RAM) resources.
● It is not at all clear which, if any, of these tasks will actually set the flag (Switch_on_water_heater_G), or the other similar flags that will be required in the other tasks in this application.
In practice, what we require in this and many similar applications is a single ‘System Update’ task: this, as we will see, is a task that will be regularly scheduled and will, where necessary, call functions such as Control_Water_Heater() as and when required.
In the washing machine, this system update task will look something like the code in Listing 16.1.
Listing 16.1 is a representative example of a MUL TI – ST A TE T ASK .
We can describe the simplest form of this architecture as follows:
● The system involves the use of a number of different functions.
● The functions are always called in the same sequence.
● The functions are called from a single task, as required.
Note that variations on this theme are also common: for example, the functions may not always be called in the same sequence: the precise sequence followed (and the particular set of functions called) will frequently depend on user preferences or on some other system inputs.
Hardware resource implications
This architecture makes very efficient use of system resources.
Reliability and safety implications
There are no specific reliability or safety implications.
Portability
This high-level pattern is highly portable.
Overall strengths and weaknesses
MUL TI – ST AGE T ASK encapsulates a simple architecture that matches the needs of many embedded applications
Related patterns and alternative solutions
MUL TI – ST AGE T ASK combined with ONE – T ASK SCHEDULER [page 911] – and / or with ONE – YEAR SCHEDULER [page 919] provides a very simple and efficient system architec- ture with minimal CPU, memory and power requirements.
Example: Traffic lights
Suppose we wish to create a system for driving three traffic light bulbs. The conventional ‘red’, ‘amber’ and ‘green’ bulbs will be used, with the usual sequencing (Figure 16.6).
Listing 16.2 shows how we can create a multi-state task to achieve this. The ‘Update’ function is intended to be scheduled every second.
