WS2812 LEDs on P0 incompatible with onboard V2 music

[DaveAtKitronik]

Describe the bug if there are WS2812 LEDs attached to P0 on a device and the user uses the V2 music blocks then the LEDs come on, usually full white. This was reported by a user in the field with a Kitronik Servo:lite - where the WS2812 LEDs are on P0, but will also affect any other accessory with a similar configuration (for Kitronik this is ZIP64 and HALO)

To Reproduce create the following code:

soundExpression.giggle.play()

turn on and see the LEDs randomly come on.

AS the V2 onboard sounder is not physically connected to P0 I think this could be fixed by not routing the sound output to the edge connector - possibly with a block similar to the disable onboard speaker. For now we will advise the user that sound and P0 ws2812 LEDs are not currently compatible.

[jaustin]

I don't believe this is an incompatibility... It's more that you can't have two things be the default behaviour and we picked that the default behaviour for sound on V2 should be the same as it was on V1, which was that it would come out the edge connector. This is to ensure that speaker accessories for micro:bit V1 that have an amplifier, etc, also get to amplify the sounds.

You can set an audio pin in MakeCode today. Although you can't currently select "none", you could select something else... For example

@DaveAtKitronik does using this work around the issue for you? I just tested it here with a speaker and the speaker doesn't play if I do this:

@pelikhan is there an easy way to add a 'none' to this block, (I think we kinda covered this in #3740)

Or @DaveAtKitronik would it work if we exposed the C++ call audio.setPinEnabled(false); in JS? I would prefer not to add another block :/

@DaveAtKitronik We also discussed checking at the time we first play a sound whether the pin has already been used for something else, I think, so I believe it might be possible to do something digital with the pin before playing a sound, like this:

But @finneyj you did this for event handlers, but it doesn't seem to cover just digital operation. At least on current MakeCode beta with the sample above, I still get sound on P0. Looking at https://github.com/lancaster-university/codal-microbit-v2/commit/7145889d5d66325cce67cb2cb26f480dc46f8e5a it would seem only if we have an event handler on P0 would we avoid default audio routing.

[DaveAtKitronik]

@jaustin I think the user was excited to have sound on their :MOVE mini. In an ideal world the system would realise its a V2, and that there are none audio things attached to P0 and just not route audio out. That sounds like a nightmare to implement in a sensible manner and catch all the possibilities, so I don't think going that way is a good idea.

The pin already used doesn't detect the Neopixels unless they have been 'shown' - I guess when the pin is actually written to. I could get this to go wrong fairly consistently:

But didnt see this fail:

That is slightly confusing - if the user happens to put an audio block - for instance to indicate power up before showing the LEDs it will sometimes not work as expected.

Perhaps the solution is to have a new 'pin' in the set audio pin block - internal speaker (V2 only)? That would give the user the choice to deliberately not route audio out, and would fit with the current 'I want audio on' type of thinking, whilst still allowing the internal sounder to work. Although adding one more option its not a new block and I think fits OK. That might also work for @4tronix based on their comment in https://github.com/microsoft/pxt-microbit/issues/3740