Mercurial > public > ostc4
changeset 319:d8e86af78474 fix-version
bugfix: correct packed main version number in dive header
This fixes a rather mysterious bug. Users report that up to 1.3.5 beta,
a correct version number is shown in libdivecomputer based
applications (like in Subsurface, in the extra data tab). Careful
examining the code in both libdivecomputer and the firmware shows
a subtle error in the bit mask and shift operation to pack a full
X.Y.Z.beta version number in 2 bytes (as is available in the
dive header) in the firmware end (as the libdivecomputer code
looks sane, assuming this is the right way to pack things).
Likely, this bug crept in in the conversion from the closed
source Keil period into the open source GCC setup of
the code base. So its impossible to document the exact
history of this problem here.
Further notice that the main version number is only 1 of 3 version
numbers, denoting the full version of the firmware (besides Font
and RTE).
Finally notice that this way of packing is limited to 2^5 bits
(decimal 32), so we could easily build a 1.4.21, but not a
1.4.55.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
| author | Jan Mulder <jlmulder@xs4all.nl> |
|---|---|
| date | Wed, 19 Jun 2019 14:31:50 +0200 |
| parents | 49f5db6139d5 |
| children | 117a7ec23385 |
| files | Discovery/Src/settings.c |
| diffstat | 1 files changed, 1 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- a/Discovery/Src/settings.c Sat Jun 01 10:12:15 2019 +0200 +++ b/Discovery/Src/settings.c Wed Jun 19 14:31:50 2019 +0200 @@ -1391,7 +1391,7 @@ uint8_t firmwareVersion_16bit_high(void) { - return ((firmware_FirmwareData.versionFirst & 0x1F) << 3) + ((firmware_FirmwareData.versionSecond & 0x1C) >> 5); + return ((firmware_FirmwareData.versionFirst & 0x1F) << 3) + ((firmware_FirmwareData.versionSecond & 0x1C) >> 2); } uint8_t firmwareVersion_16bit_low(void)