Currently there's no fancy algorithms to estimate stride length. Just
pure simple step counting directly from the hardware's "intelligence
engine".
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
The code to recalculate the uptime to walltime adjustment was broken
(e.g. the longer we leave it after reboot the more inaccurate the time
setting becomes).
Fixes: 80079e4 ("wasp: nrf_rtc: Add a tiny bit of extra resolution")
We now have a couple of applications (stopwatch, Game of Life) that benefit
from sub-second precision. The micropython RTC/utime code for nrf still
needs a major overhaul but this allows us to paper over the cracks for
just a little longer.
There's a bunch of different changes here but there are only really three
big wins. The biggest win comes from restructuring the 2-bit RLE decode
loop to avoid the inner function (~20%) but the switch to 16-bit writes in
_fill() and adoption of quick_write (e.g. no CS toggling) are also
note worthy (and about 5% each).
This makes line-by-line drawing more efficient because don't have to
handle the dc line. The optimization targets font rendering and if good
for slightly less than 10% rendering improvement.
Migrate the filling of the line buffer into a seperate function.
This does naturally reduce the cost of the loop management but
much more importantly allows us to use viper native code
generator.
Currently this supports time only (no date) and it based on the
RTCounter class which is customized for nRF ports. At present
the nRF port doesn't have proper machine.rtc support so we have
implemented within wasp instead.
