Enter BLE mode using a MicroBitEvent

[microbit-sam]

No description provided.

[ghost]

What do you mean by "BLE mode"?

OK, I see this is Pairing Mode.... whose name may or may not have changed :-)

What's the use case for this (out of interest)?

[microbit-sam]

Yeah, BLE mode = Pairing Mode
I'm not sure what the correct name for it is at the moment!
lancaster-university/microbit-dal#318

The idea is so that if a project has hard to access the buttons (e.g. clock on the wall), the user can create a custom method to enter Pairing/BLE mode

[jamesadevine]

Cool, this seems like a no brainer! What's GPREGRET used for?

[microbit-sam]

GPREGRET retains it's value through a soft reset microbit_reset() so the MB can restart in BLE mode without any user code running.

However GPREGRET isn't guaranteed to keep it's state after a hard reset, so using the Key/Value storage may be better

@jaustin pointed out a use case where a BLE flash fails due to the user resetting the MB at the wrong time
If the reset into BLE mode flag could be set before flashing, and cleared upon a successful flash, the MB would boot back into BLE mode if interrupted

[ghost]

OK, that's a great idea then. Like it very much :-)

[jamesadevine]

Cool, maybe you could add a couple of comments detailing that?

Also - my one concern here is that adding the overhead of a listener of 70 bytes or so (especially in BLE mode) is not a good idea. Instead, we could reuse this code somehow... https://github.com/microbit-sam/microbit/blob/81dc7f52321d24f91b557bbbc32a3d7a05fe24c6/source/MicroBit.cpp#L195

Or even simpler, add a function call to ble manager.

[jaustin]

@jamesadevine good catch.

I think the two options are to generalise the messagebus listener you pointed to into a 'uBit specific events' listender and then put the pairing mode handler in there if the mode is enabled....

But I think it might just be easier to add a function in BLE manager. Sam - we only call 'init' on BleManager if we actually have Bluetooth enabled and we need to do this from a radio build, so you can't use anything that gets initialised by init() but you should be able to get into pairing mode fine. (https://github.com/microbit-sam/microbit/blob/81dc7f52321d24f91b557bbbc32a3d7a05fe24c6/source/MicroBit.cpp#L178 )

I was actually surprised to see we have a BLEManager in uBit no matter what, but I like the idea that it's always there but not always up.

Is there any difference for how easy it is for Microsoft to wrap this in a block based on the two mechanisms? We want to let people trigger 'BLE Mode' however they like... Not sure where that block should live in MakeCode (probably in 'control')

[jamesadevine]

@jaustin I think it's fairly trivial to wrap a function and dress it as a block. The "pairing mode" function could be represented as a block, and that block could be used in conjunction with an event handler:

[on button a pressed
   [ enter pairing mode]
]

This would handle the majority of use cases for users wanting to do this. Further, firing and creating events is considered an advanced action in MakeCode, hence many users aren't aware of its existence. I think the above would be the best option in many ways.

For those wanting to program this from C++ land, they would likely use similar mechanisms for interactive actions, or call the pairing mode function in conjunction with driver code, i.e. when they receive a datagram, or a certain sequence of serial bytes. In either case, this is application driven and does not need special treatment.

[pelikhan]

Is it possible to also call this from a program running "radio"? Would be great to be able to remote flash micro:bit even if they are not using BLE.

[jaustin]

Yea, that's the idea - that we can call it from a radio program to use BLE for flashing. (That's why we need to be able to call the function without BLE being initialised)

…

On 7 Mar 2018 9:21 pm, "Peli de Halleux" ***@***.***> wrote: Is it possible to also call this from a program running "radio"? Would be great to be able to remote flash micro:bit even if they are not using BLE. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI-qffJL3VNJioVCb2ZKweKA6HsWNA0ks5tcE9egaJpZM4SYUDn> .

[finneyj]

superseded by #13