Determine micro:bit model version and add to Device Information Service #12
Conversation
source/MicroBit.cpp
Outdated
| { | ||
| switch(MicroBitAccelerometer::detectedAccelerometer->whatAmI()) | ||
| { | ||
| case 1: |
There was a problem hiding this comment.
Use defines from MicroBitAccelerometer
source/MicroBit.cpp
Outdated
| #if CONFIG_ENABLED(MICROBIT_HEAP_ALLOCATOR) && CONFIG_ENABLED(MICROBIT_HEAP_REUSE_SD) | ||
| microbit_create_heap(MICROBIT_SD_GATT_TABLE_START + MICROBIT_SD_GATT_TABLE_SIZE, MICROBIT_SD_LIMIT); | ||
| #endif | ||
| // Start the BLE stack, if it isn't already running. | ||
| if (!ble) | ||
| { | ||
| bleManager.init(getName(), getSerial(), messageBus, true); | ||
| bleManager.init(getName(), getSerial(), messageBus, true, getModel()); |
There was a problem hiding this comment.
Pass value rather than getModel()
|
In MicroBit::getModel() |
|
Should the MICROBIT_MODEL_UNKNOWN case supply a non-empty version to distinguish it from old firmware that does not add a version? And something different from the version number that would be supplied by newer firmware that knows about the next version? |
|
Oops, thanks Martin It would probably useful, I'm not sure what a sensible value would be though? "BBC micro:bit (?)"? |
|
I would rather have simple integer version numbers but in the current scheme, how about using 1.6 for the unknown future version, so >1.3 makes sense? When that future version actually appears, firmware that knows about it could call it 1.7, so we'll know if we're dealing with firmware that doesn't really know about the new hardware. |
|
What is the significance of the "x" in "v1.3x"? |
|
We chose 1.3x as we can't determine if it's a 1.3 or a 1.3b Ah ok, unknown isn't for a future version. I've added it in to cover a case where the micro:bit's model can't be determined. e.g. Accel/Mag damaged / removed |
|
The error case should be different if possible from future hardware as well as old firmware. |
|
Noted that this is a temporary fix, as there is no specific hardware way to detect the board at present (and thus device probing is a pragmatic solution). But we shouldn't rely on device probing as a long term solution as it gets really hard to manage as more variants appear. In other projects and products, tricks such as: board fitted resistor, programming an ID into the factory loaded resident boot code of interface chip at manufacture time (the recovery image region that is not upgradeable unless you use the on chip test pins), and thresholds on device serial number, have been used with various success. |
lancaster-university/microbit-dal#373