Default pull mode seems different from V1, so getDigitalValue behaves differently

[martinwork]

By default, V1 P0 reads 0 until connected to 3V, while V2 P0 reads 1 until connected to GND.

C++

#include "MicroBit.h"

MicroBit uBit;

int 
main()
{
    uBit.init();

    while(1)
      uBit.display.printCharAsync( uBit.io.pin[0].getDigitalValue() ? '1' : '0');
}

MakeCode

basic.forever(function () {
    basic.showNumber(pins.digitalReadPin(DigitalPin.P0))
})

[finneyj]

Thanks @martinwork

Yes, it looks like we're configured differently in the v2 target specification:
https://github.com/lancaster-university/codal-microbit-v2/blob/master/target.json#L26

Having that default pulldown in v1 was always a slightly contentious choice though (I remember much debate with the BBC)! This is an easy fix to align with v1, but tagging @jaustin here first just in case he's like to take this opportunity to make a breaking change or v2...

@jaustin? I presume would prefer to maintain consistency with v1 here?

[jaustin]

I do want to maintain consistency, so my default response is definitely "yes align with V1".

I don't think I was part of the discussions first time around, though, is there something I'm missing that we're hiding or breaking with this default? Do you strongly want to make a case to change? I can't see why changing to some other default helps, and I think changing to NO_PULL gives us floating voltages and non-determinism.

[finneyj]

right. The argument was between determinism for kids looking at voltages on pins. An input always reads as zero when nothing is connected to it was more intuitive to them.

The counter argument was that no-pull is more standard for engineers and accesssory makers.

I also think set to PullDown.

[microbit-mark]

Also raised in micro:bit support #41704

This is causing confusion for users. If we are in agreement to maintain V1 compat, can this be implemented?

[finneyj]

Hi @microbit-mark - I thought this was applied ages ago:
ed5dc98

Are you still seeing recent reports?

[martinwork]

It looks like NRF52Pin::getDigitalValue(void) assumes the pull mode bits in PIN_CNF have been set, and doesn't reset them from the pullMode member.

[martinwork]

I guess changing it could have side effects in isTouched and getPulseUs.

[finneyj]

Hmmm... if changing the default hasn't taken, then we need to trace through carefully.

[martinwork]

If getDigitalValue() starts defaulting to PullDown, wherever getDigitalValue() occurs we need check it isn't assuming pullNone.

For what it's worth, all looks OK to me for getDigitalValue() to set the pull mode from pullMode (as in the DAL), except I'm not sure about NRF52SPI::config() and maybe NRF52Pin::getPulseUs().

[finneyj]

Agree. It's just internal usage we need to be concerned about - outward usage would match v1. getPulse() was technically a v1 API too (we just pulled it down from MakeCode for v2), so historically should also have been using the default pull mode, right?

[microbit-carlos]

We had more reports of users hitting this difference in behaviour between v1 and v2. #67 was originally opened from a support ticket.

[jaustin]

@martinwork can you please confirm that as of the latest DAL this issue is still reproducable

[martinwork]

@jaustin Still the same with freshly cloned microbit-v2-samples.

[finneyj]

Fixed in v0.2.25

[martinwork]

Retested... V1 and V2 behave the same.