Most recent activity
-
Tried out
Bangle.setLCDMode("240x240")- it works well although Vector fonts do look - just perceptibly - a little more ragged. I found the simulated buttons to be unresponsive at times and Clock apps tend to stop after a few seconds when they get thelcdPoweroff event. So - I suppose in general - multi-platform apps will need to query the type of the underlying watch. -
I have also been thinking of how to have only one version of apps. It should be possible with the a bit of discipline and the ability to detect the capabilities of the underlying hardware - in most cases, I lazily hard coded in new screen coordinates. The screen size and color palette is probably the major issue but there is also the touch interface which it would be nice if apps could exploit. For example, the SMAQ3 version of my desktop style launcher allows you to click on the icon.
Related to touch, it would be nice to have swipe up and swipe down as well as a click event with x, y coordinates. These are easy to do, however, not sure how best to combine these with the current Bangle event. My version of the firmware implemented these instead of the existing touch events, however, I would prefer to,return to the standard build.
Having different versions of menu, prompt and message for the SMAQ3 was really flexible and means that you can have touch friendly versions without changing the app at all.
I got a sample SMAQ3 delivered in 10days, so as you say, it looks like they are now willing to supply the watches. I think a lot of people would be interested in getting an SMAQ3 with Espruino preloaded or at least with the DFU boot loader to avoid having to deal with SWD.
I tried emailing the VC31 manufacturer requesting a datasheet - sadly no response.
-
I have been spending some time adapting Bangle applications to the SMAQ3. You can see some of the results in the pictures below.
The flash memory, magnetometer, barometer and touch now all work reliably and reasonably efficiently thanks to Gordon's work to which I have contributed a few bug fixes. The heart monitor VC31 chip remains a mystery.Once you do the initial flash of the watch using the SWD interface, subsequent firmware updates can now be done using bluetooth which is a great convenience as the DFU loader for the NRF52840 seems to be much faster than that used for Espruino on NRF52832 devices.
When compared with the Bangle, the always on reflective display is great in daylight, but at night, the backlight tends to wash out colours and the Bangle display looks much crisper.
Battery life is nowhere near as good as the Bangle - I get 4 days and I am sure this can be improved, however, the battery at 175mah is smaller than the Bangle.js battery. It is also worth mentioning that the charging cable attaches very insecurely due to having 4 pogo style pins rather than only two on the Bangle. In fact overall, the SMA Q3 is a much less robust watch than the Bangle.
The GPS works OK, however, it loses signal in places where the Bangle does not - I think the Bangle has a much better antenna.
You can see the adapted SMA Q3 apps here together with a version of the firmware necessary to run them.
Some Bangle Apps will run without modification on the SMA Q3, especially using the standard Espruino build for the SMA Q3 which has simulated buttons. However, most apps need to be modified to deals with the different screen size and limited colour palette and to take full advantage of the touch interface.
Lastly, the additional RAM on the NRF52840 is liberating - you can run as many widgets as you want:)
Screenshots
Some pictures of apps running on the SMAQ3:
Launcher App
Multiclock App - Clock face
Multiclock App - BMP280 face
GPS Recorder App - Menu
GPS Recorder App - Track display
Note that the red padlock icon means that the screen is locked i.e. touch disabled. On the Bangle this would be display off, however, with an always on display, we simply disable touch to save power. Enabling is controlled by the usual LCD Power On settings e.g. button press.
-
@hungryforcodes - I did exactly as you suggest - actually I removed the BLUETOOTH module entirely - for Espruino on the TWATCH. See
https://github.com/jeffmer/Twatch_Espruino. -
A small update - I have now got double buffering to work with SPI flash. The solution is to introduce a simple spin lock which blocks any attempt to do a flash read until the DMA transfer has finished. I used the existing macro WAIT_UNTIL for the spin lock so that it can timeout if a DMA interrupt goes missing.
-
Many thanks, I assume, I flash the upgrade zip first and then I can flash normal Espruino builds as in BOARD=P8-SDK12 RELEASE=1 make ?
-
Having thought about it, I think the current implementation is probably the best you can do as for the reasons below, it is difficult/impossible to use double buffering. In addition, I think enabling and disabling the HW SPI is quite legitimate - it already happens to switch from DMA SPI to normal SPI to read single bytes. For some graphics screens, you have to do something similar to adjust to lower the bus speed for the touch controller if shares the display bus.
Double Buffering
My attempt at this - which works well when not using SPI flash - failed with a SPI timeout for - I think - the following reason. The driver starts a DMA operation to flush a buffer full of pixels and then returns to drawImage which accesses SPI flash to read the color palette. This read stops the DMA transfer with no completion interrupt so when it comes to try and flush the next buffer you get the SPI timeout.
I do not think that there is a general solution- other than synchronous single buffering - to stopping the CPU accessing the SPI flash in the time available during the DMA transfer. I tried blocking the SPI flash read while the DMA is in operation but this causes a sort of deadlock - #
drawImagecannot fill the next buffer because it is waiting for a spi flash read which cannot complete because it is waiting for the bus to be released.I have persevered with the driver as I would like to run different apps with different graphics requirements - you can see the result in the video below.
@fanoush - Many thanks for your invaluable help with this - looking forward to softdevice+bootloader upgrade package to move to SDK12 as I need the secure connection to connect my phone.
-
I think that would be worth investigating as I am not convinced that my current implementation is very robust. I assume the Bangle uses SW SPI as its the same NRF5x
jshardware.cimplementation. Is there any reason why you do not use HW SPI with DMA? -
Thanks for your advice. After a little bit of a struggle, I have got my driver to work with the SPIFLASH board description. I added an enable/disable function:
/** enable/disable SPI - needed for shared SPI pins between flash and device */ void jshSPIEnable(IOEventFlags device, bool enable);to
jshardware.c. You can see it here]: (https://github.com/jeffmer/Espruino/blob/master/targets/nrf5x/jshardware.c) . I also put a weak implementation injshardware_common.c. I am not sure if @Gordon will think this is something that might be included in the main repository. It would seem to be needed if you want to share SPI pins.Your board description only allocates 96 pages of the 4 Megabyte spi flash - is there any reason why we cannot use the whole 4M as with the Bangle?
With regards to Swipe, I have just extended the existing Bangle swipe event to add UP and DOWN. I use the events for navigation - specifically swipe down to look at old notifications - swipe up to return to the clock. These are just gestures recognised by the CST816 touch chip as is “click”. Smooth scrolling is quite ambitious given the display and might it be possible that the stream of touch events makes other activities unresponsive? In fact, in my prototype, I have made the `E.touchˋ event the “click” rather than the stream of touch coordinates as a quick hack. The “click” makes it easy to implement buttons.