All About The Switch Interface

There are two significant issues with the standard mechanical switch when used with embedded processors:

1.       Dealing with Switch Contact Bounce

2.       Decision to Field by Interrupt Method or Polling Method

Contact bounce is the item listed above as issue number one, since it must be dealt with regardless of the interface method employed. For the interrupt method, switch bounce can cause multiple interrupts and always must be eliminated with a hardware solution for proper results. The polling method is also only effective if the incoming signal is debounced, but polling is a horrible waste of time under all circumstances. Polling requires the undivided attention of the host processor to properly observe when you enter and leave one switch service cycle, so you can tell the difference between cycles if another one begins. The host processor must ignore the task of executing its program while waiting for someone to take his fat finger off a switch. Note that in most switch applications the amount of time a switch is pressed by man or machine is irrelevant to the program.

The LogiSwitch Handshake Protocol for Polling

All LogiSwitch ICs and switch products incorporate a two-way communication provision to make the most of the switch interface for your choice between the polled or interrupt switch interface method. The handshake uses a single wired-or host pin to communicate with a request/acknowledge link between the LogiSwitch device and the host processor.

The request/acknowledge polling sequence is as follows:

·         The LogiSwitch device receives an actuation from the switch.

·         The signal is debounced by the LogiSwitch device.

·         A wired-or high output is passed from the LogiSwitch device to the host processor indicating a switch service request.

·         The host pin, configured as an input, fields the request

·         The host reconfigures its pin to the output mode and outputs a low 5ms ACK pulse back to the LS device.

        The LS device  sees the ACK and latches out a low level on the common line to terminate the service request. The low level remains on     the line until another switch service request is initiated to repeat the cycle.

Note that the host processor is not required by this protocol to respond with an ACK. If the cycle continues without an ACK from the host, it will terminate as it normally would when the switch is released. Also note that once the user’s program responds to the REQ by the LogiSwitch device with an ACK, the cycle is complete, and no more attention is required. The LogiSwitch device is still working in the background to debounce the release portion of the switch cycle but that is invisible to the program. The LS device will not allow a new switch cycle to begin until the present cycle has completed and the debounce period has ended. In a normal manual switch cycle, the switch may be in the “pressed” state for about a second. A typical embedded processor of a moderate clock frequency of 16MHz will execute as many as four million instructions in that amount of time.

The LogiSwitch Device for Edge-Triggered Interrupt Processing

For normal interrupt-driven switch processing the LogiSwitch line of bounce-free pushbuttons and limit switches are ideal. For user-supplied switches or relays, LogiSwitch provides a lower cost IC device - the LS118. When used with embedded processor input pins featuring the Interrupt-on-change capability, the LS118-DB outputs a crisp, clean single-transition edge to call for a single interrupt when pressed  In all but the most extreme high-frequency interrupt applications, the LS118-DB will handle the interrupt-on-change switch processing perfectly. Note that for high frequency (1-10ms) interrupts, the LogiSwitch device is the recommended choice to assure that a single interrupt per switch cycle will register.

 Poll or Interrupt?

Pushbuttons, relays, limit switches, etc., represent the very simplest of computer peripherals, typically signaling the on or off state to your program. They are used in many ways for many different purposes and each application requires its level of attention. Below is a rough outline of a variety of switch applications and suggested methods of implementation:

Emergency Stop. The E-Stop must be implemented at the highest possible priority. It should always be implemented as an interrupt subroutine (ISR). If non-maskable interrupts (NMI) are available this is the place for it. The responsibility of the E-Stop is to immediately stop any motors, slides or machine members that may cause harm to the operator without regard as to whether or not it harms the machine. The E-Stop interrupt must always be enabled, and execution must be continued in the ISR itself with all other interrupts disabled with its highest priority task being the shut-down of all moving parts. Note that the E-Stop is not truly a safety feature. It is commonly implemented as a response to a harmful action that has already taken place such as a jammed machine or operational error.

  • Use the Interrupt method, preferably a non-maskable interrupt (NMI) if one is available. Contain all the code for the emergency stop in the ISR to the end without deviation.

