| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
|
|
The original approach is *really* bad at drawing vertical lines (it ends
up working a pixel at a time and works the chip select for each one.
Optimize both the pixel fill and the use of the line buffer. The result
is 20% faster for quarter screen fills, 3x for horizontal lines and 6x
for vertical lines.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
|
|
Measure the performance of the quarter screen fill, horizontal lines and
vertical lines.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
|
|
Fixes: 9eb9b74 ("Update preprocess to use $(BOARD)").
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
|
|
We also change the colour scheme slightly because the increased size of
the clock interferes visually with the main display when it is bright
white.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
|
|
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>
|
|
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
|
|
Signed-off-by: Fuji Pebri <pebri86@gmail.com>
[daniel@redfelineinja.org.uk: removed leading underscore from method
arguments, removed redundant state tracking, adopt i2c.writeto_mem]
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
|
|
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>
|
|
|
|
|
|
Currently the slider doesn't actually slide (because we process touch
events rather than swipe events) but we've called is a slider anyway.
|
|
This allows some interesting manipulations of 2-bit images.
|
|
|
|
This is an incompatible change... older 2-bit images will need to be
re-encoded to display correctly.
|
|
Fixes: #25
|
|
The logo module is currently unused but it simply sits there consuming
flash. Let's shift it to the demo app to is can consume RAM instead (but
only when we upload the demo to the watch).
|
|
sx is measured in pixels (2-bytes) and len(display.linebuffer) gives
a value in bytes so the divisor isn't right.
Whilst we are here let's make sure we use integer division too.
Fixes: #18
|
|
|
|
|
|
Rename WASP to wasp-os (or Wasp-os)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These issues do not appear when parsing with micropython but when we
import this file into sphinx then things go a bit south.
|
|
wasp-os contains circular import dependancies (wasp includes apps which
include wasp) but this is normally harmless.
However using __init__.py exagerated to the problem and since the benefit
of the __init__ file is pretty anyway the let's just remove it.
|
|
|
|
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.
|
|
On nRF devices if we print with the NUS console disconnected (instead
of never connected) then things we can end up hanging. Better only
to print an exception if the watch class contains a method to do
that.
|
|
|
|
|
|
This is getting us much closer to the final UI concept. We have a
quick ring from which we can select typical apps such as clock and
stopwatch which will (eventually) be supplemented with step counting
and heart rate monitoriing. More exotic apps (currenrtly torch, self
test, settings) are all relagated to the launcher ring.
|
|
There are still some holes here. In particular the RTC resolution on
nRF devices (such as PineTime) is currently a full second (meaning
the centiseconds will always be zero. Nevertheless that isn't the apps
fault... as we can see when we run on the simulator.
|
|
|
