Skip to content

Simulator: digitalReadPin always returns 0 when pin is clicked #7093

Closed

Description

@microbit-grace

Describe the bug
Arising from https://support.microbit.org/a/tickets/102932 (private)

In the simulator, clicking a pin that is being read with digital read pin no longer changes the value returned. pins.digitalReadPin() always returns 0, so programs that depend on digital input can't be tested in the simulator. See screenshot below.

To Reproduce

  1. Open this MakeCode project https://makecode.microbit.org/#pub:93153-38157-46980-90426, or create a new project with this code:
    let reading = 0
    basic.forever(function () {
        reading = pins.digitalReadPin(DigitalPin.P0)
        if (reading == 1) {
            basic.showIcon(IconNames.Heart)
        } else {
            basic.clearScreen()
        }
    })
  1. In the simulator, click P0 near the bottom of the pin. The pin label shows 0.
  2. Click P0 near the top of the pin. The pin label shows 1, but the heart never appears (see screenshot below).

Expected behavior
Clicking anywhere on the pin should set it as 1, the pin label should show 1 and the heart icon should be shown. I assume it should not have the slider effect like analogReadPin where clicking the bottom/top of pin gives a different value.

Screenshots
Image

micro:bit version (please complete the following information):
not hardware related

Desktop (please complete the following information):

  • OS: Mac
  • Browser: Chrome
  • Version

Likely cause
#6795 (commit a7e9261) changed the pin mouse and keyboard handlers in sim/visuals/microbit.ts so that digital input pins are capped at a value of 1:

    let maxValue = pin.mode & PinFlags.Analog ? 1023 : 1;

However, digitalReadPin in sim/state/edgeconnector.ts (and the equivalent in sim/state/edgeconnectorsim.ts) still uses a threshold of 100:

    return pin.value > 100 ? 1 : 0;

As a digital pin's value can now only be 0 or 1, this condition is never true and the read always returns 0.

For the slider effect on the digital pin, the click handler still maps click height to a value, Math.floor((400 - cursor.y) / 40 * maxValue).

Activity

  1. abchatra commented on Oct 1, 2026

    @abchatra
    Collaborator
  2. microbit-matt-hillsdon commented on Oct 2, 2026

    @microbit-matt-hillsdon
    Contributor

    We'll take a look at this one. Please can you assign to me?

  3. martinwork commented on Oct 12, 2026

    @martinwork
    Contributor
  4. martinwork commented on Oct 26, 2026

    @martinwork
    Contributor
  5. martinwork commented on Oct 30, 2026

    @martinwork
    Contributor
  6. added 3 commits that reference this issue on Oct 30, 2026
    6d54979
    2b9b1bb
    7f58b54
  7. microbit-matt-hillsdon commented on Oct 30, 2026

    @microbit-matt-hillsdon
    Contributor

    I've been looking at this and we have some choice as to how to proceed.

    Using MakeCode v7 as a reference, mouse interaction with digital pins has a tiny area at the bottom that is 0 and the rest of the pin is 1. It's a slider but perhaps not so as anyone would notice for digital pins.

    #6795 has flipped this, and a tiny area at the top goes to 1. Additionally, it's not correctly mapped to the pin value so even when we show 1 in the sim the program doesn't see it.

    Options:

    1. Reinstate old interaction. Though I feel bad about such a tiny area being 0. I suspect folks are clicking to get 1 at the moment and then some folks probably get confused when trying to go back to 0. This demo just reinstates (code).
    2. Use a larger area. 50:50 seems logical but for the big pins 50% is confusingly approx the top of the non-hole area so hard to click the top part. This demo splits the pin half way through the main pad (code). Because it doesn't look like a slider it's still easy to click the bottom half and assume it doesn't do anything. I find it hard to recommend.
    3. Change approach for digital pins. This pin uses a switch for a11y and clicking toggles the pin value. This makes a lot of sense for a digital pin. This demo takes the toggle approach (code). Tested in VoiceOver and NVDA. I think this is the most natural approach.

    Richard Knoll (@riknoll) Abhijith Chatra (@abchatra) appreciate your thoughts. Whatever we do we'll need a fix to live.

  8. riknoll commented on Oct 30, 2026

    @riknoll
    Member

    i vote for toggle! slider doesn't really make any sense

  9. microbit-matt-hillsdon commented on Nov 3, 2026

    @microbit-matt-hillsdon
    Contributor

    12. i vote for toggle! slider doesn't really make any sense

    Thanks Richard Knoll (@riknoll). Discussed with Jonny too and we're happy with that approach. I've opened #7117.

  10. added a commit that references this issue on Nov 4, 2026
    7701f26
  11. microbit-robert commented on Nov 5, 2026

    @microbit-robert
    Contributor

    Richard Knoll (@riknoll) I've opened a PR to cherry-pick this fix to stable9.0 as it would be great to get this fix live to address the user feedback we've had. If the PR doesn't match convention, please feel free to close it and handle porting the change independently if convenient. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions