I’m not completely sure about your second question, since I’ve read somewhere (can’t remember where, tho’) that it doesn’t make a difference if you are using pull resistors or not, which seems counter intuitive to me.
I’d say pull resistors will have some current flowing across them, so I’m inclined to say without them, your over all power consumtion will be marginally less.
As for your first question, it’s some more or less educated guess - since I can’t find an electric diagram of the actual setup of the GPIO circuitry in the datasheet.
Since the Core is running on Vss 0V and Vdd 3.3V, I’d assume that the GPIOs are actually built “symmetric” around the avg value, which would mean that the current across either is more or less the same.
Only the last question I dare to answer definitively (although the current values we’re talking about will be extremely low - as @bko says in his post a bit further down ;-))
Since the internal pull resistors are typically rated about 40k, you’ll consume more power with lower valued external resistors (connected to 3V3 or 0V) or less respectively with higher rated resistors.
But I’ll also accept any correction by people with more factual knowledge like @peekay123, @bko or @mdma.
@ScruffR, out of interest - do you know if this is a Spark or Arduino-compatibility driven behaviour (that sleep Falling => internal pull up and vice versa); or if it is an attribute of the STM32 ?
I can see how this capability makes simple things easy for newbies, but I dislike rules like this which cannot be overridden.
Just curious and trying to understand the landscape.
Bottom line on top: within reason the resistor value will not change the power dissipation much since the input current for the input pin is limited.
The data sheet for the STM32F103 says that the weak pull-up/down are min 30k ohm, max 50k ohm, typical 40k ohm as @ScruffR said. They are probably not fully symmetric since the values are process technology dependent but it would be hard to know for any particular chip which was high and which was lower. Note 5 says that PMOS/NMOS switches that turn the pull-up/down on or off contribute up to around 10% of the resistance and their resistance is highly process dependent.
There is a formula for the VIL maximum logic low level that for a 3.3V supply works out to 1.164. The input leakage current is given as max +/- 1uA, so that would imply you could use a pull-down as large as 1.1M ohm but 100k ohm would be safer. The calculation for VIH is similar and 100k ohm should be safe there as well.
All that said, the leakage current is the same in either case so the current into the pin is the same, the only real change would be that you are not turning on the gating transistors to internal pull-up/-down which should save a tiny, tiny minuscule amount of power.
Do watch out for the internal pull down, external pull-up problem (or vice versa), the current through just the resistors will swamp the logic’s input current.
Also look out for accidentally creating a potential divider that places the input pin somewhere in the middle of the range, the exact opposite of the desired effect of pull up/down resistors.
Unfortunately not - that would again be something for @mdma or other Spark pros.
As a way not to override, but around this rule, is the use the CHANGE trigger, which doesn't auto-attach any internal pull resistors and leaves it all to you.
As SruffR pointed out, pull-up/pull-down resistor usage for wakeup is a Spark driver behaviour to prevent noise from tiggering a false wakeup. CHANGE edge trigger mode does not connect any internal resistor. I too feel that we should provide these internal connections via additional properties like : RISING_WITH_INPUT_PULLDOWN and FALLING_WITH_INPUT_PULLUP in addition to RISING, FALLING and CHANGE
We already have the behaviour defined by the RISING/FALLING mode, we should maintain that and add additional expert mode(s) that do not attach the pullups/downs.
While we’re at it, normalize the entire behaviour so an informed user can do any of the 3 edge types with any of the 3 resistor configs, because there are non-newbie use cases for all. This can be accomplished by effectively splitting the mode argument into 2 bit fields, with auto being the default as happens now, and additional modes in the upper bits allowing for explicit pullup, pulldown, or none.
We should also consider making the docs much more explicit about the activation of the internal resistors (even before we implement the feature such as I describe above), it took 38 messages on the forum and 25 days to get to the answer here, that’s too long.
@AndyW, I do greatly honour your expertise, but here I do not quite agree
As I see it, the final answer was already given in the second post, but it wasn't accepted or understood that way, so a lot of chit chat and some hard facts (but also errors of myself) went on after that, till truth was reestablished
@kennethlimcp, please don't nail me to it, but I'll see if I can find some time to do it and file a PR or send you a PM.
Yeah - it wasn’t meant in a mean way - it was just that from the users perspective it was unclear. I think making the documentation much more obvious about what I would suggest is a side-effect of the function call the OP was making can only be a good thing. I’m perfectly fine saying “RTFM” when required
Also - if the end result of this extended conversation is a more flexible interface that better meets the needs of experienced users and keeps the simplified interface for people that do not require it, then I’d say that’s a good thing.
I didn’t mean to imply that the response here was tardy or inadequate, rather that the issue appears complex and/or subtle; and the best remedy for that is documentation, and it looks like @kennethlimcp is willing to take a look over that.
Apologies if anyone took my comments the wrong way, not intended.
It’s just - as I’ve frequently said in this and other threads - very frustrating for me (and I guess for others too) when you give a “perfectly” correct feedback - even over and over again - but you can’t help the feeling it’s just not taken serious, but you’d rather find yourself pushed to defend the truth and - as in my case - even back yourself into a corner, reaching out for any fit or unfit straw you can think of just to prove the truth.
Sorry for that, but I had to let that off now
BTW: @kennethlimcp, I just came to think of it - is there any use to update the docs, or would it make more sense to wait for the proposed new wake triggers?
I say update the docs now - even if it is quick and dirty.
Otherwise, what can happen is it gets put on a queue for a sprint, then gets pushed down the priority list and before you know it, what looked like a 2 week window where waiting seemed smart turns into 3 months (for the most honorable of reasons) and more people fall into the trap.
