Draft
Conversation
Deploying microbit-connection with
|
| Latest commit: |
0dc9655
|
| Status: | 🚫 Build failed. |
This contains breaking changes (e.g. flash progress interface, connect
signature, device error codes) and will form part of a v1 at some point.
Migrating USB-only code should be trivial though.
Changes:
- Switch to capacitor-ble for bluetooth
- Quite a simplication as the service/characteristic lookups are deferred to
point of use and the interactions are internally queued.
- Support DFU and partial flashing on iOS/Android platforms
- Drop a bunch of workarounds that need reevaluating after the switch
- Temporarily drop uBit name support due to capacitor-ble limitation
- Don't try to start notifications on absent services. Prevents issues when not
in application mode for a flash.
- Improve connect interface (which had a misleading return value) and
connect/flash progress.
This branch is going to be long lived for a month or two during apps work, then
we'll loop back around and see what it means for Web Bluetooth - does it
replace it or do we have both implementations.
Design issues:
- Should connecting and connecting for flashing both be the same flow? Or are
the ideas different enough that we split them? It's nice in that it matches
USB but it's also quite different because of pairing.
microbit-matt-hillsdon
force-pushed
the
apps
branch
from
0d58d9d to
fa96588
Compare
- Use .js extension for imports consistently - Fix typo in exports for types (also on main, but at least VS Code seems to cope)
This might be a behaviour change for bluetooth but is consistent with USB.
For USB there's not really anything to do but let's keep it consistent
This has caused app-level issues because disconnected doesn't let the app understand that a reconnect will automatically happen.
You can want to pause due to a hidden tab, but defer it due to flashing then become visible before you ever did pause. But we went ahead with the pause incorrectly.
Remove them from the connection status. Check them before connect but also provide pre-flight API for UX flows. This better matches the iOS/Android permission model and is easier for client code to manage.
This is trivial for the connections and saves apps from additional state management as they often need to understand which transition happened.
…arting notifications (#76) - Attempt to connect four times before throwing error. - Throw immediately if disconnect occurs whilst connecting instead of waiting for timeout. - Ensure latest services are found.
Fixes connecting to micro:bit on Android after full flashing. Otherwise there is a "Characteristic not found" error from trying to get board version.
This seems to help significantly with reconnect on Android, where as the retry solution has encountered issues (unexpected disconnects, trouble discovering services that just increasing the delay didn't help with). Remove the retries for now - we might well reinstate but we need to do so with more care as it's led to very long retries in the case where there is no device due to app-level retries doubling the retry count. Tested on Android and iOS with a branch of ml-trainer that removes the delay after flashing.
In ml-trainer you can see this if you: 1. connect, pair, DFU 2. trigger connection errors until start-over state 3. edit the pattern away from the correct one 4. note you go on to partial flash In Web Bluetooth this wasn't an issue as we always did a clearDevice but we should fix it here for other library scenarios.
- Add a new error code for pairing information lost on peripheral. - Add new native-only progress stages (ProgressStage.CheckingBond and ProgressStage.ResettingDevice). - Add abort signal to allow for stopping of scanning (and potentially other steps in future)
…g of device on disconnect (#85) - Remove auto reconnect logic and `ConnectionStatus.Reconnecting` status in favour of the consuming app handling reconnections where necessary. - Remove discarding of connection/device on disconnect in favour of the consuming app calling `clearDevice`. So unless the app calls `clearDevice`, we assume the same device is used for the connection. - Extend radio bridge connection timeout to 10_000ms to match Bluetooth. - Remove no longer needed `ignoreDelegateStatus` - Keep serial session open when connecting to allow for reconnection after switch tabs
1. Skip 64-byte blocks that are entirely 0xFF during BLE partial flashing, matching the iOS native app's approach. The device erases each flash page when it receives a write at a page-aligned address, so interior 0xFF blocks are redundant. Flash page size is determined from the board version (V1: 0x400, V2: 0x1000). 2. Handle MakeCode hex files that nrf-intel-hex rejects. Older thin (non-universal) hex files have trailing blank lines or embedded source in custom Intel HEX record type 0x0E after the EOF record. Added truncateHexAfterEof() in hex-flash-data-source.ts, used by both BLE (bluetooth.ts) and USB (usb-partial-flashing.ts) code paths. Region bounds were verified against the iOS app's hexDataToAppRegion calculation which derives [SoftDevice end, bootloader start). Added tests covering MakeCode v0–v8 hex files (both universal and thin) with exact expected region assertions (start, end, hash).
…lative delays (#87) - Add `deviceBondState` option to Bluetooth connect. - Set device as bonded when connection is established successfully. - Set device as not bonded when connection fails. - Remove speculative delays. - Ensure partial flashing errors are raised so that the app can handle them.
Simple monorepo with npm workspaces. We'll always build everything.
This reduces partial flashing time. The `waitForDisconnect` after partial flashing has been moved to `connect`. Most of the time, the disconnect can happen in the background, except when connecting straight after partial flashing. The disconnect interferes with connecting on Android. CreateAI project hex is added as a Capacitor app file option for testing purposes. The Capacitor app has been updated to include a 'Connect' and 'Disconnect' button. Live accelerometer data is displayed if available and connected. --------- Co-authored-by: Matt Hillsdon <matt.hillsdon@microbit.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This contains breaking changes (e.g. flash progress interface, connect
signature, device error codes) and will form part of a v1 at some point.
Migrating USB-only code should be trivial though.
Changes:
Switch to capacitor-ble for bluetooth
point of use and the interactions are internally queued.
Support DFU and partial flashing on iOS/Android platforms
Drop a bunch of workarounds that need reevaluating after the switch
Temporarily drop uBit name support due to capacitor-ble limitation
Don't try to start notifications on absent services. Prevents issues when not
in application mode for a flash.
Improve connect interface (which had a misleading return value) and
connect/flash progress.
This branch is going to be long lived for a month or two during apps work, then
we'll loop back around and see what it means for Web Bluetooth - does it
replace it or do we have both implementations.
Design issues:
the ideas different enough that we split them? It's nice in that it matches
USB but it's also quite different because of pairing.
TODO: