Switch interface (software)
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 connect the port pin of an 8051 microcontroller to some form of mechanical switch (for example, a simple push-button switch or an electromechani- cal relay)?
Background
Consider the simple push-button switches illustrated in Figure 19.1.
Depressing this switch will, in either arrangement, cause a voltage change from approximately Vcc to 0V at the input port.
In an ideal world, this change in voltage would take the form illustrated in Figure 19.2 (top). In practice, all mechanical switch contacts bounce (that is, turn on and off, repeatedly, for a short period of time) after the switch is closed or opened. As a result, the actual input waveform looks more like that shown in Figure 19.2 (bottom). Usually, switches bounce for less than 20 ms: however large mechanical switches
exhibit bounce behaviour for 50 ms or more.
This bounce is equivalent to pressing an idealized switch multiple times. This causes various potential problems, not least:
● If we need to distinguish between single and multiple switch presses: for example, rather than reading ‘A’ from a keypad, we read ‘AAAAA’.
● If we wish to count the number of switch presses.
● If we need to distinguish between a switch being depressed and being released: for example, if the switch is depressed once and then released some time later, the bounce will make it appear as if the switch has been pressed again.
Solution
Checking for a switch input is, in essence, straightforward:
1 We read the relevant port pin.
2 If we think we have detected a switch depression, we read the pin again (say) 20 ms later.
3 If the second reading confirms the first reading, then we assume the switch really has been depressed.
Note that the figure of ‘20 ms’ will, of course, depend on the switch used: the data sheet of the switch will provide this information. If you have no data sheet, you can either experiment with different figures or measure directly using an oscilloscope.
We illustrate this basic procedure in the example.
Hardware resource implications
Reading a switch input in software imposes very minor loads on CPU and memory resources.
Reliability and safety issues
We consider some reliability and safety issues associated with switches here.
Latching vs. push-button switches
All the examples in this chapter (and throughout this book) focus on the use of push- button (rather than ‘latching’) switches.
To illustrate why this is the case, we will consider two possible designs for a switch- based interface (Figure 19.3). The first interface design uses a ‘latching’ switch: specifically, this is a 5-position, rotary switch. The second design uses two push- button switches and five LEDs to provide similar functionality.
We can immediately see some advantages of the push-button solution when we consider how each system behaves when power is first applied and in an emergency situation.
In the case of the push-button solution, the software designer has control of the initial state. For example, if it is appropriate to always start the system in ‘State 2’ (as illustrated in Figure 19.3), this can be easily achieved. Similarly, suppose that State 5 involves control of a piece of machinery: if a problem develops with the machine, we might need to change the system to (say) State 4. Again, we can do this under soft- ware control and we can make this change clear to the user simply by lighting the appropriate LED.
The rotary switch interface behaves very differently. If the user moves the switch to Position 5 before applying power, then, at power up, how do we move the system to State 2? And if we do change the state to State 2, we cannot indicate this fact to the user, since we are unable to move the rotary switch. Similarly, in the emergency situa- tion just discussed, we may be able to shut down the machine under software control, but we cannot show the user that the system is now in State 4.
These problems arise not just with multi-state rotary switches but with any form of latching switch.
We can summarize the advantage of the push-button solution by saying that it leaves the software in control of the hardware, rather than vice versa. This is a good general design guideline in embedded systems.
Switch bounce times
In electrical engineering terms, the switches used as inputs in a typical microcontroller system are ‘dry’. This means that, because they must handle only small currents (< 20 mA) and voltages (< 10V), they suffer little (electrical) ‘wear and tear’ and can be expected to have a long life.
However, switches also have moving mechanical parts and their performance, inevitably, varies with age. Even a good quality switch will change its performance as it is used: in particular, the period of bounce tends to increase with age. As a result, it is important not to trust to luck or experiments with new switches when determining appropriate debounce times: you should allow a margin (at least 20%) with new switches to allow for the impact of prolonged usage.
Using single-pole switches
We have already discussed the advantages of push-button (PB) switches. Unfortunately, simply using a PB switch is not enough to ensure reliability. For exam- ple, consider again the switch in Figure 19.1: this type of switch is often referred to as ‘normally open’ (NO). If this form of NO switch is removed or damaged, leaving the connection permanently open, we cannot detect this fact in software. This may have safety or reliability implications.
In some circumstances, there may be advantages to using a ‘normally closed’ (NC) PB switch (Figure 19.4). Using a PB-NC switch, we can detect the removal of the switch or damage to the wiring, although we cannot generally distinguish this from a normal (sustained) switch depression.
We can provide an even more reliable solution by using a PB ‘double-pole, double- throw’ (PB-DPDT) switch (Figure 19.5). This generates two inputs, which will always have opposite logic if the switch is undamaged and wired correctly. Using such an input device, we can detect various types of switch faults (including switch removal) and wiring faults (including wire cutting).
Note that such a switch requires two input pins and slightly more software than a single-pole switch input.
Out-of-range inputs and ESD
Like all software-only input techniques, SWITCH INTERF ACE ( SOFTW ARE ) provides no protection against out-of-range inputs: if someone applies +/–20V to your switch (by mistake or deliberately), they may ‘fry’ the microcontroller.
Similar problems arise in the event of electrostatic discharge (ESD). ESD can present a significant problem in harsh environments (e.g. industrial systems, automotive applications) and compliance with international standards in this area (e.g. IEC 1000- 4-2) is a requirement for some applications.
There is little you can do, in software, to guard again either of these situations. See
SWITCH INTERF ACE (HARDW ARE ) [page 410] for a discussion of this issue and a solution.
Portability
None of these discussions in this pattern is 8051 specific: the pattern may be used with other microcontroller families without difficulty.
Overall strengths and weaknesses
SWITCH INTERF ACE ( SOFTW ARE ) requires a minimum of external hardware.
It is very flexible: for example, the programmer can incorporate ‘auto-repeat’ functions with few code changes.
It is simple and cheap to implement.
Like all software-only input techniques, SWITCH INTERF ACE ( SOFTW ARE ) pro- vides no protection against out-of-range inputs or electrostatic discharge (ESD). See SWITCH INTERF ACE ( HARDW ARE ) [page 410] for a discussion of this issue and a solution.
Related patterns and alternative solutions
Reading a switch input is a classic example of a situation where we can trade hard- ware cost against software complexity. For an alternative approach using hardware, consider SWITCH INTERF ACE ( HARDW ARE ) [page 410].
Where the switch (or other input device) does not suffer from bounce (for exam- ple, where your input is derived from a solid-state relay or some other form of ‘electronic switch’) then much of the complexity of these input strategies can be avoided through the use of PORT I / O [page 174].
Example: Controlling a flashing LED
In this example, we use a push-button switch to control the flashing of an LED. Here the LED flashes only when the switch is pressed.
The hardware used is illustrated in Figure 19.6 and the software framework is given in Listings 19.1 to 19.4.
