Currently the time is calculated 8 times per second from (relatively) slow
python code. Optimize the power consumed by reducing the number of times
we check for wall time updates to only once-per-second and use native
code generation to reduce VM overhead when executing this critical code.
At the time of writing the difference is battery life has not yet been
measured (but we know the current master branch is worse than v0.4 and,
in theory at least, this should close the gap).
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
For small graphical items (line drawing, font glyphs) the performance
of the set_window() method is critical.
Emit native code for this function and optimize the SPI write_cmd()
method to avoid memory allocation. This give a performance boost of
a little over 15% for (24pt) font rendering and 30% for line drawing.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Currently the bma421 driver simple re-initializes the sensor when asked
to set the step counter to zero. Switch over to the proper function
for this.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Create a simple time queue where actions (functions or bound methods) can
be queued against the real time clock.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
This means hardware failure won't cause the initial boot to fail. This
won't stop the heart rate app from crashing when it starts up but at
least it will give a comprehensible crash report.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Wake from deep power down is now handled in the driver. Remove attempt
to wake the board files.
Signed-off-by: Jeffrey Bailey <wb.jeffrey@gmail.com>
[daniel@redfelineninja.org.uk: Update commit message, simplify
slightly, extended to all boards with spinor flash and update
gitmodules to bring in the flash driver updates.]
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Currently with CST816S controllers (but not CST716S controllers) then a
swipe delivered whilst the device is asleep will sometimes be processed
after we wake it up. That's never likely to be useful. Fix this by
explicitly clearing the event buffer as part of the wakeup sequence.
Reported-by: Siroj42 <siroj42@users.noreply.github.com>
Fixes: #65
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Exceptions on th sleep path more or less kill the device (it is half
alseep and is not on... but not off enough for the power button to work.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
This is useful for devices that do not have touchscreens. It can be used
to cycle through the quick ring and to check out notifications.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
The K9 is similar to the PineTime and P8 devices but does not appear
to use the CST[78]16 touch screen controllers. At present the protocol
is not known (readfrom yields all zeros, readfrom_mem provokes an
exception) so we have a hugely limited interface consisting of the side
button and the touchscreen interrupts (in other words we can treat the
touchscreen like a second button).
Works suprisingly well considering...
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
This has two useful properties. Firstly it means the watch will be
maintained in the background, allowing the REPL to be used for
notifications and other updates. Secondly it will save a little bit
of power by reducing the work needed to handle spurious wake ups.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
There nothing in the docs to give the delay time required after a
reset. Currently we use 200ms because that appears on some older
code for BMA423 but is removed in more recent drivers. 50ms is still
a long time (for hardware) and has held up in testing.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
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.
ml server