On–off switch
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.
● You are creating the user interface for your application.
Problem
How do you obtain the behaviour illustrated in Figure 19.9 from a single, push- button switch connected to the port pin of a microcontroller?
The switch is intended to operate as follows:
● The user presses the switch to turn on a piece of equipment.
● The equipment operates as required.
● The user presses the switch again to turn off the equipment.
This seems very straightforward. However, suppose we are applying the basic approach to switch reading presented in SWITCH INTERF ACE ( SOFTW ARE ) [page 399], or SWITCH INTERF ACE ( HARDW ARE ) [page 410]. This can be summarized as follows:
1 We read the relevant port pin.
2 If we think we have detected a switch depression, we read the pin again 100 ms later.
3 If the second reading confirms the first reading, we assume the switch really has been depressed.
This is what can happen:
● The user presses the switch to turn on the piece of equipment.
● The switch is checked. It is depressed.
● The switch is checked (say) 100 ms later: the second check confirms the first. The equipment is turned on.
● The switch is checked 100 ms later. It is still depressed.
● The switch is checked 100 ms later: the second check confirms the first. The equip- ment is turned off again.
● And so on.
This behaviour arises because the user will generally wait until the equipment begins to work and will then remove their finger from the switch. In the best case sce- nario, a switch depression is likely to last about 500 ms. Unless we take action to prevent it, the equipment will ‘flicker’ on and off.
Solution
We can most simply create an on-off switch by adding a ‘switch block’ counter to the existing interface code. This works as follows:
1 Every time we find the switch has been pressed, we ‘block’ it for – say – 1 second.
2 While the switch is blocked, any changes in switch status are ignored: thus, for example, if the user keeps the switch depressed for half a second, this fact will be ignored.
The ‘on-off’ example that follows illustrates how this is achieved in practice.
Hardware resource implications
Reading a switch input imposes minimal loads on CPU and memory resources.
Reliability and safety issues
In hostile environments, this code should be based on SWITCH INTERF ACE ( HARD – W ARE ) [page 410].
Note that, where safety is a primary concern, the blocking of switch inputs may not be appropriate. As an alternative, you can retain the basic switch-handling approach, but use two switches (Figure 19.11).
The use of two switches can make it easier to react quickly to changes in the inputs and may be safer under some circumstances.
Portability
This pattern may be adapted for use with other microcontrollers without difficulty.
Overall strengths and weaknesses
A simple way of achieving ‘ON–OFF’ behaviour from a single switch.
Related patterns and alternative solutions
This pattern builds on SWITCH INTERF ACE ( SOFTW ARE ) [page 399] and / or SWITCH INTERF ACE ( HARDW ARE ) [page 410].
See ‘Reliability and safety issues’ for an alternative solution.
Example: Controlling a flashing LED
In this example, we use the hardware in Figure 19.12 to illustrate the creation of an on-off switch interface.
The key software files required in this example are presented in Listings 19.6 to 19.9: as usual, a complete set of files for the project are included on the CD.
