Puck.js digitalRead() on D30

Hi,
Just tried to verify the state of a GPIO (D30):

>pinMode(D30,'output')
=undefined
>getPinMode(D30)
="output"
>digitalRead(D30)
=0
>digitalWrite(D30,1)
=undefined
>digitalRead(D30)
=0
>getPinMode(D30)
="output"
>digitalWrite(D30,0)
=undefined
>digitalRead(D30)
=0
>digitalWrite(D30,1)
=undefined
>digitalRead(D30)
=0
>

I probed the pin, it actually goes high and low according to digitalWrite. Anyone knows why the state cannot be read by Espruino?

I just checked on one here, and if you actually physically connect the pin to 3V then you can read that value back, so digitalRead does work.

I can't be sure why you can't read what you're outputting. Is it possible that you've actually managed to sort that pin to ground somehow?

It happens when the pin is in outputmode.

>digitalRead(D30)
=0
>digitalRead(D30)
=1
>pinMode(D30,'output')
=undefined
>digitalRead(D30)
=0
>digitalWrite(D30,1)
=undefined
>digitalRead(D30)
=0

I guess it happens on all pins, not just D30?

Looking at the code, it actually disconnects the input when in output mode - this is what Nordic does in all their code so it's what was copied, and I believe it is done to save power.

GPIOs in mictocontrollers are typically two separate circuits - one for output, one for input - so just because you set the output to one value, you're not guaranteed to get that same value when reading back.

Really? Well, this makes sense in term of power reduction. Anyway, reading this post: https://devzone.nordicsemi.com/question/64182/read-gpio-output-state/ I really seems that even on NRF52, an GPIO configured as an output can still be read.

As above - there are two separate circuits, in and out.

Yes, you can read from the OUT register and find out what you wrote. But that's not what digitalRead does, since it'd mean it wouldn't be able to read the actual value on the pin.

If you care about this and for some reason can't keep track of it yourself, you can use peek to look at the register yourself. Internally Espruino can figure it out because it needs it for pin.toggle but it's not exposed any other way

OK I got it! I did not understand that the value read in the outregister was not representative of the actual value. It is a bit confusing because on Pico and other platforms based on STM32 a pin can easily be set to 'output' while still readable by digitalRead().