New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update BLE interface and incorporate some functions into writeToCharacteristic( )
#246
Comments
{Placeholder for documentation updates to different characteristics, including link to BLE documentation for micro:bit, and showing the expect form of the value read or written} Micro:bit BLE documentation: https://lancaster-university.github.io/microbit-docs/resources/bluetooth/bluetooth_profile.html |
@jessegreenberg , I think the first bit is in place. I want to expand a bit on the information we present in each menu, but the first post should reflect some needed changes that are more structural in nature. |
…acteristic is selected, see #246
OK, I think these requests are done. However, for the following I took a slightly different approach.
Instead of overloading writeToCharacteristic, I think it would be better to have separate function per action. I think that is clearer and will work for multiple characteristics. For example, string decoding may apply to a few characteristics and the "Custom" ones. For the LED characteristic, you can now use writeMatrixToCharacteristic( [
[ 1, 1, 1, 1, 1 ],
[ 1, 0, 0, 0, 1 ],
[ 1, 0, 0, 0, 1 ],
[ 1, 0, 0, 0, 1 ],
[ 1, 1, 1, 1, 1 ]
] ); to draw a square. Some of these (like the LED example) are characteristic specific, and if you would like we can hide the function documentation when it isn't relevant. Ill do that if you are OK with this direction. Ready for you to review on the dev branch @brettfiedler ! |
I think that approach is great and certainly more generalizable. Noting the slack conversation here:
I think adding one more function to the Write characteristics form should cover us well and make the LED Text characteristic easier to use:
Otherwise, I'll check in with AE and company to see if the changes help. |
@brettfiedler what do you think of this?
Then the case where delimeters ARE is made clear by the function name. And the more general function gets a simpler name. This would require changing code in existing BLE examples so want to check with you before doing this. |
Service Selection Changes
We should simplify the information presented to users. Let's focus on hiding the UUIDs and simplifying language:
Dropdown:
Clean up Service/Characteristic selection
A lot of services either only have one relevant characteristic, or we are only supporting one. Let's automatically select it or possibly drop the second dropdown altogether when there is only one?
RX (write to the microcontroller, microcontroller is reading)
We can only write to the RX service.
What you write to the microcontroller does not always have to be a string, and it seems micro:bit handles this gracefully, but it would be nice to abstract some of the text part. I think the best option here is to duplicate the RX characteristic and then repurpose one to make the
writeToCharacteristic( )
automatically decode (for both RX and TX).UUID: 6E400003B5A3F393E0A9E50E24DCCA9E
Let's also update the
writeToCharacteristic( )
function to do add the delimiters to the string and encode the string to UTF-8, which the micro:bit expects. The user will still need to define the string, but it could be a String component, which would make things even simpler.Example JS from microbit-ratio-game:
TX (read from microcontroller, microcontroller is writing)
UUID: 6E400002B5A3F393E0A9E50E24DCCA9E
We can only read from the TX service.
Same logic as the RX, I think the best option here is to duplicate the TX characteristic and then repurpose one to make the
writeToCharacteristic( )
automatically decode into a string, and store the string intodeviceValue
.Example JS from microbit-ble-demos:
LED Service
LED Matrix
UUID: E95D7B77251D470AA062FA1922DFA9A8
Let's update
writeToCharacteristic( )
by incorporating the code we've used from https://github.com/antefact/microBit.js/blob/b512cdc79994a8d120851bd1ed360ec05e0c5bd1/src/microBit.js#L115C1-L141.I think the goal here should be that someone only has to define an
const icon = [ insert matrix here]
and then provide it to the characteristic asicon
and that should be good to go. ThewriteToCharacteristic( )
function will convert it to the Array it expects and send it off.Also is this function to convert a string to a UTF8Array helpful?
https://github.com/antefact/microBit.js/blob/b512cdc79994a8d120851bd1ed360ec05e0c5bd1/src/microBit.js#L346-L375
LED_Matrix_State :
uint8[ ]
writeToCharacteristic( icon(5x5 uint8Array) )
to automatically convert the matrix to a form the microbit will accept.LED Text
BF EDIT: NEVERMIND. I somehow missed we already had this. Sorry!
Button, Magnetometer, Accelerometer, Temperature
Each can only be read, not written to.
All of the custom services can retain the read/write tabs, since we don't know how they are being used. I don't think it makes a difference which they choose, but it could be helpful for tracking.
Remove Microbit Event service
The event service needs some more time and can't be used in the current implementation. It needs to send the respective requirements service at connection (on either side, client or microbit), then follows up with the respective event service. Not worth our time unless someone is very invested in it. I think UART should be a fine substitution.
The text was updated successfully, but these errors were encountered: