0
\$\begingroup\$

I'm running off batteries so I don't want to leave the esp8266 on unless there is a state change. I have the button hooked to +3.3v that triggers the reset pin on the esp8266 which then sends the data off. This works fine but I would like to use 3+ buttons and I need to know which button was pressed. Since the esp8266 is just being reset there is no way to tell which button reset it so I was thinking of hooking each button up to a RC delay circuit to keep it's state longer so the MC can then boot up and read it. Using this formula

$$t = -\log \left( \frac{V-Vc}{V} \right) \times RC$$

I should be able to keep the buttons in the correct state long enough for the MC to boot and read the values while not using a lot of energy.

Is there a better approach, easier?

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Why do the buttons have to reset the µc? \$\endgroup\$
    – PlasmaHH
    Commented Mar 17, 2017 at 13:12
  • 1
    \$\begingroup\$ Most uC's have a sleep mode and can be woken from this mode by an external event. \$\endgroup\$
    – Wouter van Ooijen
    Commented Mar 17, 2017 at 13:49
  • \$\begingroup\$ I'm using the esp8622 which does not have an interrupt from deep sleep. One suggested I read was to use another uC to wake up and reset the esp8622 but that introduces more cost and space. \$\endgroup\$
    – Ryan Detzel
    Commented Mar 17, 2017 at 15:51

1 Answer 1

Reset to default
5
\$\begingroup\$

Is there a better approach, easier?

One would normally use a uC that supports low-power mode (sleep), and then wake from an interrupt. Many uC's allow interrupts to be generated from input pins.

This is cleaner, more elegant, and the expected way to do things.

If the signal is coming from a mechanical switch, then the switch signal must be properly de-bounced, outside the controller, in order to be used as an interrupt input (or else your uC may become very confused...). Proper method(s) for (hardware) switch debouncing is another subject.

Interrupts are recorded in registers, which once set are not unset until handled. This means that if the user lets go of the button, it's activation will state will remain until you handle it in code.

Since you don't specify what controller you are using, we can't say if these common features are supported in your hardware.

\$\endgroup\$
3
  • 2
    \$\begingroup\$ External debouncing should not be necessary. Most GPIO interrupts are of the "interrupt on change" variety. All you need to do is disable the interrupt on the first change, and then wait a suitable period (10 ms is typical) before reenabling it. \$\endgroup\$
    – Dave Tweed
    Commented Mar 17, 2017 at 14:18
  • \$\begingroup\$ Added that I'm using a esp8266 which does not support interrupts when sleeping. \$\endgroup\$
    – Ryan Detzel
    Commented Mar 17, 2017 at 15:47
  • \$\begingroup\$ @Dave Tweed: I've had hands on experience with a uC hardware hanging with a mech-switch input. Found warnings in the app notes, and lesson learned. May have been some time ago. Probably with an 8051. In any case, it's better to be prepared and know about the possibility of a confused processor due to hairy input signals on an interrupt. \$\endgroup\$
    – Chris Knudsen
    Commented Mar 17, 2017 at 20:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.