search

lancaster-university / microbit

http://lancaster-university.github.io/microbit-docs
Other
78 stars 64 forks source link

Determine micro:bit model version and add to Device Information Service #12

Closed microbit-sam closed 4 years ago

microbit-sam commented 6 years ago

https://github.com/lancaster-university/microbit-dal/pull/373

martinwork commented 6 years ago

In MicroBit::getModel() MICROBIT_ACCELEROMETER_FXOS87003 is a typo - should be MICROBIT_ACCELEROMETER_FXOS8700

martinwork commented 6 years ago

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?

microbit-sam commented 6 years ago

Oops, thanks Martin

It would probably useful, I'm not sure what a sensible value would be though? "BBC micro:bit (?)"?

martinwork commented 6 years ago

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.

martinwork commented 6 years ago

What is the significance of the "x" in "v1.3x"? Will the versions always have "v" in front with format vX.Y[x]?

microbit-sam commented 6 years ago

We chose 1.3x as we can't determine if it's a 1.3 or a 1.3b I think once we have a format we'll stick to it, so I think all will be vX.Y[x]

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

martinwork commented 6 years ago

The error case should be different if possible from future hardware as well as old firmware.

DavidWhaleMEF commented 6 years ago

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.