Digital pin vs analog pin blocks

[microbit-carlos]

Summary

The "analog pin" dropdown lets you select invalid pins for the [analog read pin [P0]] block, without showing any warning/errors, and it simulates it successfully, even though it will not work on the device.

Current situation

In MakeCode v6 we have pin blocks with two kinds of pin dropdown widgets:

• The digital pin dropdown, used for digital read, digital write and more blocks like the pulse-in, etc
  
• And the analog pin dropdown, used analog read, analog write and more blocks like the servo, etc
  

The problem

This is all good for the digital read, digital write and analog write blocks. However, for the analog read block, the analog pin dropdown let's the user select an invalid pin, it doesn't show any warning on the block, and it simulates the ADC in the simulator:

This programme will not work on the device, as P9 is not an ADC pin.

New blocks

Since the introduction of pin parameters in PR #5700, we now also have the option to set a variable to a "digital pin" or "analog pin".

So this could add an additional layer of confusion to the user, as you can use the "wrong" pin block type and it will work in some cases, but might not in others.

This this example we are:

• Using an analog pin inside a [digital write pin[ _ ]] block, works ✅
• Using digital pin 0 inside a [analog read pin[ _ ]] block, works ✅
• Using digital pin 16 inside a [analog read pin[ _ ]] block, does not works ❌

Suggestions

These are not final and are open for discussion.

We could:

• Have a "pin" like the current "digital pin" block
• Have a "analog read pin" block with only the ADC pins
• Digital read/write pin blocks could accept either block
• Analog write (PWM) blocks could accept either block
• Analog read (ADC) blocks should only accept the "analog read pin" block
  • A warning could be shown in the block if a different pin is inserted

[sae220]

That's a nice suggestion, but we need a way to restrict block placed on top or to display erros.

@abchatra @riknoll
Do you have any example or idea to solve this?

[riknoll]

@sae220 the only way to do this today would be to change the argument/return types to be different

[abchatra]

I am good with @carlosperate suggestion. @sae220 do you want to try and fix this?

[microbit-carlos]

Thanks @abchatra!
To clarify, the suggestion from the description was just an initial idea, I do need to check with the rest of the team internally first, as it is a change to the public facing blocks. Due to the time constrains we were considering this as something that maybe we had to leave out for this release?

@sae220 for that reason if you could separate the work for #5700 (comment) from this one (into different PRs), that would be great, so that they don't block each other from being merged.