Sensor signals can often have characteristics such that under some set of conditions the sensor signals give erroneous readings. For example, sensor signals indicating the presence of a device may, during the addition or deletion of a device to a system while the system is active, toggle between present and not present. Errant sensor signals may also be generated during a ramp-up of power for an added device. Errant sensor signals may also be generated due to malfunctions in an Integrated Circuit (IC). In these and other situations multiple sensor state changes may be falsely sensed and reported.
Following a de facto process of waiting a certain time before looking at a sensor signal, thereby allowing the sensor signal time to debounce, two approaches are customarily taken to handle sensor signals that are sensitive to other events. In the first of these approaches some error reports related to the sensor signal are accepted as issues with the product and ignored by the event consumer. Herein, the “event consumer” may be an application program, an operating system, a firmware entity, hardware entity, or the like. In certain circumstances it may be a user of the associated processor-based system. In the aforementioned first existing approach taken to handle sensor signals that are sensitive to other events, an initial value of a present sensor reading and a previous sensor reading are each set as equal to a default sensor state value. Then an algorithm, which may be referred to as a sensor monitor loop, is executed, wherein the present sensor reading is set equal to a retrieved sensor reading. If the present sensor reading is not equal to the previous sensor reading, a state change event is reported and the previous sensor reading is set as equal to the present sensor reading. The sensor monitor loop is then repeated.
Problematically, in this first approach it is difficult to distinguish erroneous reports from actual events. Also, under this first approach sensor-signal glitches often force the reporting of multiple events in quick succession, many of which are erroneous.
In a second existing approach, often referred to as signal debouncing, a sensor signal is read multiple times to determine if it is stable, prior to reporting a state change. In this second existing approach, initial values for a present sensor reading, a previous sensor reading and a last stable sensor reading are each set as equal to a default sensor state value. An initial value of a stable reading counter is initially set at zero. An algorithm, which may also be labeled a sensor monitor loop, sets the present sensor reading as equal to a retrieved sensor reading. If the present sensor reading is equal to the previous sensor reading, a stable reading counter is incremented. If the present sensor reading is not equal to the previous sensor reading, a stable reading counter is zeroed. However, if the stable reading counter is greater than or equal to a stable reading tolerance level, the stable reading counter is zeroed. If in addition to the stable reading counter being greater than or equal to a stable reading tolerance level, the present sensor reading is not equal to the last stable sensor reading, a state change event is reported. The last stable sensor reading and previous sensor reading are then set to be the present sensor reading. The sensor monitor loop is then repeated.
Problematically, this second approach may mask out actual errors where the sensor signal is metastable. Herein, metastable refers to a condition wherein a sensor signal continues to transition above and below a threshold that would indicate one signal state or another. Typically, a metastable sensor signal never holds at a state long enough to be considered at that value. Problematically, a metastable sensor signal may transition at some frequency greater than the number of samples required to determine that the transient state should be reported. Thus, the latter approach for signal debouncing might filter out true instability, such as where the frequency of a metastability is higher than the required threshold hold time to report a state change, thereby possibly never reporting a state change.