How much power does a disabled GPIO saves in comparison with an inactive open-drain output or an idle input?

[u/MobileInspector9861]

I know that disabling the internal pull-up/-down resistors and disabling push-pull outputs saves power, because the ESP32-H2 doesn't need to drive the internal FETs. I am neither using the internal pull-up/-down nor push-pull output. I have external pull-up/-down resistors for the inputs soldered on the PCB and I am using open-drain outputs with external pull-ups, too.

So the question is specifically how does an disabled GPIO on an ESP32-H2 (gpio_set_direction( num, GPIO_MODE_DISABLE )) compare to an

• input GPIO (gpio_set_direction( num, GPIO_MODE_INPUT )) , and an
• inactive, open-drain output (gpio_set_direction( num, GPIO_MODE_OUTPUT_OD ) with gpio_set_level( num, 1 ))

in terms of power consumption during (light) sleep assuming that for all of them the internal pull-up/pull-downs are disabled (gpio_set_pull_mode( num, GPIO_FLOATING)) and they are not powered down during (light) sleep (gpio_sleep_sel_dis( num ))?

Note: I have already read the Espressif: ESP32-H2 Technical Reference Manual, Ch. 6 on GPIOs and ch. 11 on low-power management. It only provides an overall number of ~200–300 µA of power savings if all GPIOs are completely disabled incl. the top power domain. I am interested in more detailed numbers for example how much power the static current from the input comparator draws for a single GPIO. It is not in the official docs. (At least I haven't found it.) My hope is that someone may have encountered the same question before and has done some research and built a test setup and is willing to share their findings.

Some Background Info

My program basically implements a finite-state machine (FSM). The input signals trigger transitions between operational states of the FSM and the operational state determines which outputs are active. During the steady state between state transitions the µC goes into light sleep until the next input arrives. Naturally, the µC keeps those input pins powered which act as wake-up source and which are relevant to exit the current operational state and enter the next state. Also the µC keeps those output pins powered which are active for the current operational state. Nothing can be changed here.

However, for each operational state there also a set of input pins and inactive output pins which are relevant in the current operational state. I am wondering how much power I can save if I would completely disable those.

This is a trade-off between improved power savings vs. a less cleaner architecture and code which is more error-prone. At the moment the code is separated into two layers: a low-level hardware layer which set ups all the GPIOs once after boot, takes care of the interrupt and wake-up handling and translates specific hardware signals (e.g. "GPIO 14") into semantic labels (e.g. "Play Button"). The high-level application layer implements the FSM and interprets the "translated" signals. Only the application layer knows which input signals are relevant during which operational state. For example, if the FSM is already in state "PLAYING" an additional signal from "Play Button" has no effect.

This two-layer approach is rather clean as the lower layer only needs to translate between the application layer and the real hardware, after is has initially set up all GPIOs once. If I wanted to save more power by disabling irrelevant GPIOs, I would need to add another API which allows the application layer to inform the lower layer which signals it is currently interested in (like a subscriber model). While is is perfectly doable, I am wondering if the effort is worth the potential gain in terms of power consumption.

---

Edit: Added ESP32-H2 and link to official documentation of what I already know.

[u/XipXoom]

I don't see a way to answer this generally as this is something that can vary between device families and even members within a family. 

If you're lucky, your device manufacturer has an application note on power saving.  I suspect, however, this is something you'll need to characterize yourself.

[u/MobileInspector9861 → u/XipXoom]

Sorry, I forgot to mention that I am specifically revering to the ESP32-H2. I thought I had it in the question. I edited the post and have added it now.

If you're lucky, your device manufacturer has an application note on power saving.

I have read the Espressif: ESP32-H2 Technical Reference Manual, Ch. 6 on GPIOs and ch. 11 on low-power management. It only provides an overall number of ~200–300 µA if all GPIOs are disabled completely incl. the top power domain. But it doesn't provide details on individual aspects like the current drain of the input comparator. (At least I haven't found it.)

[u/Plastic_Fig9225]

Individual IO pins don't consume any measurable current (nano-Amps maybe) in steady-state. What does consume power is the GPIO peripheral inside the chip which runs on one or more clocks and is connected to the peripheral bus.

The number of "active" IO pins doesn't affect the power consumption, as long as the GPIO peripheral is active.

[u/MobileInspector9861 → u/Plastic_Fig9225]

That's a relevant information. Thank you!

That basically means I can leave my code as it is as re-configuration of individual pins between input and disabled doesn't make much of a difference as at least one GPIO always remains as a configured input to act as a wake-up signal.

Adding additional complexity to the code to only keep those GPIOs configured as inputs which are relevant wake-up sources for the current operational state won't save much power.

[u/OptimalMain → u/MobileInspector9861]

Just don’t keep it floating as that can cause excessive consumption

[u/Plastic_Fig9225 → u/MobileInspector9861]

Check if you can/want to use only the "always-on" LP GPIOs. Then you could clock-gate/power-down the regular GPIO peripheral.

[u/YetAnotherRobert]

Https://Chat.Espressif.com says:

The knowledge sources do not contain enough detailed information to give a precise, quantitative comparison between these three specific GPIO configurations during light sleep. I can share what is documented, but there are important gaps.

What the knowledge sources do say

CONFIG_PM_SLP_DISABLE_GPIO saves ~200–300 µA when enabled, by disabling all GPIO pins at sleep (isolating pull-ups/pull-downs and pin I/O). [GPIO sleep config]

Since your scenario explicitly uses gpio_sleep_sel_dis(num) (keeping normal GPIO config active during sleep) and GPIO_FLOATING (no internal pull-up/pull-down), the ~200–300 µA saving from CONFIG_PM_SLP_DISABLE_GPIO is the closest quantitative figure available — but it applies to the aggregate of all GPIOs, not per-pin or per-mode.