Time-Critical Functions. The operator may be watching a machine member that requires an instantaneous manual pushbutton response, or something similar. While not at the critical level of importance of the E-Stop routine, a function like this does require a snappy response by the software. The implementation must be weighed against other operations which are required to be running simultaneously. Coding as an interrupt is the best choice in this case. The question is whether to code the entire routine beginning to end in the ISR or setting a flag in the ISR and returning to the main loop. This of course depends on the priority of the other routines. If the time-critical portion of the task can be completed in the ISR and the less time-critical portion can be completed in the main loop, that is usually the best way to go. Interrupts should (almost) always be short and sweet, except for the E-Stop ISR.

  • Initiate the routine with an interrupt. If the time spent in the ISR will be short, contain the entire routine in the ISR. Otherwise execute the time-critical portion in the ISR and the rest of it in the main loop.

Timer Interrupts.  A timer interrupt usually contains a checklist of several events that must be handled within certain time constraints. Each device is normally read in the ISR to determine its readiness for any action to be performed. As a rule, if the frequency of the interrupt is of a short duration (5ms to microseconds) a single switch transition may be read several times in contiguous interrupts. To insure against this happening, the switch routine in the ISR uses the handshake to remove the switch service request, precluding the possibility of it showing up in the next timer interrupt. Note that this only works properly in conjunction with the single-transition hardware debounce like the LogiSwitch device provides.

  • Timer interrupts are actually a hybrid of the interrupt and polling method in one. They initiate quickly as an interrupt but the ISR code must sample the switch device similar to the polling method. Timer interrupts implemented specifically for a single purpose like a switch service routine should be avoided if possible. Edge-triggered interrupts when available, are much more efficient and are triggered immediately when the switch is activated. Note that the handshake is not necessary in an edge-triggered interrupt since a subsequent switch service ISR will not be invoked until after the initial switch closure ahs been released.

Normal Switch Input. Under most conditions switch input has no importunate urgency. It is said that a delay of 100ms or more is perceptible to the human eye and generally agreed that 50ms or less is perceived as immediate. A typical quick pushbutton closure and release normally eats up approximately 200-300ms. This is one of the areas operators find the software appear to be “sluggish”. Removing the polling for release of the switch will dramatically improve the responsiveness of the switch service routine. This is where the handshake adds responsiveness to your routine.

  • Use Polled method for the non-time critical switch input. For responsiveness use the handshake. For a little better response in initiating these routines, sample the switch at multiple points in your main loop. Terminating the request with a handshake ACK pulse will result in no time spent in a repetitive loop.

Waiting for Input. There are times when the program has come to a point where it has nothing else to do until a pushbutton is pressed. In those circumstances it is perfectly proper to poll the switch in a tight loop for pressed status. Again, to make your program snappy, the handshake should be used to terminate the switch service routine, rather than waiting to proceed until someone releases a button.

  • Use the Polled method as shown above for normal input. If the software has no other tasks in the queue, stop and poll the switch for pressed status. Before executing the switch service routine always use the handshake to avoid waiting for release of the switch.

LogiSwitch for Interrupts. Interrupt implementation should always use hardware debouncing. There are great advantages to triggering interrupts on a rising or falling edge, only if the triggering signal from the switch comes in the form of a clean, single transition. Depending on the priority level of the interrupt and the frequency in the case of the timer interrupts, it may not be necessary to utilize the handshake.

LogiSwitch for Polling.  Most polled switch routines require the programmer to be aware of both the pressed and the released state of a switch to keep track of each individual switch cycle, when one ends and the next one begins. The lion’s share of time wasted is in polling for release of the switch. Under all circumstances your program will execute with greater response using the LogiSwitch handshake to eliminate repetitive release polling. Note that the time spent with the switch held closed is almost never relevant. Only the program knows when it no longer needs the request to be active.

Read More