Determine micro:bit model version and add to Device Information Service #373
Conversation
|
Example program here: |
|
What about the future though? Will this essentially be binary versioning i.e. if it's 1.3 or 1.5 depending on the accelerometer? What if there are other editions which retain the current accelerometer? |
|
I think if we have to update the board to revise another sensor or similar in the future, we should be able to identify it by the ICs on board / something similar It should be fairly simple to modify the |
|
@martinwork |
|
It would be more convenient if this info was in the advertisement, but the problems that might cause for existing software parsing the advertised name have already been discussed! Thinking about the above and @bluetooth-mdw 's comment, it would be good to make the format explicit now and specify that other info could be added, so apps can allow for that when parsing. How much space is available? Integer version numbers are slightly easier to deal with than float or text. 13 and 15? I don't know the significance of these actual version numbers. If we started with 0 and 1 now, it would fit it into a byte for 700+ years at the current rate! |
|
Agree wth @martinwork Also... the version information is of no use unless the distinction between micro:bit versions is going to be documented and there's a commitment to do that into the future. Where will this documentation live? "Documentation" may be the wrong word.... it's perhaps no more than a paragraph per version but whatever form it takes, it's needed. |
|
Definitely specify the format in code comments. |
|
Flags for: C++/makecode; flashIncomplete; compass calibrated? Or is this sort of state info not appropriate in the model characteristic? |
|
getMicrobitModel is declared in MicroBitBLEManager.h but not defined in MicroBitBLEManager.cpp. MICROBIT_MODEL_XXX string macros are defined in MicroBitDevice.h but only used in MicroBit::getModel() in lancaster-university/microbit. MicroBit::getModel() returns a string. Would it make sense to have a function that returns a simple version number for use in code and turn this into a string for calling MicroBitBLEManager::init? Could the string conversion avoid including more text constant instances containing "BBC micro:bit"? It looks like MICROBIT_BLE_MODEL is no longer used. |
|
Does this need to be implemented in DAL 2.1.0 for anything in iOS app @martinwork ? It sounds like this should be reworked slightly and we should all agree on a format before this goes forward, but just that this is a "nice to have" feature rather than a requirement when 1.5 is out
|
|
The only use the app has for this is that if it sees "1.3", it disables the alert for old hex files, which tells the user they might need an update to work with their micro:bit. Without the version, the app will always alert for old hex files. I still think integer version numbers would be better, but I have assumed "1.3" in the app now, so let me know if you change it! Most users will not see the model string. It doesn't need to be confusing, if it is specified and documented that it could change, but I don't know if it can or should be changed. |
|
whatAmI (maybe should be whoAmI) is implemented using a virtual function. Would it use less RAM and be simpler to add a single byte member variable in MicroBitAccelerometer for the subclasses to store their ID, returned by a non-virtual function in MicroBitAccelerometer? Maybe there are enough unused bits in MicroBitComponent::status? |
| @@ -150,7 +150,7 @@ class MicroBitBLEManager : MicroBitComponent | |||
| * bleManager.init(uBit.getName(), uBit.getSerial(), uBit.messageBus, true); | |||
| * @endcode | |||
| */ | |||
| void init(ManagedString deviceName, ManagedString serialNumber, EventModel &messageBus, bool enableBonding); | |||
| void init(ManagedString deviceName, ManagedString serialNumber, EventModel &messageBus, bool enableBonding, ManagedString microbitModel = ManagedString("BBC micro:bit")); | |||
There was a problem hiding this comment.
Any way to avoid using heap memory to store this info?
The micro:bit can detect what kind of micro:bit it is: 1.3x, 1.5x using by determining which accelerometer is in use.
This is then appended to "BBC micro:bit" in the Device Information Service.