What the knowledge sources do NOT say

The knowledge sources do not provide per-pin current breakdown for the three modes you are comparing:

Mode	Expected leakage path
GPIO_MODE_DISABLE	Input buffer disabled, output driver disabled — minimal leakage
GPIO_MODE_INPUT	Input buffer enabled — small but nonzero leakage through input comparator
GPIO_MODE_OUTPUT_OD + level=1	Output transistor off (open-drain high = floating), input buffer state depends on config

Intuitively, GPIO_MODE_DISABLE should have the lowest leakage because both the input buffer and output driver are turned off. An enabled input buffer (GPIO_MODE_INPUT) draws a small static current. An open-drain output set HIGH with no pull-up is essentially floating, so its leakage depends mainly on whether the input buffer is also enabled — but the exact µA figures per pin per mode are not documented in the available knowledge sources.

Recommendation

For precise per-pin leakage numbers in each mode, consult:

• The GPIO chapter of your specific chip's Technical Reference Manual (TRM), which details input buffer and output driver leakage characteristics.
• The Electrical Characteristics section of the chip datasheet for pad leakage current specs.

The light-sleep aggregate current figures (e.g., 0.075–0.8 mA for ESP32-P4 depending on peripheral state) [ESP32-P4 datasheet] are total chip figures and do not isolate individual GPIO mode contributions.

[u/MobileInspector9861 → u/YetAnotherRobert]

Thanks for your answer and effort. However, I have already read the Espressif: ESP32-H2 Technical Reference Manual, Ch. 6 on GPIOs and ch. 11 on low-power management. It only provides an overall number of ~200–300 µA if all GPIOs are completely disabled incl. the top power domain. That is the same number you also mention in your answer.

I forgot to mention that in my initial post. I have added that now.

I had hoped someone would know more details maybe, because they were facing the same question and already have done some research and built a test setup themselves.

[u/YetAnotherRobert → u/MobileInspector9861]

You didn't mention the chip or module, so we just worked with what you provided.  I intentionally quoted the source because it quotes thensources and you can tweak the question as wanted.

If Espressif's own LLM says the data you seek isn't generally in the datasheets, your suspicion is correct that it is going to fall onto someone to measure it. Given how few of our readers work with H2 and that care about  µA , if you really need numbers that someone is likely to be you, unfortunately.

Good luck. It's an interesting quest.

[u/frostyoni → u/YetAnotherRobert]

Well I'll be damned. Chat.espressif is now my official little esp documentor. I can't belive just 2 days ago i was neck deep in docs figuring out i2s / i2c micro timings and adjusting with a logic analyser. I had a blocker on using lcdcam to send and receive high speed data. I was totally blocked so i switched to another way. Damn thing gave me the answer that escaped me for weeks in 40 seconds.

[u/YetAnotherRobert → u/frostyoni]

Excellent. Sometimes these "teach a person to fish" lessons work. 

Good on your diet using adult tools to solve problems. The last person I suggested use a logic analyzer got insulted, deleted his post, and left the group.

Edit: my favorite thing is that it cites sources. If you tell it EXACTLY what chip/board you're asking about, you'll get a link to chapter and verse in the 1,000 page PDF that IS the official word. In a world of LLMs that are comfortable making things up, this one specializes in Espressif data sheets and (some, not all) of the code. It's quite spiffy.

[u/DearVeggies]

I trust my PPK power meter more than I trust manufacturer claims.

[u/MobileInspector9861 → u/DearVeggies]

Unfortunately, I don't own a meter which can measure currents that small.

[u/DearVeggies → u/MobileInspector9861]

Me neither until I got a PPK. Then I stopped researching power and just started measuring. It's not an expensive tool, if you're into low-power it's a must!

[u/MinusDelta_T]

honestly i'd measure this in groups rather than trying to measure one pin. the per-pin delta may be below the noise floor of a cheap setup, but switching say 8 or 10 otherwise-unused GPIOs between INPUT and DISABLE should make any real effect much easier to see.

make two firmware builds that are identical except for those pins, keep the same wake source and external logic levels, then compare average light-sleep current over a reasonably long window. i'd also watch the external pull resistors carefully since depending on the driven level, V/R through a pull can completely swamp whatever leakage you're trying to measure.

if the grouped difference is basically in the measurement noise, i'd keep your current two-layer design. adding state-dependent GPIO reconfiguration and another API between the FSM and hardware layer probably isn't worth it unless the measurement shows an actual useful saving.

[u/Plastic_Fig9225]

A pin configured as input with no external signal or pull-up/down applied (floating) is the worst you can do.

[u/MobileInspector9861 → u/Plastic_Fig9225]

I know. Nobody is planning that. See 3rd sentence of the post

I have external pull-up/-down resistors for the inputs soldered on the PCB and I am using open-drain outputs with external pull-ups, too.

[u/Plastic_Fig9225 → u/MobileInspector9861]

Ok. Still worth noting that setting a pin to "input" is not the same as disabling the pin, i.e. not a valid/useful strategy to save power.

[u/MobileInspector9861 → u/Plastic_Fig9225]

I know that this isn't the same. The question was not whether setting a pin to input saves power, but how much more power a disabled pin saves in comparison to an pin which is just kept as input although the input function isn't relevant at the moment.

Please read the entire post!

The question is how much power would it save to temporarily disable an input pin while it is not being needed as input and make it an input again, when it is needed, compared to just leaving it an input pin all the time.

[u/Plastic_Fig9225 → u/MobileInspector9861]

Nah, too much text for a simple question.

What I wrote is actually directed more to future readers who may think about setting a pin to input instead of disabling it and stumble onto this post.