On 2/26/16 12:39 PM, Hal Murray wrote:
[email protected] said:
Strange that at least 3 independant firmware trees/development teams should
chose the same magic wk860.
I don't find it strange. If the next firmware version is based on the
previous version and none of the developers has stumbled across this
potential problem earlier ...
That sounds like poor software engineering. Or poor engineering management.
The wk860 is supposed to represent the build time of the software so it will
work for 20 years from when it was built rather than 20 years from when the
10 bit week counter last rolled over or 20 years from when the constant was
last updated.
That magic constant has to be pulled out to a module where it is visible
rather than buried deep in some large module. Then the recipe for releasing
software has to update it, either by having a step in the checklist where the
human does the edit or by running a script that does it. (Yes, you have to
start by having a formal procedure for releasing software/firmware.)
for something which has a design life of <1024 weeks, I don't know that
this can be described as poor software engineering. The software meets
the requirements. It doesn't have extra complexity (needed to deal with
rollover) that is not required.
For all we know, they have some process at the mfr which would trigger
an update on new releases of the software (for new models of receiver).
20 years is a very long time for most electronics made in large
quantities. The people who get "bit" by this kind of thing are folks
using old surplus equipment (time-nuts, etc.) and deep space missions
(lots of inheritance, long mission durations).
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
