Interesting they did not go with 2-chip design(1 for main application, 1 for BLE stuff). Which is sometime makes sense because high power mcu usually does not have RF
The "high-end" modern MCUs are pretty great, you have the NRF offerings, but also the likes of the ESP32 where you can get Bluetooth and WiFi in a single package.
Personally these days I would lean towards the ESP32, they continue to iterate on it nicely and it has great community support. I'm personally developing a smart watch platform based on micropython.
While the ESP32 is great for many applications, it’s not for battery operated stuff. When an nRF draws 1-2 mA when using BLE, ESP32 will draw 40 mA. And the chip they selected is even more efficient.
The low power chips can also run in low power mode without BLE running using micro amps, something the ESP can’t match.
I really like ESP32 and I hope they have a low power chip on their roadmap.
Sure I agree, but the WiFi functionality is a killer feature. As mentioned in another comment, it means a smart watch stops being a smart phone addition and can actually operate as a stand-alone device.
Years ago I had a "smart" watch that had a sim card and was a full mobile phone within its own right, I think it was just 10 years or so too early.
Manufacturer lock-in can be quite a problem. I'm not saying the ESP32 solves this fully, but you can mix and match as you like, and it's highly encouraged. I think with the ESP32 most build upon Free RTOS but I'm not aware of a strict requirement.
Of note, you can just pull in a lib to use Wi-Fi and BLE on an ESP32 (C-3 at least). I've done it. It doesn't imply any changes to your firmware architecture. That's the part that bothers me about Nordic's approach.
Not insanely for a smart watch. Your smart watch battery will be something like 200mAh, so for 20 hours you need to average 10mAh. With zero optimisation, screen refresh rate at 30+fps, I have smart watch chewing 30mAh.
Getting down to 10mAh is not so bad. If you're not actively driving the display, you can under-clock significantly [1], if you're not using WiFi you can turn the modem off [2].
It might be just-about acceptable for a smartwatch. But anything the micro takes out of the power budget means less screen and radio time, which does add constraints.
PineTime, based on NRF52, will get you 4-7 days of practical usage.
There are ESP32 watches. One I have[1] comes with quite thick 940mAh battery but my understanding is the battery life still isn't that amazing (just got it, haven't really tested the battery) - something like less than a day of constant runtime or few days if you turn it off constantly
Yeah I got one of those as well. An the older non-S3 version. Fun for developing, very powerful. I use it for developing ML applications for watches etc (emlearn project). Great device for that, but battery life is not its strong point.
Can confirm, I regularly get about 9 days of charge on my PineTime, running the latest PineTimeOS release. Its gotten better and better over the years, and the functionality keeps coming ..
I used to use the PineTime with PineTimeOS, but mine eventually broke (corroded inside), but not having WiFi made it annoying to develop for. With WiFi suddenly you don't need to communicate regularly with a phone and the possibilities really open up.
I'm getting 10 hours run time with the screen continuously running and drawing graphics every refresh in micropython - extending this time out is definitely possible.
There are many ESP32 variants, depending on what you pick some may be more compelling for your use-case.
I think once we start talking about GPU, MMU, USB, display, etc, we're getting towards a CPU of sorts.
Speaking of a low-end CPU, I want to test out the RV1103 Rockchip, those crazy little chips are running Linux apparently [1], and even able to run Python [2]. Depending on power draw, a Linux-based smart watch could be on the horizon.
You got downvotes but im a firmware eng and can point out more esp deficiencies. #1 completely fake FPU that they lie aboutm. #2 awful memory bandwidth. Not only slow but unpredictable. #3 small onboard memory. #4 low clock speed.
the more chips you have, the more complex the project becomes. BOM is one thing, every chip needs support passives and oscillators, but now you also need to coordinate communication between the chips, you need to devise a way to update firmwares and access both chips for debugging purposes... that might be worth to trade off for less battery life.
in my experience they are not that much difference between 2 design. The BLE FW is a binary blob that you will download at boot with 2 chip-design, or load it to correct address with single chip-design.
> in my experience they are not that much difference between 2 design.
Depends!
If the two chips use UART or SPI for intercommunication, okay, you need two lines between the CPU and two GPIO lines for wakeup, and JTAG can be shared anyway.
But if you use stuff like shared memory, or want to do stuff like updating the display not just from the high-power chip but also from the low-power one, suddenly design becomes much more complex.
The Cortex-M33 core in the SiFli chip will be much faster than the M4 cores that the fastest released Pebble watches used, so a faster MCU than this is not something that's needed. However, more battery life is very welcome, and the fact that they're using MCUs with integrated Bluetooth this time seems to be a huge part of the upgrade from about a week of battery life to about a month of battery life.
Interesting comment, because according to https://en.wikipedia.org/wiki/PDP-7 the PDP7 (the first computer "UNIX" ran on) had ~9.2KB of memory (supporting up to 144KB).
Most contemporary SoCs will have more memory (and compute power) than that.
And frustratingly all "lacks MMU" and V6 UNIX binaries don't just run. Imagine the world where random IoT gadgets all run backported GPLv2 GNU/Unix systems and crashing left and right.
Instead there's a massive gap between Linux-capable systems and RTOS-focused systems despite, like you said, the latter now being bigger and better than real shared UNIX systems.
